VHDL Programming by Example phần 9 pdf

■ 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 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; 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 TRUE; end DFF; architecture body architecture AltVITAL of DFF is attribute VITAL_LEVEL1 of AltVITAL : architecture is TRUE; SIGNAL D_ipd : STD_ULOGIC := ‘U’; SIGNAL CLRN_ipd : STD_ULOGIC := ‘U’; SIGNAL PRN_ipd : STD_ULOGIC := ‘U’; SIGNAL 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, PRN, tipd_PRN); VitalWireDelay (CLK_ipd, CLK, tipd_CLK); end block; 389 CPU:Vital Simulation 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 : STD_ULOGIC := ‘0’; VARIABLE PrevData_Q : STD_LOGIC_VECTOR(1 to 6) ; VARIABLE D_delayed : STD_ULOGIC := ‘U’; VARIABLE CLK_delayed : STD_ULOGIC := ‘U’; VARIABLE Results : STD_LOGIC_VECTOR(1 to 1) := (others => ‘X’); output glitch detection variables VARIABLE Q_VitalGlitchData : VitalGlitchDataType; CONSTANT DFF_Q_tab : VitalStateTableType := ( Violation, CLRN_ipd, CLK_delayed, D_delayed, PRN_ipd, CLK_ipd ( L, L, x, x, x, x, x, L ), ( L, H, L, H, x, H, x, H ), ( L, H, H, x, H, x, x, S ), ( L, H, x, x, L, x, x, H ), ( L, H, x, x, H, L, x, S ), ( L, x, L, L, H, H, x, L ) ); begin Timing Check Section if (TimingChecksOn) then VitalSetupHoldCheck ( Violation => Tviol_D_CLK, TimingData => TimingData_D_CLK, TestSignal => D_ipd, TestSignalName => “D”, RefSignal => CLK_ipd, RefSignalName => “CLK”, SetupHigh => tsetup_D_CLK_noedge_ posedge, SetupLow => tsetup_D_CLK_noedge_ posedge, HoldHigh => thold_D_CLK_noedge_ posedge, HoldLow => thold_D_CLK_noedge_ posedge, Chapter Seventeen 390 CheckEnabled => TO_X01(( (NOT PRN_ipd) ) OR ( (NOT CLRN_ipd) ) ) /= ‘1’, RefTransition => ‘/’, HeaderMsg => InstancePath & “/DFF”, XOn => DefTimingXon, MsgOn => DefTimingMsgon ); end if; Functionality Section Violation := Tviol_D_CLK; VitalStateTable( StateTable => DFF_Q_tab, DataIn => ( Violation, CLRN_ipd, CLK_delayed, D_delayed, PRN_ipd, CLK_ipd), Result => Results, NumStates => 1, PreviousDataIn => PrevData_Q); D_delayed := D_ipd; CLK_delayed := CLK_ipd; Path Delay Section VitalPathDelay01 ( OutSignal => Q, OutSignalName => “Q”, OutTemp => Results(1), Paths => (0 => (PRN_ipd’last_event, tpd_PRN_Q_negedge, TRUE), 1 => (CLRN_ipd’last_event, tpd_CLRN_Q_negedge, TRUE), 2 => (CLK_ipd’last_event, tpd_CLK_Q_posedge, TRUE), 3 => (D_ipd’last_event, tpd_CLK_Q_posedge, TRUE)), GlitchData => Q_VitalGlitchData, Mode => DefGlitchMode, XOn => DefGlitchXOn); end process; end AltVITAL; configuration CFG_DFF_VITAL of DFF is for AltVITAL end for; end CFG_DFF_VITAL; 391 CPU:Vital Simulation [...]... in a library named alt_vtl: MAX+plus II Version 7.2 RC2 2/14 /97 Sat Oct 25 10: 59: 34 199 7 -LIBRARY IEEE; USE IEEE.std_logic_1164.all; LIBRARY alt_vtl; USE alt_vtl.VCOMPONENTS.all; ENTITY cpu IS -PORT ( -addr : OUT std_logic_vector(15 downto 0); -data : INOUT std_logic_vector(15 downto 0); -clock : IN std_logic; CPU:Vital Simulation 395 -ready : IN std_logic; -reset : IN std_logic; -rw : OUT std_logic;... However, this time, the CPU RTL description is replaced with a VITAL description of the CPU This can be accomplished by two different methods The first involves compilation order, and the second is by direct specification Remember that the last architecture compiled is used by default for an entity By compiling architecture EPF10K10TC144_a3 last, this architecture is used for entity cpu The other method is... Instrumentor The designer reads the VHDL design into the instrumentor and specifies which signals to probe and which breakpoints to enable The instrumentor generates a new VHDL description of the design with the IICE core added and connected to the appropriate places in the design Once the new VHDL description has been created, the designer synthesizes, and place and route the new VHDL description In an FPGA... 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 file This file is generated by the place CPU:Vital Simulation 393 and route tools and contains accurate timing for the device The SDF file contains timing information... of the generics in the VITAL library that need data passed to them Following is a sample SDF file: (DELAYFILE (SDFVERSION “2.1”) (DESIGN “cpu”) (DATE “10/25 /97 10: 59: 58”) (VENDOR “Altera”) (PROGRAM “MAX+plus II”) (VERSION “Version 7.2 RC2 2/14 /97 ”) (DIVIDER ) (VOLTAGE :5:) (PROCESS “typical”) (TEMPERATURE (TIMESCALE 100ps) :25:) (CELL (CELLTYPE “DFF”) (INSTANCE DFF_457) (DELAY (ABSOLUTE (IOPATH (posedge... contains two tools The Bridges2Silicon instrumentor reads the VHDL description and adds the debug core, called an Intelligent In-Circuit Emulator (IICE) to the design The Bridges2Silicon debugger communicates with the JTAG port on the target device, reads the database created by the instrumentor, and reads the original source files created by the designer At Speed Debugging Techniques 401 Instrumented... number of cells Each cell in the SDF file represents an instance in the VHDL netlist produced by the place and route tools Each cell contains the type of cell, the instance name in the netlist, and timing information to be back-annotated to the design The VITALcompliant simulator reads the SDF file and matches the generics in the VHDL source with the delay constructs in the SDF file For instance, an... device is programmed with the new device file created by place and route Debugger Once the board is powered up, and the FPGA device is programmed with the new device file from place and route, the debugger can communicate with the device through the JTAG port The debugger also reads the database file created by the Instrumentor and the original VHDL source files The instrumentor database relates the... linked This value will be specified as CPU TOPLEVEL LANGUAGE specifies the default language used to compile the design and to write out the instrumented design TOP-LEVEL LANGUAGE is specified as VHDL by clicking the VHDL radio button This is shown in Figure 18-5 Now that we have specified all the needed parameters, click the OK button, which saves the project and also compiles the project After compilation,... more future data is shown after the trigger In this example the history and future data is the same, which corresponds to the middle trigger position Waveform Display Another way to view the sample buffer data is via a waveform display In Figure 18-11 the sample buffer data are shown as a waveform The vertical At Speed Debugging Techniques 4 09 Figure 18 -9 Breakpoint Enabled on Loadl2 cursor shows the position . VCOMPONENTS, to be located in a library named alt_vtl: MAX+plus II Version 7.2 RC2 2/14 /97 Sat Oct 25 10: 59: 34 199 7 LIBRARY IEEE; USE IEEE.std_logic_1164.all; LIBRARY alt_vtl; USE alt_vtl.VCOMPONENTS.all; . accomplished by two different methods. The first involves compilation order, and the second is by direct specification. Remember that the last architecture compiled is used by default for an entity. By. file: (DELAYFILE (SDFVERSION “2.1”) (DESIGN “cpu”) (DATE “10/25 /97 10: 59: 58”) (VENDOR “Altera”) (PROGRAM “MAX+plus II”) (VERSION “Version 7.2 RC2 2/14 /97 ”) (DIVIDER .) (VOLTAGE :5:) (PROCESS “typical”) (TEMPERATURE