Using Timing Constraint Checks in VITAL Models

Anatomy of a VITAL Model

8.2 Using Timing Constraint Checks in VITAL Models

Adding timing constraint checks to VITAL models is a straightforward process. It begins with adding the timing generics that are needed for the particular model to the entity. Generic names are based on the formulae given in Chapter 5.

Timing checks are always called from within a process. Any signal referenced by a timing check must appear in the sensitivity list of that process. Most compilers will check this for you, but if somehow a signal is missed, incorrect results are likely to be given. Within the process certain variables must be declared, depending on which timing checks are being used. Those variables will be described later, along with the timing check procedure calls.

Timing checks have their own section within a VITAL process. They come after the declaration of variables but before any functional description. Each process may have its own timing check section. This section exists entirely within an IFclause:

IF (TimingChecksOn) THEN ...

-- All timing check code ...

END IF;

The execution of all the timing checks may be controlled through the TimingChecksOn generic. Its value can, if desired, be set on an instance-by- instance basis for a design being simulated. This could be useful if you are con- centrating on a section of your design and would like to reduce the number of messages from the simulator regarding other sections.

In Free Model Foundry models, the TimingChecksOngeneric defaults to FALSE. This is because most designs are first simulated without timing to detect basic errors in logic, then simulated with timing to look for more subtle errors. Defaulting to FALSEmeans the value must be changed once during the design cycle rather than twice. Each timing check procedure performs its specified check and returns a parameter value indicating whether a constraint violation occurred. These values are the only output of the timing section. It is common practice to ORthe various outputs together into a single term.

VARIABLE Violation : X01 := ‘0’; ...

Violation := Tviol_D_CLK OR Pviol_CLK OR Pviol_CLRint;

The violation variable may then be used elsewhere with the model.

There are four types of timing constraint checks in VITAL2000: setup/hold, period/pulsewidth, recovery/removal, and skew checks.

8.2.1 Setup/Hold Checks

The VitalSetupHoldCheckprocedure checks that its TestSignal(data) is stable during a specified period before and after the active transition of its RefSignal

108 Chapter 8 Timing Constraints

(clock), as illustrated in Figure 8.1. The timing constraint values are specified through generics. This check is usually required for any component model with registered or latched inputs. Real components can produce unpredictable outputs when setup and hold requirements are not met. A good simulation model will warn the user if a hazard exists.

Use of the VitalSetupHoldCheck procedure requires the declaration of two variables for each time it is referenced. The variables are used for timing data storage and for the violation flag output.

-- Timing Check Variables

VARIABLE Tviol_D_CLK : X01 := ‘0’;

VARIABLE TD_D_CLK : VitalTimingDataType;

A VitalSetupHoldCheckprocedure call appears in Figure 8.2.

The procedure call in Figure 8.2 will test that D_ipd, the delayed data signal, is stable for the period tsetup_D_CLKbefore the rising edge of CLK_ipd, the delayed clock signal, and for the period thold_D_CLKafter the rising edge of CLK_ipd. In the example,

CheckEnabled => TRUE,

8.2 Using Timing Constraint Checks in VITAL Models 109

error region

tsetup thold

TestSignal

RefSignal

Figure 8.1 Setup/hold check

VitalSetupHoldCheck ( TestSignal => D_ipd, TestSignalName => “D_ipd”, RefSignal => CLK_ipd, RefSignalName => “CLK_ipd”, SetupHigh => tsetup_D_CLK, SetupLow => tsetup_D_CLK, HoldHigh => thold_D_CLK, HoldLow => thold_D_CLK, CheckEnabled => TRUE, RefTransition => ‘/’,

HeaderMsg => InstancePath & “/std534”, TimingData => TD_D_CLK,

XOn => XOn, MsgOn => MsgOn, Violation => Tviol_D_CLK );

causes this check to always be enabled. Otherwise, an expression could be used to cause execution of the check to depend on some dynamic condition. One common condition under which timing checks are disabled is an inactive chip enable.

The parameters to the VitalSetupHoldCheckprocedure are as follows:

Parameters of Mode IN

