CPU- VITAL Simulation

CHAPTER
17
CPU:
VITAL Simulation
The last step in the high-density FPGA design process is
to run gate-level timing simulation of the design. Figure
17-1 shows the high-density FPGA design flow. The place
and route process produces a number of files that need to
be verified before the design is implemented. The gate-
level timing simulation process verifies that the design
from the place and route process is correct from a timing
and functional point of view.
Within VHDL, this process is implemented using VITAL.
VITAL is an IEEE standard that is used for modeling accu-
rate timing at the gate level. VITAL is an acronym for the
VHDL Initiative Toward ASIC Libraries. VITAL specifies a
standard method of writing ASIC or FPGA libraries so
that timing can be back-annotated. VITAL libraries used
in concert with a VITAL-compliant VHDL simulator can
perform gate-level timing simulation of the target design.
17
Chapter Seventeen
380
The VITAL process is shown in Figure 17-2.
The place and route tools generate two VITAL-compliant simulator
input files. The first is a VHDL netlist that contains the interconnections
of all of the entities used to model the design. The second is a timing-
accurate SDF back-annotation file used to input post-route timing into
the VITAL simulation. There is a third input needed to the simulation
process. The third input is the VITAL library that describes all of the
behavior of the entities used to implement the design. In the next few

sections, we examine each of these in more detail.
Design Specification
HDL Capture
RTL Simulation
RTL Synthesis
Functional
Gate Simulation
Place and Route
Post Layout Timing
Simulation
Figure 17-1
High-Density Design
Flow.
381
CPU:Vital Simulation
VITAL Library
One of the reasons VITAL was developed was because there were no
standard methods of describing timing behavior in VHDL. With no standard
method of describing timing, there was also no standard method of
describing timing back-annotation. VHDL was also inefficient at modeling
gate behavior when compared to gate-level simulators optimized for
gate-level performance.
For all these reasons, VITAL was created to allow near gate-level
simulation performance with timing accurate models. Some of the features
available with VITAL are as follows:
■ Accurate specification of delays
—
Delays can be specified pin to
pin, be dependent on state, or specified in relation to a particular
occurrence of a condition.

Tabular
Output
Waveforms
Vital
Simulator
Place and
Route
Vital
Library
VHDL
Netlist
SDF
File
Figure 17-2
VITAL Data Flow.
■ Accurate timing check support
—
Checks include setup checks, hold
checks, pulsewidth checks, period checks, and accurate glitch
detection.
■ Many ways to specify functionality
—
Functionality can be specified
with truth tables, state tables, boolean primitives, or a behavioral
description.
All of these features give the designer the ability to create timing-
accurate FPGA or ASIC libraries.
VITAL Simulation Process
Overview
The place and route tool generates a number of output files, as we saw in

the last chapter. The VITAL simulation uses two of these files. The first
is the VHDL netlist. This is a file containing component declarations, sig-
nals, and component instantiations that connect all of the components
together with the declared signals to form the functionality of the design.
This file is read by the VITAL simulator and used to create the compo-
nent connectivity in the database.
The second file is an SDF (Standard Delay Format) file that describes the
timing for the design. For each instance in the netlist, this file contains SDF
statements that describe the delays and timing checks for the instance. This
information is used during simulation to model the timing behavior.
To build the VITAL simulation database, the simulator needs to have
a VITAL library that contains components for the target technology and
the VHDL netlist and SDF timing file from the place and route tools. The
simulator uses the netlist to instantiate the proper instances from the
VITAL library in the internal database and then apply timing to the
instances with the SDF file. Each of the instances contains a number of
generics that receive the timing information. The timing data is used
within the model to provide the correct behavior of the underlying device.
VITAL Implementation
VITAL descriptions follow a standard style and make use of standard
functions and procedures from two VITAL packages. The VITAL Timing
Chapter Seventeen
382
Package contains procedures and functions for accurate delay modeling,
timing checks, and timing error reporting. The VITAL Primitives Package
contains built-in primitives that are optimized for simulator performance.
Most VITAL-compliant simulators build the primitives package into the
simulator for optimum performance.
VITAL contains two styles of modeling that can be back-annotated with
SDF timing data for timing-accurate simulation. The first style, VITAL

level 1, uses only VITAL primitives for modeling the behavior of the
design. The second, VITAL level 0, has the capability to back-annotate
timing, but uses behavioral statements to describe the functionality of the
design. VITAL level 1 descriptions can be accelerated by VITAL-compliant
simulators because the constructs used are built into the simulator. VITAL
level 0 descriptions may not be accelerated because these descriptions use
behavioral constructs which may not be built in.
Simple VITAL Model
To understand how the VITAL modeling process works, a simple VITAL
model is examined. The model describes the behavior of a 2-input AND
gate. The symbol for the AND gate is shown in Figure 17-3.
The AND gate has two inputs,
in1
and
in2
, and an output
y
. When
modeled with VITAL, this device has an input delay on inputs
in1
and
383
CPU:Vital Simulation
in1 Input Delay
Output Delay
int2 -> y
in1
y
in2
Figure 17-3

