VITAL
  
    
    
     
   
   Formal Definition
  
   VITAL (VHDL Initiative Towards
   ASIC Libraries) is an initiative, which objective is to accelerate
   the development of sign-off quality ASIC macro-cell simulation
   libraries written in VHDL by leveraging existing methodologies of
   model development. 
  
   Complete description: IEEE Standard 1076.4. 
  
   Description
  
   VITAL, which is now
   standardized by IEEE, was created by an industry-based, informal
   consortium in order to accelerate the availability of ASIC
   (Application Specific Integrated Circuits) libraries for use in
   industrial VHDL simulators. As a result of the effort a new modeling
   specification has been created. 
  
   VITAL contains four main elements: 
  
   - 
   
    Model Development Specification document,
     which defines how ASIC libraries should be specified in VITAL-compliant
     VHDL in order to be simulated in VHDL simulators. 
    - 
   
    VHDL package Vital_Timing,
    defining standard types and procedures that support development of
    macro-cell timing models. The package contains routines for delay
    selections, timing violations checking and reporting and glitch detection. 
    - 
   
    VHDL package Vital_Primitives,
     defining commonly used combinatorial primitives provided both as
    functions and concurrent procedures and supporting either behavioral
    or structural modeling styles, e.g. VitalAND, VitalOR, VitalMux4,
    etc. The procedure versions of the primitives support separate
    pin-to-pin delay path and GlitchOnEvent glitch detection.
    Additionally, general purpose Truth Tables and State Tables are
    specified which are very useful in defining state machines and registers. 
    - 
   
    VITAL SDF map -
    specification that defines the mapping (translation) of Standard
    Delay Files (SDF), used for support timing parameters of real
    macro-cells, to VHDL generic values. 
     
  
   MODELING SPECIFICATION
  
   The modeling specification of VITAL defines several rules for VHDL
   files to be VITAL-compliant. This covers in particular: 
  
   - 
   
    Naming conventions for timing parameters and internal signals,
    including prefixes for timing parameters, which must be used in the
    generics specifications (Example 1); 
    - 
   
    How to use the types defined in the Vital_Timing package for
    specifications of timing parameters; 
    - 
   
    Methodology of coding styles; 
    - 
   
    Two levels of compliance: level 0 for complex models described at
    higher level, and level 1, which additionally permits model acceleration. 
     
  
   A VITAL-compliant specification consists of an entity with generics
   defining the timing parameters of the ports (Example 1) and an
   architecture that can be written in one of two coding styles: either
   pin-to-pin delay style or distributed delay style. 
  
   PIN-TO-PIN DELAY MODELING STYLE
  
   An architecture that follows this style contains two main parts
   (Example 2): 
  
   - 
   
    A block called Wire_Delay, which defines input path delays between
    input ports and internal signals. This block calls the concurrent
    procedure VitalPropagateWireDelay. 
    - 
   
    A process called VitalBehavior. This process may contain declarations
    of local aliases, constants and variables. It has a very rigid
    structure and is divided into three parts: 
   
    - 
    
     Timing Checks - does calls to procedure VitalTimingCheck which is
     defined in the package Vital_Timing. 
     - 
    
     Functionality - makes one or more calls to subprograms contained in
     the Vital_Primitives package and assignments to internal temporal
     variables. No wait statements, signal assignments or control
     structures are allowed here. 
     - 
    
     Path Delay - contains a call to VitalPropagateDelay for each output signal. 
      
     
  
   DISTRIBUTED DELAY MODELING STYLE
  
   In this style the specification (ASIC cell) is composed of structural
   portions (VITAL primitives), each of which has its own delay. The
   output is an artifact of the structure, events and actual delays. All
   the functionality is contained in one block, called Vital_Netlist and
   this block may contain only calls to primitives defined in the
   Vital_Primitives package. 
  
   Examples
  
   Example 1 
  
   library IEEE; 
   use IEEE.Std_Logic_1164.all; 
   library VITAL; 
   use VITAL.Vital_Timing.all; 
   use VITAL.Vital_Timing; 
   use VITAL.Vital_Primitives.all; 
   use VITAL.Vital_Primitives; 
   entity Counter is 
     generic(tpd_ClkOut1
    : DelayType01 := (10 ns, 10 ns); 
     . . .); 
     port (Reset : in
   Std_Logic := 'U'; 
       Clk : in
   Std_logic := 'U'; 
       CntOut : out
   Std_logic_Vector(3 downto 0)); 
   end Counter; 
  
     
   This entity is a part of a VITAL-compliant specification of a
   four-bit synchronous counter with reset. Note that two libraries and
   three packages are used. In particular, multiple value logic types,
   defined in Std_Logic_1164, are standard logical types for VITAL. 
  
   The example given here specifies the propagation delay between the
   Clk input and the output number 1. The VITAL prefix tpd determines
   the timing parameter. The type used is specified in the Vital_Tming package. 
  
   Example 2 
  
   architecture PinToPin of
   Counter is 
   -- declarations of internal signals 
   begin 
   -- Input path delay 
     Wire_Delay: block 
     begin 
     -- calls to the VitalPropagateWireDelay procedure 
     Vital_Timing.VitalPropagateWireDelay (. . .); 
     . . . 
   end block; 
   -- Behavior section 
   VitalBehavior: process(. . .) 
     -- declarations 
   begin 
     -- Timing Check 
     Vital_Timing.VitalTimingCheck (. . .); 
     -- Functionality 
     Vital_Primitives.VitalStateTable (. . .); 
     -- Path Delay 
     Vital_Timing.VitalPropagatePathDelay (. . .); 
     Vital_Timing.VitalPropagatePathDelay (. . .); 
     end process VitalBehavior; 
   end PinToPin; 
  
     
   The above listed architecture PinToPin is a template of a pin-to-pin
   modeling style. All its procedure calls should be specified with
   appropriate parameters. 
  
   Example 3 
  
   architecture DistrDelay of
   Counter is 
     -- internal signals declarations 
   begin 
   -- Input path delay 
   Vital_Netlist: block 
     -- internal declarations of the block 
     begin 
     -- calls to VITAL primitives, for example 
     Vital_Primitives.VitalAND2(. . .); 
     Vital_Primitives.VitalBuf(. . .); 
     Vital_Primitives.VitalStateTable(. . .); 
     end block; 
   end DistrDelay; 
  
     
   The above listed Architecture DistrDelay is a template of a
   distributed delay modeling style. All its procedure calls should be
   specified with appropriate parameters. 
  
    
    |