Path Delay Procedures

The VitalPathDelay procedure comes in three flavors: VitalPathDelay, VitalPathDelay01, and VitalPathDelay01 Z. Each supports

• Transition-dependent delays • Path delay selection

• User-controlled glitch detection • User-controlled ‘X’generation • User-controlled error reporting • Output signal scheduling • and more

Of the three varieties of VPDs, VitalPathDelayis for simple path delays of type VitalDelayTypethat are not transition dependent. The VitalPathDelay01pro- cedure is for delays of type VitalDelayType01that require different rise/fall tran- sition delay values. Finally, VitalPathDelay01Zis for scheduling path delays on signals for which there is a transition to ‘Z’. All three procedures take the same set of parameters,

OutSignal, output port or internal signal to be driven. Type std_logic. OutSignalName, name of OutSignal to use when generating messages. Type string OutTemp, the value to be applied to the output; computed in the functionality section (_zd). This is an input of type std_ulogic.

76 Chapter 6 Modeling Delays

6.4 Path Delay Procedures 77

--- -- VITALBehavior Process

--- VITALBehavior1 : PROCESS(A_ipd, B_ipd, DIR_ipd, ENeg_ipd)

-- Functionality Results Variables VARIABLE A_zd : std_ulogic := ‘X’; VARIABLE B_zd : std_ulogic := ‘X’; VARIABLE Aen_int : std_ulogic := ‘X’; VARIABLE Ben_int : std_ulogic := ‘X’; -- Output Glitch Detection Variables VARIABLE A_GlitchData : VitalGlitchDataType; VARIABLE B_GlitchData : VitalGlitchDataType; BEGIN

--- -- Functionality Section

--- Aen_int := VitalAND2(a=> NOT(DIR_ipd), b => NOT(ENeg_ipd));

Ben_int := VitalAND2(a=> DIR_ipd, b => NOT(ENeg_ipd)); A_zd := VitalBUFIF1 (data => B_ipd, enable => Aen_int ); B_zd := VitalBUFIF1 (data => A_ipd, enable => Ben_int );

--- -- Path Delay Section

--- VitalPathDelay01Z ( OutSignal => A, OutSignalName => "A", OutTemp => A_zd, Paths => ( 0 => (InputChangeTime => B_ipd’LAST_EVENT, PathDelay => VitalExtendToFillDelay(tpd_B_A), PathCondition => (Aen_int = ‘1’)), 1 => (InputChangeTime => DIR_ipd’LAST_EVENT, PathDelay => tpd_DIR_A, PathCondition => TRUE ), 2 => (InputChangeTime => ENeg_ipd’LAST_EVENT, PathDelay => tpd_ENeg_A, PathCondition => TRUE ) ), GlitchData => A_GlitchData ); VitalPathDelay01Z ( OutSignal => B, OutSignalName => "B", OutTemp => B_zd, Paths => ( 0 => (InputChangeTime => A_ipd’LAST_EVENT, PathDelay => VitalExtendToFillDelay(tpd_A_B), PathCondition => (Ben_int = ‘1’)), 1 => (InputChangeTime => DIR_ipd’LAST_EVENT, PathDelay => tpd_DIR_B, PathCondition => TRUE ), 2 => (InputChangeTime => ENeg_ipd’LAST_EVENT, PathDelay => tpd_ENeg_B, PathCondition => TRUE ) ), GlitchData => B_GlitchData ); END PROCESS;

Paths, a list of paths of VitalPathArrayType. Each path gives the delays and conditions for driving the output.

DefaultDelay, delay used when no delay path applies. If absent, defaults to zero.

IgnoreDefualtDelay, a boolean. If FALSE, the default delay will be used. If TRUE, no event will be visible if no paths are selected. If absent, defaults to FALSE.

GlitchData, a variable (local to the behavior process) used by the VPD to store data required for glitch detection. Must not be referenced elsewhere.

MsgOn, control for message generation on glitch detection. When TRUE, glitches are reported. Defaults to TRUE.

MsgSeverity, the severity level at which the message is reported.

XOn, glitch ‘X’generation control. When TRUE, ‘X’s are scheduled for glitches. If absent, defaults to TRUE.

Mode, selects the type of glitch detection. Value should be one of OnEvent (default), OnDetect, VitalInertial, on VitalTransport(described later in this chapter).

OutputMap, an array that allows mapping of output strength. For Vital- PathDelay01Zonly.

NegPreemptOn, if TRUE, enables negative preemptive glitch handling. RejectFastPath, if TRUE, enables rejection of fast signal path.

Some of the parameters listed require further explanation and are covered in later sections.

Paths

The Pathsparameter is an array of records. There may be one or more elements in the array. The order of the elements is not significant. Each record is made up of three elements:

InputChangeTime, the amount of time since the input changed. This should be of the form <signal>‘LAST_EVENT.

PathDelay, a VitalDelayType, VitalDelayType01, or VitalDelayType01Z value specifying the delay time (from a specific input). Most often, this will be a tpdgeneric.

Condition, a boolean expression controlling whether this delay path is to be considered.

Three examples of paths taken from three FMF models are displayed in Figure 6.5. The VitalDelayTypein the PathDelayelement of the record must be consis- tent with the VITAL path delay procedure call. However, when using Vital-