TestSignal, the value of the test signal. The procedure is overloaded for TestSignal to be either std_logicor std_logic_vector. It should be a delayed input signal. TestSignalName, the name of the test signal. It is of type STRINGand will be used in any messages generated by the procedure. You should supply a name the user will recognize.

TestDelay, not shown. This is the model’s internal delay associated with TestSignal. It is used only in models having negative timing constraints. It is of type TIME. If a value is not provided, it defaults to zero.

RefSignal, the value of the reference signal. It is of type std_logic. It should be a delayed input signal.

RefSignalName, the name of the reference signal. It is of type STRINGand will be used in any messages generated by the procedure. You should supply a name the user will recognize.

RefDelay, not shown. This is the model’s internal delay associated with RefSignal. It is used only in models having negative timing constraints. It is of type TIME. If a value is not provided, it defaults to zero.

SetupHigh, the minimum time duration before the active transition of RefSignalfor which transitions of TestSignalare allowed to proceed to the “1” state without causing a setup violation. It is of type TIME and usually gets its value from a tsetupgeneric. If a value is not provided, it defaults to zero. SetupLow, the minimum time duration before the active transition of Ref- Signalfor which transitions of TestSignalare allowed to proceed to the “0” state without causing a setup violation. It is of type TIME and usually gets its value from a tsetup generic. If a value is not provided, it defaults to zero. Because some components may have asymterical setup constraints, separate SetupHigh and SetupLow parameters are provided.

HoldHigh, the minimum time duration after the active transition of Ref- Signalfor which transitions of TestSignalare allowed to proceed to the “1” state without causing a setup violation. It is of type TIME and usually gets its value from a tholdgeneric. If a value is not provided, it defaults to zero. HoldLow, the minimum time duration after the active transition of RefSignal for which transitions of TestSignal are allowed to proceed to the “0” state

110 Chapter 8 Timing Constraints

without causing a setup violation. It is of type TIME and usually gets its value from a tholdgeneric. If a value is not provided, it defaults to zero. Because some components may have asymterical hold constraints, separate HoldHigh and HoldLow parameters are provided.

RefTransition, the active transition of RefSignal. It is of type VitalEdge- SymbolType.

HeaderMsg, text that will accompany any assertion messages produced. It is of type STRING. It should, at a minimum, help the user determine the origin of the message. Additional information may be added.

XOn, a BOOLEAN that controls the violation output parameter. If TRUE, the output parameter is set to ‘X’in the event of a violation. Otherwise, violation is always ‘0’. If a value is not provided, it defaults to TRUE. This parameter could be used to allow execution of the procedure while disabling the Violation output.

MsgOn, a BOOLEAN that controls the emission of violation messages. If TRUE, setup and hold violation messages will be generated. Otherwise no messages are generated, even upon violations. If a value is not provided, it defaults to TRUE. MsgSeverity, not shown. Severity level for the assertion. It is of type SEVER- ITY_LEVEL. It can be used to control message display and simulation execution. If a value is not provided, it defaults to WARNING. The simulator may allow masking of low-severity messages or pausing or aborting simulation in the event of a high-severity message.

EnableSetupOnTest, not shown. If FALSEat the time that the TestSignal signal changes, no setup check will be performed. It is of type BOOLEAN. If a value is not provided, it defaults to TRUE.

EnableSetupOnRef, not shown. If FALSEat the time that the RefSignalsignal changes, no setup check will be performed. It is of type BOOLEAN. If a value is not provided, it defaults to TRUE.

EnableHoldOnTest, not shown. If FALSE at the time that the TestSignal signal changes, no hold check will be performed. It is of type BOOLEAN. If a value is not provided, it defaults to TRUE.

EnableHoldOnRef, not shown. If FALSEat the time that the RefSignalsignal changes, no hold check will be performed. It is of type BOOLEAN. If a value is not provided, it defaults to TRUE.

Parameters of Mode INOUT

TimingData, an information storage area for the procedure. It is used internally to detect reference edges and record the time of the last edge. It is of type VitalTimingDataType. It must be declared but must not be used outside the procedure.

Parameters of Mode OUT

Violation, the violation flag returned. It is of type X01.

