Backannotating Path Delays

The VITAL standard is strict regarding how timing generics are named but more relaxed about how they are used. Taking advantage of this can result in some economies in certain types of models and provide utility in others.

Most components can have multiple delay paths described by a single timing specification. The data sheet for a 2-input nand gate will usually state the same delay from either input to the output. There is no need to write separate generics for each input and then backannotate identical values to both of them. A single generic will do. This is all the more true for a model with a single clock and a 16-bit output bus. If all bits have the same delay specification, a single generic will do.

A more interesting case is when a component exhibits different delays based on an internal state. This frequently is true for synchronous DRAMs, which can be pro- grammed for different CAS latencies. A CAS latency of 3 provides an output with a shorter delay relative to the clock than a CAS latency of 2, but with a three-clock- cycle latency. A CAS latency of 2 means there will be a longer delay relative to the clock but only a two-clock-cycle latency.

In the km432s2030 model, the two sets of delays are brought in using two tpd generics:

-- tpd delays

tpd_CLK_DQ2 : VitalDelayType01Z := UnitDelay01Z; tpd_CLK_DQ3 : VitalDelayType01Z := UnitDelay01Z;

They are backannotated from two SDF IOPATHstatements:

(DELAY (ABSOLUTE

(IOPATH CLK DQ2 (3 : 6 : 8) (3 : 6 : 8) (3 : 6 : 8) (3 : 6 : 8) (3 : 6 : 8) (3 : 6 : 8)) (IOPATH CLK DQ3 (2 : 4 : 6) (2 : 4 : 6) (2 : 4 : 6) (2 : 4 : 6) (2 : 4 : 6) (2 : 4 : 6)) ))

Any of the DQ ports could have been used in the generics and SDF, but it is easy to remember DQ2and DQ3are for CAS latencies of 2 and 3.

The model incorporates a signal called CAS_Latthat gets its value from a pro- grammable register. The user (of the component or the model) configures the memory by programming this and other registers. In the model, the VPD uses CAS_Latas a condition in selecting the path delays for the output bus.

A path delay procedure call that uses the value of an internal register to select a path is shown in Figure 6.10.

If you are trying to write compatible VHDL and Verilog models of components, be warned that these tricks will not translate to Verilog. The specification of multiple path delay values in Verilog requires the use of conditional path delay

88 Chapter 6 Modeling Delays

generics (described in Chapter 10). However, those may not depend on internal states so they will not work for this example.

6.9

Interconnect Delays

Interconnect delays represent the time it takes a signal transition to propagate from one component to another through the copper traces on a printed circuit board or through other media. As components get faster and clock cycle times get shorter, these interconnect delays become more important to the correct timing of our designs.

On a PCB, the delay is dependent on the length of the trace between the driving and receiving pins, the construction of the board, the materials from which it is built, and the signaling system employed. As a board is designed, progressively more accurate delay values can be extracted. Before component placement, zero delays are assumed. After component placement, delays can estimated based on manhattan distances. After routing the board, delays can be estimated based on the actual length of the interconnect. For the most accurate analysis, a signal integrity analyzer in employed. It uses analog models of the drivers and receivers as well as any terminators to determine the time from when a driver begins to change state to when the receiver switches. It can take into account capacitive loads, transmis- sion line reflections, and series and parallel terminations.

Any good PCB layout or signal integrity tool should be capable of extracting interconnect delays and writing them to an SDF file. In the SDF file they will be

6.9 Interconnect Delays 89

--- -- Path Delay Process

--- DataOutBlk : FOR i IN 31 DOWNTO 0 GENERATE

DataOut_Delay : PROCESS (D_zd(i))

VARIABLE D_GlitchData:VitalGlitchDataArrayType(31 Downto 0); BEGIN VitalPathDelay01Z ( OutSignal => DataOut(i), OutSignalName => "Data", OutTemp => D_zd(i), Mode => OnEvent, GlitchData => D_GlitchData(i), Paths => ( 1 => (InputChangeTime => CLKIn’LAST_EVENT, PathDelay => tpd_CLK_DQ2, PathCondition => CAS_Lat = 2), 2 => (InputChangeTime => CLKIn’LAST_EVENT, PathDelay => tpd_CLK_DQ3, PathCondition => CAS_Lat = 3) ) ); END PROCESS; END GENERATE;

expressed in an INTERCONNECTstatement. In VITAL it is mapped to a tipdgeneric. As seen in Chapter 5, the delay is applied to an input pin. It must be applied to an input because VHDL (or Verilog for that matter) has no way to simulate a wire. A WireDelay block delays the input signal by the value in the tipd generic and updates a new internal (_ipd) signal for use throughout the model.

As long as there is only one driver on a net, there can be any number of receivers, and interconnect delays remain straightforward. However, when there is more than one driver on a net, the situation becomes more complex. This is called a multi- source interconnect delay. SDF has no difficulty expressing independent delays from multiple drivers to multiple receivers.

VITAL defines two mechanisms for dealing with multisource delays. In one sce- nario, the simulator’s SDF annotator picks one of the delay values. The simulator may allow the user to select the minimum, maximum, or last delay in the list. In the other scenario, the simulator accepts all the delays and puts them into an array. Each time an event is detected at an input port, the simulator determines the source driver. It then applies the correct delay for that driver through the WireDelay block.

Which capabilities you get depends on which simulator you buy. Read your manuals for instructions on how to control backannotation of multisource inter- connect delays.

6.10

Summary

There are two methods of delay modeling in VITAL. They are distributed delays and pin-to-pin delays. For most models, pin-to-pin delays are preferred because they are easier, more flexible, and allow greater control over glitch handling and path selection.

The VITAL path delay procedures are used to implement output delays. They are usually called from within the process that computes the output values whenever practical. In most cases, using VPDs is preferred over modeling with distributed delays. For modeling components with buses they may be embedded in a generate statement. Multiple VPDs may read the same path delay generic, reducing the size of the timing and SDF files required.

Signal assignments or concurrent VITAL procedure calls may be used to drive multiple identical outputs from a single VitalPathDelayprocedure call. VITAL models may use an internal signal or variable in the selection of a path delay.

Interconnect delays are the physical delay associated with a printed circuit board (or other) implementation. Most PCB tools provide some means of generating an SDF file for backannotation.

Whenever a model requires a timing value that is not directly associated with a pin pair, a device delay may be used. They are very flexible and can be fit to almost any need.

90 Chapter 6 Modeling Delays

7

VITAL Tables

One of the strengths of Verilog is its user-defined primitives. The VITAL standard brings similar capability to VHDL. VITAL tables can be used to model a variety of combinatorial and state-dependent behaviors.

In the early 1990s, the VITAL team was formed and tasked with finding a way to improve the gate-level simulation performance of VHDL so it could compete with Verilog. In performing this mandate, they were not shy about borrowing from Verilog’s strengths. One of the features they borrowed was Verilog’s UDPs. The UDP has been a useful tool for Verilog model writers since its inception because it gives the writer the ability to concisely define the behavior of small digital cir- cuits such as gates, multiplexers, decoders, and counters. The result was VITAL truth tables and VITAL state tables. Truth tables and state tables are defined in the

VITAL_Primitivespackage.

In the VITAL2000 revision, the use of tables has been extended to include mod- eling static memories.