CONCLUSIONES Y REFLEXIONES FINALES

The negative constraint block is also called the signal delay block. It is used in models with negative timing constraints. Because a component can have a nega- tive timing constraint only if a signal has an internal delay, we can model such a component by implementing a similar internal delay. This is done using calls to VitalSignalDelay. A timing diagram illustrating negative setup and hold con- straints is given in Chapter 11.

A schematic of a component that would have a VitalSignalDelayis shown in Figure 5.5. There may be at most one signal delay block in a VITAL architec- ture, and it must have the label SignalDelay. An example of a signal delay block is shown in Figure 5.6. A signal delay block contains exactly one call to

5.2 Level 1 Guidelines 65 BEGIN --- -- Wire Delays --- WireDelay : BLOCK BEGIN

w_1: VitalWireDelay (D1_ipd, D1, tipd_D1); w_2: VitalWireDelay (D0_ipd, D0, tipd_D0); END BLOCK;

Figure 5.3 Example wire delay block

w_1 : VitalWireDelay (CLRNeg_ipd, CLRNeg, tipd_CLRNeg); w_2 : VitalWireDelay (OE1Neg_ipd, OE1Neg, tipd_OE1Neg); wdgen : FOR i IN 7 downto 0 GENERATE

VitalWireDelay (IO_ipd(i), IO(i), tipd_IO(i)); END GENERATE;

END BLOCK; WireDelay : BLOCK BEGIN

Figure 5.4 Wire delay block with GENERATEstatement

A D Q Q

CLK

CLK_ipd CLK_dly

ticd_CLK

VitalSignalDelayfor each timing generic representing an internal clock delay or internal signal delay. Negative timing constraints are the topic of Chapter 11.

5.2.3

Processes

A VITAL model may contain as many processes as required. There are four possi- ble sections in a VITAL process. Most are optional:

• Declarative section • Timing check section • Functionality section • Path delay section

The sequence of the various sections in the process is significant. They must appear in the order shown here.

All VITAL processes must have a sensitivity list. Each and every signal that is read in the process must appear in the sensitivity list of that process. This is due to the model’s tracking of timing for all its signals. If a signal were read in the process without it being in the sensitivity list, the model could register the signal transi- tion at the wrong time. Timing checks and delays based on the signal would become inaccurate.

Declarative Section

The declarative section of a VITAL process may include constants, variables, aliases, and attributes. In a level 1 model, variables must be of type std_ulogic, std_logic_vector, boolean, time, or one of the VITAL internal (restricted) types. Keep in mind most component models will not be level 1 models. Instead, they will be behavioral models that are easier to write and faster to run.

The restricted types you will declare in a VITAL process and their uses are: VitalGlitchDataType is used with VitalPathDelay procedures to store timing data used for glitch detection.

VitalTimingDataType is used with VitalSetupHoldCheck and Vital- RecoveryRemovalCheckprocedures to store timing data used to detect timing violations.

66 Chapter 5 Anatomy of a VITAL Model

--- -- Negative Timing Constraint Delays

--- SignalDelay : BLOCK

BEGIN

s_1: VitalSignalDelay (CLK_dly, CLK_ipd, ticd_CLK);

END BLOCK;

Figure 5.6 Signal delay block MAG05 8/18/04 3:12 PM Page 66

VitalPeriodPulseDataType is used with VitalPeriodPulseCheck proce- dures to determines pulse widths and periods.

PreviousDataIn is of type std_logic_vector and is used with Vital- StateTablecalls to store previous state information.

VitalSkewDataType is used with VitalInPhaseSkewCheck and Vital- OutPhaseSkewCheck procedures to store timing data used to detect skew violations.

Variables of these restricted types are used to store persistent data for private use by certain VITAL procedures. They may not be modified by the model itself. Figure 5.7 shows a VITAL process declarative section.

Timing Check Section

The timing check section performs timing constraint checks through predefined timing check procedures. These procedures can generate timing violation messages to the user and set violation flags that can be read by the functionality section of the process. The predefined procedures available are as follows:

• VitalSetupHoldCheck • VitalRecoveryRemovalCheck • VitalInPhaseSkewCheck

5.2 Level 1 Guidelines 67