In this list, note that CheckEnabled enables or disables the entire procedure. In VITAL2000, the parameters EnableSetupOnTest, EnableSetupOnRef, EnableHoldOnRef, and EnableHoldOnTest were added to allow more precise control over which checks are performed and when. They can all take their values from expressions based on control signals, state, or register values.

8.2.2 Period/Pulsewidth Checks

The VitalPeriodPulseCheckprocedure has two functions. It tests the TestSig- nalfor maximum periodicity (1/frequency) and for minimum pulse width for ‘0’ and ‘1’values. It is illustrated in Figure 8.3.

Use of the VitalPeriodPulseCheckprocedure requires the declaration of two variables for each use of the procedure. The variables are used for timing data storage and for the violation flag output.

VARIABLE Pviol_CLK : X01 := ‘0’;

VARIABLE PD_CLK : VitalPeriodDataType := VitalPeriodDataInit;

A VitalPeriodPulseCheckprocedure call appears in Figure 8.4.

The procedure call in Figure 8.4 will test that CLK_ipdhas a minimum period of tperiod_CLK_posedge, during which it is high for at least tpw_CLK_posedge and low for at least tpw_CLK_negedge. This check as shown is always enabled.

This procedure uses several of the same parameter names and type as the Vital- SetupHoldCheckprocedure, plus some new ones. Together, they are as follows:

112 Chapter 8 Timing Constraints

tpw_hi tperiod

tpw_low TestSignal

Figure 8.3 Period/pulsewidth check MAG08 8/18/04 3:01 PM Page 112

Parameters of Mode IN

TestSignal, the value of the test signal. For this procedure TestSignalmust be std_logic. It should be a delayed input signal.

TestSignalName, the name of the test signal. It is of type STRINGand will be used in any messages generated by the procedure. You should supply a name the user will recognize.

Period, the minimum period allowed between consecutive rising (‘P’) or falling (‘F’) transitions. It is of type TIME. If a value is not provided, it defaults to zero.

PulseWidthHigh, the minimum time allowed for a high (‘1’or ‘H’) pulse. It is of type TIME. If a value is not provided, it defaults to zero.

PulseWidthLow, the minimum time allowed for a low (‘0’or ‘L’) pulse. It is of type TIME. If a value is not provided, it defaults to zero.

CheckEnabled, an expression of type BOOLEAN. A check is performed if TRUE. If a value is not provided, it defaults to TRUE. This parameter enables or disables the entire procedure call. Expressions may be used to make execution of the procedure dependent on the state of one or more pins, internal registers, or states. HeaderMsg, text that will accompany any assertion messages produced. It is of type STRING. It should, at a minimum, help the user determine the origin of the messsage. Additional information may be supplied.

XOn, a BOOLEANthat controls the violation output parameter. If TRUE, the output parameter is set to ‘X’in the event of a violation. Otherwise, violation is always ‘0’. If a value is not provided, it defaults to TRUE. This parameter could be used to allow execution of the procedure while disabling the Violation output.

8.2 Using Timing Constraint Checks in VITAL Models 113

VitalPeriodPulseCheck ( TestSignal => CLK_ipd, TestSignalName => “CLK_ipd”, Period => tperiod_CLK_posedge, PulseWidthHigh => tpw_CLK_posedge, PulseWidthLow => tpw_CLK_negedge, CheckEnabled => TRUE,

HeaderMsg => InstancePath & “/std534”, PeriodData => PD_CLK,

XOn => XOn, MsgOn => MsgOn, Violation => Pviol_CLK );

MsgOn, a BOOLEAN that controls the emission of violation messages. If TRUE, setup and hold violation messages will be generated. Otherwise no messages are generated, even upon detection of violations. If a value is not provided, it defaults to TRUE.

MsgSeverity, not shown. It is the severity level for the assertion. It is of type SEVERITY_LEVEL. It can be used to control message display and simulation execution. If a value is not provided, it defaults to WARNING. The simulator may allow masking of low-severity messages or pausing or aborting simulation in the event of a high-severity message.

Parameters of Mode INOUT

