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 Attribute VitalLevel1 specifies that the VITAL model is level 1 compliant. Level 1 models are modeled only with VITAL primitives and can be accelerated. Some simulators have compliance checkers that can validate level 1 compliance. The architecture contains a block labeled WireDelay which contains the VHDL description that actually delays the input signals. The block contains a call to the VitalWireDelay procedure for each input port. The VitalWireDelay procedure delays the input ports by the value passed to the appropriate generic used in the procedure call. In this example, generic tipd_in1 is used to delay input in1 , and generic tipd_in2 is used to delay input in2 . After the wire delay section is the timing check section. This example has no timing check section because it is a purely combinational gate model. The next section is the functionality section. This section contains the statements that model the behavior of the device. This section starts with a process labeled VitalBehavior . Notice that the process is sensitive to the delayed versions of the two input signals, in1_ipd and in2_ipd . There are a number of local variables declared and a statement that performs an AND function of the two inputs. This AND function can be built into the simulator so that execution can be accelerated. The last section of the architecture starts with the VitalPathDelay procedure call. This section is the path delay section. This section schedules the new logic values calculated in the functionality section to occur after the appropriate delay. This section consists of a VitalPathDelay01 proce- dure call for each output from the entity. 387 CPU:Vital Simulation U1 U2 U3 8 ns 8 ns Figure 17-4 Wire Delay Representation. The VitalPathDelay01 procedure has a number of parameters passed to it. These parameters are used to control what kind of glitch behavior is wanted, the delays to be used, and the temporary data used to store sig- nal information. In this example, the VitalPathDelay procedure is passed the following parameters: ■ OutSignal — The signal to have the new value placed on it. ■ OutSignalName — The name of the output signal to be used in glitch reporting or error reporting. ■ OutTemp — A temporary signal used to store the current value of the signal for comparison. ■ Paths — An array used to store delay information. There is a table entry for each delay arc through the device. ■ GlitchData — A temporary storage area used to store signal state and transition information for use in calculating glitches. ■ Mode — Specifies the type of glitch behavior wanted. ■ GlitchKind — Specifies the kind of glitches generated, OnEvent or OnDetect . Flip-Flop Example In this next section, we examine another VITAL model with more com- plexity. This example shows the VITAL model for a DFF device. This device has sequential behavior and needs to have timing checks to check for illegal timing conditions: ----- CELL DFF ----- library IEEE; use IEEE.STD_LOGIC_1164.all; use IEEE.VITAL_Timing.all; use IEEE.VITAL_Primitives.all; library alt_vtl; use alt_vtl.SUPPORT.all; -- entity declaration -- entity DFF is generic( TimingChecksOn: Boolean := True; XGenerationOn: Boolean := False; InstancePath: STRING := “*”; Chapter Seventeen 388 [...]...CPU :Vital Simulation 389 tpd_PRN_Q_negedge : VitalDelayType01 := DefPropDelay01; tpd_CLRN_Q_negedge : VitalDelayType01 := DefPropDelay01; tpd_CLK_Q_posedge : VitalDelayType01 := DefPropDelay01; tsetup_D_CLK_noedge_posedge : VitalDelayType := DefSetupHoldCnst; tsetup_D_CLK_noedge_negedge : VitalDelayType := DefSetupHoldCnst; thold_D_CLK_noedge_posedge : VitalDelayType := DefSetupHoldCnst;... of the VITAL model while simulation is progressing The cell description in the preceding example is for the DFF model that we looked at earlier There are delay values for CLK to Q, PRN to Q, and CLRN to Q, and values for the setup and hold check VITAL Simulation To run the VITAL simulation, the designer first compiles the VITAL library into a simulator library The device manufacturers supply VITAL libraries... -architecture AltVITAL of DFF is attribute VITAL_ LEVEL1 of AltVITAL : architecture is TRUE; SIGNAL SIGNAL SIGNAL SIGNAL D_ipd : STD_ULOGIC := ‘U’; CLRN_ipd : STD_ULOGIC := ‘U’; PRN_ipd : STD_ULOGIC := ‘U’; CLK_ipd : STD_ULOGIC := ‘U’; begin INPUT PATH DELAYs WireDelay : block begin VitalWireDelay (D_ipd, D, tipd_D); VitalWireDelay (CLRN_ipd, CLRN, tipd_CLRN); VitalWireDelay (PRN_ipd,... delay section contains a single call to the VitalPathDelay01 procedure, which schedules output Q with the appropriate delay value To see how all of these VITAL functions and procedures are implemented, look at the VITAL packages included on the CD with the book or visit www.vhdl.org /vital SDF File The other piece of functionality needed to complete the VITAL simulation picture is the SDF back-annotation... DefSetupHoldCnst; thold_D_CLK_noedge_negedge : VitalDelayType := DefSetupHoldCnst; tipd_D : VitalDelayType01 := DefPropDelay01; tipd_CLRN : VitalDelayType01 := DefPropDelay01; tipd_PRN : VitalDelayType01 := DefPropDelay01; tipd_CLK : VitalDelayType01 := DefPropDelay01); port( Q : out STD_LOGIC; D : in STD_LOGIC; CLRN : in STD_LOGIC; PRN : in STD_LOGIC; CLK : in STD_LOGIC); attribute VITAL_ LEVEL0 of DFF : entity is... Figure 17-5 Figure 17-5 The Simulator Window CPU :Vital Simulation 397 Running the simulation through the entire process verifies the functionality of the placed and routed design To verify the timing and functionality, we need to back-annotate the timing from place and route to the simulation Back-Annotated Simulation To run timing back-annotated simulation, we don’t need to recompile We only need... supply VITAL libraries for their devices Next, the VITAL netlist is compiled to the working library, and, finally, the SDF file is read in to back-annotate the timing data into the design After these steps have been completed, the designer runs the VITAL simulation in the same manner as the RTL simulation that we ran earlier The first step is to compile the VITAL library into a simulator library so that... /u1=cpuout.sdf topconstruct This command tells the simulator to back-annotate the VITAL simulation of the CPU design with SDF file cpuout.sdf created by the place and route tools After this command has executed, the simulation is invoked, and the SDF file is back-annotated to component U1 (cpu) and simulation started Running the simulation produces the waveform shown in Figure 17-6 The back-annotated delays... CLRN, tipd_CLRN); VitalWireDelay (PRN_ipd, PRN, tipd_PRN); VitalWireDelay (CLK_ipd, CLK, tipd_CLK); end block; 390 Chapter Seventeen BEHAVIOR SECTION -VITALBehavior : process (D_ipd, CLRN_ipd, PRN_ipd, CLK_ipd) timing check results VARIABLE Tviol_D_CLK : STD_ULOGIC := ‘0’; VARIABLE TimingData_D_CLK : VitalTimingDataType := VitalTimingDataInit; functionality results VARIABLE Violation... the place and route tools To complete the simulation setup process, the final compilations needed are shown here: vcom top.vhd vcom topconstruct.vhd After these steps, the design is ready for simulation To load the design into the simulator, the following command is executed: vsim topconstruct The simulator brings up its windows and begins the simulation If the simulation is run ahead 500 nanoseconds, . values for the setup and hold check. VITAL Simulation To run the VITAL simulation, the designer first compiles the VITAL li- brary into a simulator library RTL Simulation RTL Synthesis Functional Gate Simulation Place and Route Post Layout Timing Simulation Figure 17-1 High-Density Design Flow. 381 CPU:Vital