78 Chapter 6 Modeling Delays

PathDelay01Z, the function VitalExtendtoFillDelay may be employed to extend a constant of VitalDelayTypeor VitalDelayType01 to VitalDelay- Type01Z, as demonstrated in the third example.

DefaultDelay

If none of the paths are selected and IgnoreDefaultDelay is FALSE, the DefaultDelayis used for the output delay. If no default value is supplied by the model, a zero delay will be used. In a properly written model, every path and con- dition is anticipated, so use of the DefaultDelayshould never happen. However, when testing a model, a zero delay can be very handy because it signals that no path was selected and an unanticipated condition occurred, an indication that the model is not yet perfected.

IgnoreDefualtDelay

If IgnoreDefualtDelayis set to TRUEand no path is selected, the output event is scheduled for TIME’HIGH. From a simulation perspective, this is the end of time. If there is a requirement that transitions not covered by any of the paths never reach the output port, this is the way to do it.

MsgOn

The MsgOn parameter controls the emission of messages in the event of a glitch detection. In most cases you will want to see these messages. However, should you prefer to ignore them, the value of this parameter can be set through generics and controlled on an instance-by-instance basis or for the entire schematic.

MsgSeverity

Messages emitted by the VPD have a severity level. Most simulators can be config- ured to pause or abort a simulation based on the severity level of a message.

6.4 Path Delay Procedures 79

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) 0 => (InputChangeTime => CLK_ipd’LAST_EVENT, PathDelay => tpd_CLK_Q,

PathCondition => ((CLRint = ‘0’) AND (PREint = ‘0’))),

0 => (InputChangeTime => A_ipd’LAST_EVENT,

PathDelay => VitalExtendToFillDelay(tpd_A_Y), PathCondition => TRUE),

Alternatively, most simulators can be configured to hide messages of low severity. The MsgSeverityparameter allows the user to set the severity level of messages emitted upon glitch detection. The value must be note, warning, error, or failure. If no value is supplied, the value will default to warning.

XOn

If a glitch occurs on an input, the VPD will, by default, schedule an ‘X’ on the output. Although this may be a good thing for regression tests, the ‘X’ propaga- tion can be inconvenient during initial debug. Fortunately, it is easy to control through the XOngeneric routinely included in your model entity.

Mode

Given that a glitch is detected and XOn is TRUE, there are four modes for propa- gating the ‘X’: VitalInertial, VitalTransport, OnEvent, and OnDetect. They are shown in Figure 6.6.

80 Chapter 6 Modeling Delays

in in out(VitalInertial) out(VitalTransport) out(OnEvent) out(OnDetect) A 1 2 9 8 5 13 19 20 Negative Preemptive Behavior Positive Preemptive Behavior 14 15 B B A out tr_⫽4, tf_⫽6

Figure 6.6 The four glitch propagation types MAG06 8/18/04 3:13 PM Page 80

VitalInertialand VitalTransportare identical to VHDL inertial and trans- port modes. If either of these modes is selected, glitches will not be detected. Oth- erwise if the duration of an input pulse is less than the propagation delay for that pulse, a glitch is detected at the end of the pulse. OnEventand OnDetectare special glitch handling modes. OnEvent outputs ‘X’ from the time an output event is scheduled. OnDetectmode outputs ‘X’from the time the glitch is detected (when the glitch ends). “A” is the first scheduled event, “B” is the second scheduled event.

NegPreemptOn

In Figure 6.6, the buffer has a longer delay for a falling output than for a rising one. Therefore, the first positive going glitch has its pulse width extended. The second glitch shown, with its negative going pulse, would normally produce no output. This is because the shorter delay of the rising edge would preempt and thus cancel the falling edge. That is positive preemption. If we are concerned with such pulses and want them to cause ‘X’outputs, we can set the NegPreemptOnparam- eter to TRUEin the VitalPathDelayprocedure call.

RejectFastPath

In the component illustrated in Figure 6.7, both the clock and the output enable are causing a ‘1’to be scheduled on pin Q. However, the propagation delay for the output enable, OE, is longer than the delay for the clock. If RejectFastPath is FALSE, Q will transition from ‘Z’to ‘1’after a delay of 4. If RejectFastPath is TRUE, Q will transition from ‘Z’to ‘1’after a delay of 8. In most cases, 8 more closely models the actual component. It is important to note that RejectFast- Pathdoes not work with simultaneous inputs.

OutputMap

The output type of a VPD is std_logic. The part you are modeling may not be capable of driving the full range of values supported by std_logic. For example, the component being modeled may have an open collector output. In such a case the OutputMapparameter can be used to modify an output value before scheduling.

OutputMap => “UX0ZZWLZ-”;

This statement will cause any ‘1’ or ‘H’ computed result to be transformed to ‘Z’. This is done by a simple positional mapping between the VitalDefault- OutputMapand the user-defined map:

UX01ZWLH- --VitalDefaultOutputMap UX0ZZWLZ- --user defined map

Note that the OutputMapparameter is available only in the VitalPathDelay01Z procedure. Also note that because the transformation takes place before

scheduling, the delay chosen is based on the new transition values, in this case 0 ->Z rather than 0 ->1.