PeriodData, an information storage area for the procedure. It is used internally to detect reference edges and record the pulse and period times. It is of type VitalPeriodDataType. It must be declared and initialized to VitalPeriod- DataInitbut must not be used outside this procedure.

Parameters of Mode OUT

Violation, the violation flag returned. It is of type X01.

Periodis the minimum allowed time for a full cycle of the TestSignal. It cor- responds to tperiod in Figure 8.2 and is used when TestSignalis a clock or other periodic signal. For nonperiodic signals, such as reset, Periodis omitted. PulseWidthHigh and PulseWidthLow correspond to tpw_hiand tpw_low in Figure 8.3. They represent the minimum allowed time for a high or low pulse, respectively.

8.2.3 Recovery/Removal Checks

The VitalRecoveryRemovalCheckprocedure is used to test for the presence of a recovery or removal violation on the TestSignalwith respect to the correspond-

114 Chapter 8 Timing Constraints

active

trecovery tremoval

inactive

TestSignal

RefSignal

Figure 8.5 Recovery/removal check MAG08 8/18/04 3:01 PM Page 114

ing RefSignal, as illustrated in Figure 8.5. The most common use for this is to check for the timely deassertion of the Clear signal prior to arrival of a Clock edge on a resetable flip-flop.

As always, the use of the VitalRecoveryRemovalCheckprocedure requires the declaration of two variables for each reference. The variables are used for timing data storage and for the violation flag output.

VARIABLE Rviol_CLRNeg_CLK : X01 := ‘0’;

VARIABLE TD_CLRNeg_CLK : VitalTimingDataType;

A VitalRecoveryRemovalCheckprocedure call appears in Figure 8.6.

The procedure call in Figure 8.6 will test that CLRintis inactive for the period trecovery_CLRNeg_CLKbefore the active edge of CLK_ipd. This check, as written, is always enabled.

The parameters to the VitalRecoveryRemovalCheckprocedure are as follows:

Parameters of Mode IN

TestSignal, the value of the test signal. The procedure is overloaded for Test- Signalto be either std_logicor std_logic_vector. It should be a delayed input signal (_ipd).

TestSignalName, the name of the test signal. It is of type STRINGand will be used in any messages generated by the procedure. You should supply a name the user will recognize.

TestDelay, not shown. This is the model’s internal delay associated with TestSignal. It is only used in models having negative timing constraints. It is of type TIME. If a value is not provided, it defaults to zero.

RefSignal, the value of the reference signal. It is of type std_logic. It should be a delayed input signal.

8.2 Using Timing Constraint Checks in VITAL Models 115

VitalRecoveryRemovalCheck ( TestSignal => CLRint, TestSignalName => “CLRint”, RefSignal => CLK_ipd, RefSignalName => “CLK_ipd”, Recovery => trecovery_CLRNeg_CLK, ActiveLow => TRUE, CheckEnabled => TRUE, RefTransition => ‘\’,

HeaderMsg => InstancePath & “/std174”, TimingData => TD_CLRNeg_CLK,

XOn => XOn, MsgOn => MsgOn,

Violation => Rviol_CLRNeg_CLK );

RefSignalName, the name of the reference signal. It is of type STRINGand will be used in any messages generated by the procedure. You should supply a name the user will recognize.

Recovery, the minimum time the asynchronous TestSignal must be not asserted prior to a reference edge on RefSignal. It is of type TIME and if not provided, defaults to zero.

Removal, not shown. This is the minimum time the asynchronous TestSig- nal, if already asserted, must remain asserted after a reference edge on RefSig- nal. It is of type TIMEand if not provided, defaults to zero.

ActiveLow, a flag to indicate if TestSignalis asserted when low (‘0’). FALSE indicates that TestSignal is asserted when it has a value ‘1’. It is of type BOOLEAN. If a value is not provided, it defaults to TRUE.

RefTransition, the active transition of RefSignal. It is of type VitalEdge- SymbolType.

HeaderMsg, text that will accompany any assertion messages produced. It is of type STRING. It should, at a minimum, help the user determine the origin of the messsage. Additional information may be supplied.

In document ASIC and FPGA Verification A Guide To Component Modeling pdf (Page 129-142)