VITAL AND Gate.
in2
, and pin-to-pin delays from input
in1
to output
y
and from input
in2
to output
y
.
Following is the VITAL model that implements the functionality of the
AND2
device:
----- CELL AND2 -----
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.VITAL_Timing.all;
library alt_vtl;
use alt_vtl.SUPPORT.all;
-- entity declaration --
entity AND2 is
generic(
TimingChecksOn: Boolean := True;
XGenerationOn: Boolean := False;
InstancePath: STRING := “*”;
tpd_IN1_Y : VitalDelayType01 := DefPropDelay01;
tpd_IN2_Y : VitalDelayType01 := DefPropDelay01;
tipd_IN1 : VitalDelayType01 := DefPropDelay01;
tipd_IN2 : VitalDelayType01 := DefPropDelay01);

port(
Y : out STD_LOGIC;
IN1 : in STD_LOGIC;
IN2 : in STD_LOGIC);
attribute VITAL_LEVEL0 of AND2 : entity is TRUE;
end AND2;
-- architecture body --
architecture AltVITAL of AND2 is
attribute VITAL_LEVEL1 of AltVITAL : architecture is
TRUE;
SIGNAL IN1_ipd : STD_ULOGIC := ‘U’;
SIGNAL IN2_ipd : STD_ULOGIC := ‘U’;
begin
---------------------
-- INPUT PATH DELAYs
---------------------
WireDelay : block
begin
VitalWireDelay (IN1_ipd, IN1, tipd_IN1);
VitalWireDelay (IN2_ipd, IN2, tipd_IN2);
end block;
--------------------
-- BEHAVIOR SECTION
--------------------
VITALBehavior : process (IN1_ipd, IN2_ipd)
Chapter Seventeen
384
-- functionality results
VARIABLE Results : STD_LOGIC_VECTOR(1 to 1) :=
VARIABLE Results : (others => ‘X’);

ALIAS Y_zd : STD_ULOGIC is Results(1);
-- output glitch detection variables
VARIABLE Y_GlitchData : VitalGlitchDataType;
begin
-------------------------
-- Functionality Section
-------------------------
Y_zd := (IN2_ipd) AND (IN1_ipd);
----------------------
-- Path Delay Section
----------------------
VitalPathDelay01 (
OutSignal => Y,
OutSignalName => “Y”,
OutTemp => Y_zd,
Paths => (0 => (IN1_ipd’last_event, tpd_IN1_Y,
Paths => (0 => (TRUE),
Paths => (1 => (IN2_ipd’last_event, tpd_IN2_Y,
Paths => (1 => (TRUE)),
GlitchData => Y_GlitchData,
Mode => DefGlitchMode,
XOn => DefGlitchXOn);
end process;
end AltVITAL;
configuration CFG_AND2_VITAL of AND2 is
for AltVITAL
end for;
end CFG_AND2_VITAL;
The model looks like standard VHDL with some different packages
included. In fact, the model is standard VHDL. The entity contains decla-

rations for the
STD_1164
packages for the signal logic types, but also con-
tains
USE
clauses for the VITAL timing package. The VITAL timing pack-
age is needed in the entity for
AND2
to provide the type declarations for
the entity generics.
The
entity
statement contains four generics that are used to pass
delay information to the model. Each of the generics has a prefix that
represents the type of the delay. Generic
tipd_in1
is an input delay for
input
in1
. Generic
tipd_in2
is an input delay for input
in2
. Generic
385
CPU:Vital Simulation
tpd_in1_y
models the pin-to-pin delay from input
in1
to output

y
. Generic
tidp_in2_y
models the pin-to-pin delay from input
in2
to output
y
.
The timing information passed to these generics comes from the SDF
file generated by the place and route tool. Each of the delays passed to
the entity is instance specific.
Each of the generics has a type associated with it that represents how
many delay values can be held. In this example, the generic contains two
values. Delay
tr01
represents the delay value when the signal changes
from a
‘0’
to
‘1’
value. Delay
tr10
represents the delay when the signal
changes from a
‘1’
to
‘0’
value.
The entity also contains other generics that control functionality of the
VITAL model. This example contains a generic called

TimingChecksOn
that controls whether or not the timing check functions in the VITAL
model are executed or not. Finally, the entity contains the input and
output ports for the model.
VITAL Architecture
The architecture for the VITAL model contains four distinct code areas.
These are the wire delay section, the timing violation section, the function
description section, and the path delay section. Not all models contain all
of these sections. Some models are purely combinational and do not need
timing check sections.
Wire Delay Section
The first section of the architecture is the wire delay section. The
AND2
architecture starts with a number of library declarations; but notice that
the architecture also uses the VITAL primitives package. After the
architecture statement, the architecture declares two local signals,
in1_ipd
and
in2_ipd
, and an attribute. The two signals are used to
delay the input signals to the entity. The delay values applied to the two
input signals represent the wiring delays to connect the physical gates
together. For instance, in Figure 17-4, gate U1 drives gates U2 and U3.
The wiring from gate U1 to gate U2 causes 8 nanoseconds of delay in
the path, but the wiring from U1 to U3 causes 10 nanoseconds of delay
in the path. With separate input delay values for each input, the wiring
delays can be modeled correctly.
Chapter Seventeen
386