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.
|