--- -- Main Behavior Process

--- VitalBehavior : PROCESS (CLKint, D_ipd, MR_ipd)

-- Timing Check Variables

VARIABLE Tviol_D_CLK : X01 := ‘0’;

VARIABLE TD_D_CLK : VitalTimingDataType; VARIABLE Rviol_MR_CLK : X01 := ‘0’;

VARIABLE TD_MR_CLK : VitalTimingDataType; VARIABLE Pviol_CLK : X01 := ‘0’;

VARIABLE PD_CLK : VitalPeriodDataType := VitalPeriodDataInit; VARIABLE Pviol_MR : X01 := ‘0’;

VARIABLE PD_MR : VitalPeriodDataType := VitalPeriodDataInit; VARIABLE Violation : X01 := ‘0’;

-- Functionality Results Variables VARIABLE Q_zd : std_ulogic;

VARIABLE PrevData : std_logic_vector(0 to 3); -- Output Glitch Detection Variables

VARIABLE Q_GlitchData : VitalGlitchDataType;

• VitalOutphaseSkewCheck • VitalPeriodPulseCheck

The timing check section is constructed of a single IFstatement. The Timing- ChecksOn generic must be used as the only condition. The timing check proce- dures are called from within the IF statement. No ELSE or ELSIF clauses are allowed:

BEGIN

--- -- Timing Check Section

--- IF (TimingChecksOn) THEN

-- as many calls to timing check procedures as required ...

END IF;

The timing check section only detects timing violations. The model must func- tion correctly when TimingChecksOnis FALSE. Timing constraint violations may be translated to ‘X’ outputs or corrupted memory locations in the functionality section. Signal assignments may not be made in the timing check section. All timing checks must be independent of one another. Details of the various timing check procedures are given in Chapter 8.

Functionality Section

The function of a VITAL model may be coded by utilizing the VITAL functionality section, concurrent procedure calls, or both. The functionality section defines the logical function of the model. It computes new output values based on the input values, but without timing.

The operation of a component is modeled in the VITAL level 1 process through a sequence of variable assignments and/or calls to the VitalTruthTable or VitalStateTableprocedures. Right-hand-side expressions may include

• Function calls to VITAL primitives

• Operators and functions defined in the std_logic_1164package • Function calls to VitalTruthTables

• Concatenation and aggregate forms

• Variables, constants, signals (_ipd), and ports

The following are not allowed in a level 1 process (but are allowable in a level 0 process):

• IF, CASE, LOOP, NEXT, EXIT, and RETURNstatements • WAITstatements

68 Chapter 5 Anatomy of a VITAL Model

• Signal assignments • Assertion statements

• Procedure calls to other than VITAL procedures

These restrictions limit the usefulness of level 1 processes to modeling relatively simple components. The majority of models will be compliant with VITAL level 0.

A level 1 functionality section might look like this:

--- -- Functionality Section

--- Violation := Tviol_D_CLK OR Pviol_CLK OR Rviol_MR_CLK OR Pviol_MR;

VitalStateTable (

StateTable => DFFR_tab,

DataIn => (Violation, CLKint, D_ipd, MR_ipd), Result => Q_zd,

PreviousDataIn => PrevData );

We will see level 0 functionality sections in later chapters.

Path Delay Section

The path delay section receives the undelayed computed output values from the functionality section and uses them to drive ports or internal signals after applying the appropriate delays. It accomplishes this task through calls to the VitalPath- Delayprocedures. (A more in-depth discussion of path delays is given in Chapter 6.) Figure 5.8 shows the path delay section from the eclps151 model:

5.2 Level 1 Guidelines 69

--- -- Path Delay Section

--- VitalPathDelay01 ( OutSignal => Qint, OutSignalName => "Qint", OutTemp => Q_zd, GlitchData => Q_GlitchData, XOn => XOn, MsgOn => MsgOn, Paths => ( 0 => (InputChangeTime => CLKint’LAST_EVENT, PathDelay => tpd_CLK1_Q, PathCondition => TRUE), 1 => (InputChangeTime => MR_ipd’LAST_EVENT, PathDelay => tpd_MR_Q, PathCondition => TRUE) ) );