mentor_instroduction

Coding Techniques

________________________________________________________________________________________________________________________

1USE my_lib.my_qsim_logic.ALL; --This package defines qsim_state.

2USE my_lib.my_qsim_extended.ALL;--This package defines

11--Enable_rise = Prop. Delay low-to-high from enable to q_out

12--Enable_fall = Prop. Delay high-to-low from enable to q_out

13--Enable_fall = Prop. Delay high-to-low from enable to q_out

22--Each string is ordered as min, typ, and max time values.

23--Each string assumes values in nanoseconds.

28-- my_qsim_get_time function from my_qsim_extended package

29-- accepts two parameters:

30-- 1 A string of characters that is converted to a time value

31-- 2 Constant "Timing_mode", which is declared in test_bed

32-- model and set to a value of either min, typ, or max

Figure 6-7. Entity for One-Bit Latch Using Parameterized Rise/Fall Delays

Coding Techniques

________________________________________________________________________________________________________________________

Figure 6-8. Rise/Fall Values Passed to One-Bit Latch Model

Four constants in Figure 6-7, declared in lines 34 through 41, correspond with the four generic constants in lines 17 through 20. The constants in lines 34 through 41 hold the actual propagation delay values used in the architecture of the model. Each of these are declared as type time and set to a specific value determined by the function my_qsim_get_time. The function and its parameters are described in the code comments in lines 28 through 32.

In this example, generic constant Data_rise (line 17 of Figure 6-7) receives string "8,16,30" as shown in Figure 6-8. This value comes from the fourth parameter in the generic map of line 25 in the test bench model of Figure 6-9. The eighth parameter in the generic map (Figure 6-9, line 26) sets the Timing_mode constant (Figure 6-7, line 21) to typ. The function call in line 34 of Figure 6-7 passes the string "8,16,30" and constant Timing_mode (which is

Coding Techniques

________________________________________________________________________________________________________________________

set to typ) to function my_qsim_get_time. In this case, the function returns the time value 16 ns and assigns it to constant Data_tplh (Figure 6-7, line 34). The constant timing values are used throughout the behav1 architecture body shown in Figure 6-10. The other rise/fall parameters are also set in this way.

1LIBRARY my_lib; --Define Logical library name.

2USE my_lib.my_qsim_logic.ALL;

5ENTITY test_latch IS

6END test_latch

7

8ARCHITECTURE test_bed OF test_latch IS

9COMPONENT latch1

13PORT (da, en: IN my_qsim_state; qo: OUT my_qsim_state);

14END COMPONENT;

15

16FOR L1 :latch1 USE ENTITY latch(behav1)

17GENERIC MAP (En_width, Da_setup, Da_hold,

20PORT MAP (da, en, qo);

21SIGNAL data, enable, q_out : my_qsim_state;

22BEGIN

23L1: latch1

24GENERIC MAP( 20 ns, 20 ns, 5 ns, --This line supports

27PORT MAP (data, enable, q_out);

28. . . --The code here can exercise the Latch.

29END test_bed;

Figure 6-9. Test Bed Code for Latch Model

Coding Techniques

________________________________________________________________________________________________________________________

1 ARCHITECTURE behav1 OF latch IS

2

3BEGIN

4PROCESS (enable, data)

5BEGIN

6IF enable’event THEN -- -------------------------------------

18ELSIF enable /= ’0’ THEN --Behavior when enable is ’X’ or ’Z’

19IF enable_tplh >= Enable_tphl THEN

24END IF;

25ELSE -- No event on enable ---------------------------------

37END IF;

38END behav1;

Figure 6-10. Architecture Body for One-Bit Latch with Parameterized Delays

Coding Techniques

________________________________________________________________________________________________________________________

Increasing Model Accuracy with Error Checking

The previous example of the one-bit latch in Figure 6-7 is used here to show one way to add hold and setup violation checks to your simulation models. As before, generics are used to pass data into the VHDL model.

In this example the latch test bench model associated with the latch model assumes the values shown in Table 6-1 (set in lines 24 through 26 in Figure 6-9). The values added to the latch for the setup and hold checks in this example are Setup, Hold, and Width.

Table 6-1. Constant Values Set in Latch Test Bed Model

Figure 6-11 shows the lines that are added to the code in Figure 6-7 to handle a pulse-width check for the enable signal, a check of the data-to-enable setup time, and a check of the data-from-enable hold time.

Lines 14 through 16 in Figure 6-11 show the generic constant declarations which receive the information from outside the model during simulation. Each of these constants are set to a default time value of 0 ns if there is no associated data from outside the model. When the latch model is instantiated in either a test bench model or another design entity and contains the values listed in Table 6-1, the associated VHDL model assigns the proper values to the constants.

Coding Techniques

________________________________________________________________________________________________________________________

Figure 6-11. Error-Checking Code Added to Entity for One-Bit Latch

Coding Techniques

________________________________________________________________________________________________________________________

E4

30

Figure 6-12. Comparing a Signal with Its Delayed Counterpart

The elapsed time since the last event at timestep "30.0 ns" (E3) for the enable signal is 0 ns. This is why the ’last_event attribute is applied to the delayed version of the enable signal in line 45. If the ’last_event attribute is applied to the enable signal instead of the delayed version of the enable signal, the elapsed time between events E3 and E1 is not returned at event E3.

At event E3, (when the enable signal changes to a ’0’) theenable’delayed signal has not yet changed state (no event). Therefore, when the ’last_event

Coding Techniques

________________________________________________________________________________________________________________________

time since data last changed. If the returned value is less than or equal to 20 ns in this example, a setup violation has occurred. The setup time in Figure 6-13 (from event E1 to E3) is within the 20 ns specification and will not generate an error report.

enable

E1

data

Figure 6-13. Setup/Hold Timing for Latch

The chk_hold assertion statement in lines 54 through 57 is similar to the chk_setup assertion statement in lines 49 through 52.

The chk_hold assertion statement has three conditions that all must evaluate to FALSE before the report is issued. The first condition (data’stable) causes the assertion statement to "look" at the other two conditions only when there is an event on data.

The second condition (enable /= ’0’) causes the assertion statement to perform the hold check only when enable is ’0’ (not ’1, ’X’, or ’Z’’). The third condition (enable’last_event >= Data_hold) performs the hold check. If the first two conditions are false, then this statement determines whether the report will be sent. Assuming that constant Data_hold has a value of 5 ns, the