ANEXO V. C UESTIONARIO Y RESPUESTAS
C UESTIONARIO Y RESPUESTAS DE PROFESIONALES
SDF was originally intended for use in a chip design process. Things can be done with it that are beyond those needed for board-level simulation. In this discussion we will limit ourselves to those features that we know apply to component modeling.
As we saw in our example, SDF includes constructs for modeling both circuit delays and timing checks. All of the constructs we are about to examine have map- pings to VITAL. Those mappings are shown in later chapters.
4.2.1
Circuit Delays
Circuit delays can be either interconnect delays or path delays. SDF files describing interconnect delays are generated by (nearly all) vendor-supplied tools that gener- ate interconnect information, such as printed circuit board layout tools or signal integrity tools. We will not cover the interconnect portion of the SDF standard.
Path delays are delays within or through a component. In most cases we specify pin-to-pin path delays, but in modeling some complex parts we must also model internal delays deep inside the component.
Each delay definition we are about to study requires a set of delay values. The set is formally referred to as a delval_list. That is to say it is a list of delvaltokens.
52 Chapter 4 An Introduction to SDF
Each of these tokens consists of either one, two, or three real numbers. If the token has one number it is simply interpreted as a delay. If it has two numbers, they are taken as minimum and maximum delays. If there are three numbers, they will represent minimum, typical, and maximum delays.
The formal syntax for delval_listis as follows:
delval_list ::=
delval | delval delval | delval delval delval
| delval delval delval delval delval delval
| delval delval delval delval delval delval delval delval delval delval delval delval
The number of tokens in the delval_listcan be one, two, three, six, or twelve. For component modeling,
A single token is specified if a single value is sufficient for all transitions. Two tokens are specified for 2-state drivers with 0 Æ1, 1 Æ0 transitions. Three tokens are specified for 0 Æ1, 1 Æ0, ? ÆZ (1 or 0 to Z) transitions. Six tokens are specified for normal 3-state drivers that have 0 Æ1, 1 Æ0, 0 ÆZ,
Z Æ1, 1 ÆZ, and Z Æ0 transitions.
Twelve tokens are specified for drivers that can drive low impedance with unknown values. Memories often have this property. The transitions are 0 Æ 1, 1 Æ 0, 0 ÆZ, Z Æ1, 1 ÆZ, Z Æ0, 0 ÆX, X Æ1, 1 ÆX, X Æ0, X ÆZ, and Z ÆX. The delay section of an SDF cell description begins with the key word DELAY. Delays can be ABSOLUTEor INCREMENTAL. We will only need ABSOLUTE. A delay section might look like this:
(DELAY (ABSOLUTE
(IOPATH A Y (.440:.620:.810) (.440:.620:.810)) ))
After opening the absolute delay section we can list one or more delay defini- tions. The most commonly used definition specifies a delay from an input pin to an output pin. Its key word is IOPATH. The IOPATH key word must be fol- lowed by the names of the two ports for which the delay is being given. The order in which the ports are listed is input first then output. These are usually followed by a list of delays, as shown. The formal syntax from the standard document is
iopath_def ::=
(IOPATH port_spec port_instance { retain_def } deval_list )
retain_def ::=
(RETAIN retval_list )
In this syntax,
IOPATH is the key word. port_spec is the input port. port_instance is the output port. retain_def will be discussed shortly. delval_list is the delay data.
In our definition, RETAINspecifies the time an output port retains its previous logic value after a change at a related input, as shown in Figure 4.3.
(IOPATH ADDR0 DOUT0
(RETAIN (2:3:4) (3:4:5)) // RETAIN delays (5:10:15) (6:12:18)) // IOPATH delays
The pin-to-pin delay through a component may vary depending on the state of another pin. SDF accommodates this situation by providing the conditional path delay. The formal syntax for conditional path delay is
cond_def ::=
( COND [ qstring ] conditional_port_expr iopath_def )
Here, the fields are interpreted as follows: COND is the key word.
qstring is an optional symbolic name. Its mapping in VITAL is not well doc- umented, so we shall avoid using it.
conditional_port_expr is the description of the state dependency of the path delay. A particular conditional path delay will be used only if the condi- tion is TRUE. Only expressions using ports are legal. VITAL offers additional,
54 Chapter 4 An Introduction to SDF
addr
dout
IOPATH delay retain time
Figure 4.3 Retain time MAG04 8/18/04 3:08 PM Page 54
more flexible methods of selecting among competing path delays. The mapping of condition expressions will be covered in a later chapter.
iopath_def has the same meaning as described earlier.
Here is an example of conditional path delay excerpted from the timing file for a 74GTL1655:
(DELAY (ABSOLUTE
(COND VERC == 1 (IOPATH A0 B0 (3.0:4.5:5.1) (2.9:5.5:6.5))) (COND VERC == 0 (IOPATH A0 B0 (2.3:3.3:4.3) (2.0:3.4:4.4)))
Sometimes we need to define a delay that is internal to a component and not related to any port. This cannot be done with an IOPATHdelay. For this situation SDF provides a device delay.
Although the device delay was devised for gate-level models using distributed timing, it is also applicable in component modeling for things like expressing the refresh interval in a dynamic memory. There is an example of using device delays in a model in Chapter 6.
The formal syntax for device delays is
device_def ::=
(DEVICE [ port_instance ] delval_list )
Where the fields mean DEVICE is the key word.
port_instance is an optional field specifying the output port to which the delay will be applied.
delval_list is the delay data.
Here is an example of a device delay used in a DRAM model:
(CELL (CELLTYPE “VITALbuf” )
(INSTANCE U1/REF) (DELAY (ABSOLUTE ( DEVICE (15625) ) ) )
A complete explanation is given in Chapter 6.
4.2.2
Timing Checks
An important part of the board-level verification of your FPGA is ensuring that the timing requirements of all the components with which it interfaces are met. To do this we must build timing constraint checks into our component models. VITAL provides us with the procedures for performing the constraint checks, but SDF gives us the means to pass in the actual values.
The formal syntax for an SDF timing specification is
tc_spec ::=
(TIMINGCHECK tchk_def { tchk_def } )
where
TIMINGCHECK is the key word marking the beginning of the timing specification. Any number of tchk_def constructs can be listed in a tc_spec.
The tchk_defsyntax here is not a complete list of all the constructs available in SDF, but it lists all the constructs used in component modeling:
tchk_def ::= setup_timing_check | hold_timing_check | recovery_timing_check | removal_timing_check | skew_timing_check | bidirectional_skew_timing_check | width_timing_check | period_timing_check | nochange_timing_check setup_timing_check :: =
( SETUP port_tchk port_tchk value )
hold_timing_check
( HOLD port_tchk port_tchk value )
recovery_timing_check
( RECOVERY port_tchk port_tchk value )
removal_timing_check
( REMOVAL port_tchk port_tchk value )
skew_timing_check
( SKEW port_tchk port_tchk value )
bidirectional_skew_timing_check
( BIDIRECTSKEW port_tchk port_tchk value value )
width_timing_check
( WIDTH port_tchk value )
period_timing_check
( PERIOD port_tchk value )
nochange_timing_check
( NOCHANGE port_tchk value )
Waveforms illustrating these constraint checks are provided in Chapter 8.
56 Chapter 4 An Introduction to SDF
Figure 4.4 shows how some of these constructs appear in an SDF file.
As you may have guessed, just as conditions can be applied to an IOPATHspec- ification, so may they be applied to a timing constraint specification. The syntax is similar:
port_tchk ::=
port_spec
| ( COND [ qstring ] timing_check_condition port_spec )
where
COND is the key word
qstring is an optional symbolic name that we will not use.
timing_check_condition is the description of the state dependency of the timing check.
conditionport_spec is the input port.
Here is an example of a conditional timing check taken from the STDH1655 timing file:
(SETUP (COND CLK = = 0 A0) LEAB (2.6)) (SETUP (COND CLK = = 1 A0) LEAB (2.8))
Any port_spec can be further qualified with an edge identifier:
port_spec ::=
port_instance | port_edge port_edge ::=
( edge_indentifier port instance )
A list of legal edge identifiers is given in Chapter 10. Because VITAL also pro- vides the capability to specify edge conditions for timing checks, we really only need to use edge identifiers in SDF to specify separate values for a constraint, as illustrated here:
(WIDTH (posedge CLK) (3.0)) (WIDTH (negedge CLK) (3.5))
The subject of timing constraints in component models is discussed in greater detail in Chapter 8. 4.2 SDF Capabilities 57 (SETUP DQ0 CLK (1.0)) (HOLD DQ0 CLK (1.0)) (RECOVERY CLRNeg CLK (2.0)) (WIDTH (posedge DQS) (2.6)) (PERIOD (posedge CLK) (7.5))
4.3
Summary
SDF is a convenient way to annotate timing values into a simulation. It is supported by both VHDL/VITAL and Verilog simulators. SDF has the capability to annotate circuit delays as pin-to-pin delays or as device delays. It is also able to annotate values for a variety of timing constraint checks. In both cases conditions can be included to allow multiple values to be specified and have the correct value selected by the simulator.
58 Chapter 4 An Introduction to SDF