DFF Testbench confusing

Question

So i saw this VHDL code for a testbench for a DFF somewhere and i don't quite get a few things.

1) Why are there 5 cases? Why aren't there just two? when the input is 0 and when it is 1; 2) Why did he pick those waiting periods so randomly? It seems that 12,28,2,10,20 ns seem very randomly chosen. What was the logic behind that?

architecture testbench of dff_tb is

signal T_din:  std_logic;
signal T_dclk:  std_logic;
signal T_qout:  std_logic;
signal T_nqout: std_logic;

component dff 
port ( din:   in std_logic;
     dclk:  in std_logic;
     qout:    out std_logic;
     nqout:  out std_logic
   );
end component;

begin

dut_dff: dff port map (T_din,T_dclk,T_qout,T_nqout);

process
begin
T_dclk <= '0';
wait for 5 ns;
T_dclk <= '1';
wait for 5 ns;
end process;

process 

variable err_cnt: integer := 0; 

begin
--case1
T_din <= '1';
wait for 12 ns;     
assert (T_qout='1') report "Error1!" severity error;

-- case 2
T_din <=  '0';   
wait for 28 ns;
assert (T_qout='0') report "Error2!" severity error;

-- case 3
T_din <= '1';            
wait for 2 ns;
assert (T_qout='0') report "Error3!" severity error;

-- case 4
T_din <= '0';
wait for 10 ns;
assert (T_qout='0') report "Error4!" severity error;

-- case 5
T_din <=  '1';    
wait for 20 ns;    
assert (T_qout='1') report "Error5!" severity error;   

wait;
end process;

end testbench;

score 1 · Answer 1 · answered May 17 '14 at 14:03

You have to look closer on the clock. The clock switches every 5 ns.

Case 1

So in the beginning the DFF should be '1'.

Case 2

After 15 ns since the start, the output should be '0', not after 12 ns, thats, what you have to check.

Case 3

You set the input to '1' but the DFF should never react on it, because the duration is too short.

Case 4 & Case 5

They just ensure you, that after Case 3, there is everything alright. Again, like in Case 2 here you can check after which amount of time the DFF really switches.

This testbench IS a little bit large, if you consider testing a DFF. But if you are learning about hardware description and testbenching, it is good to know what you have to look after, before you start to implement more complicated and complex designs. Especially if you are going to make a silicon out of it, there is never enough testing done :)

score 1 · Accepted Answer · answered May 17 '14 at 21:46

In the following the case 1, case 2, through case 5 are represented by named markers A through E:

dff_tb waveform

Case 1 checks to see that T_qout doesn't get updated on the falling edge of T_clk with T_din = '1'. See marker A.

Case 2 (marker B) checks to see T_qout doesn't get updated on the falling edge of T_clk with T_din = '0'.

(And about now you get the impression a student was supposed to do a gate level implementation of dff).

Case 3 (marker C) checks to see if T_qout remains a '0' (an assertion occurs when the condition is False), that the dff is clocked. That a '1' on T_din doesn't cause the output to change.

Case 4 (marker D) checks to see if T_qout remains a '1' the for the opposite value of T_din.

(These all appear to be checking gate level dff implementations).

Case 5 (marker E) appears to be checking the that a Master–slave edge-triggered D flip-flop isn't oscillating or 'relaxing' to the original state.

The testbench appears to be specific to a class assignment for implementing a DFF as a gate level model.

Now the question is, did the instructor cover all possible cases for a student to get it wrong?

DFF Testbench confusing

2 Answers2