{"id":256,"date":"2018-09-27T13:32:35","date_gmt":"2018-09-27T13:32:35","guid":{"rendered":"http:\/\/blogs.plymouth.ac.uk\/embedded-systems\/?page_id=256"},"modified":"2018-09-27T13:44:40","modified_gmt":"2018-09-27T13:44:40","slug":"part-6-modelling-and-testing-synchronous-systems","status":"publish","type":"page","link":"https:\/\/blogs.plymouth.ac.uk\/embedded-systems\/fpga-and-vhdl\/test-benches\/part-6-modelling-and-testing-synchronous-systems\/","title":{"rendered":"Part 6 – Modelling and Testing Synchronous Systems"},"content":{"rendered":"

Prev<\/a><\/p>\n

The majority of sequential logic systems use a shared clock to synchronise outputs. We say such systems are “synchronous”. One of the most fundamental building blocks of a synchronous systems if the D-Type Flip-Flop.<\/p>\n

This is defined in the following VHDL:<\/p>\n

library ieee;\t\t\t\t\r\nuse ieee.std_logic_1164.all;\r\n\r\n--D-Type Flipflop primitive\r\nentity dff_primitive is\r\nport(  \tD:\tin std_logic;\r\n\tCLK:\tin std_logic;\r\n\tQ:\tout std_logic\r\n);\r\nend dff_primitive;\r\n\r\n--This component has two architecture\r\narchitecture v1 of dff_primitive is\r\n\r\nbegin\r\n\tprocess(CLK)\r\n\tbegin\r\n\t\t--Update Q on the rising edge of CLK\r\n\t\tif rising_edge(CLK) then\r\n\t\t\tQ <= D; \r\n\t\t\t-- The absence of an else will result in a latching behviour\r\n\t\tend if;\r\n\tend process;\r\nend v1;<\/pre>\n
In words, the output\u00a0Q<\/span>\u00a0 is latched to the input value\u00a0D<\/span>\u00a0 on the rising edge of the clock\u00a0CLK<\/span>\u00a0 Note that this is edge triggered<\/em>, and NOT level triggered. Special edge detection circuitry is is used in synthesis.<\/p>\n
Note how the\u00a0rising_edge<\/span>\u00a0 function is used in this example. This function only returns a boolean true when the signal changes from a low value (‘0’ or ‘L’) to a high value (‘1’ or ‘H’). It does not return true for a transition from ‘U’ to ‘1’.<\/p>\n
Testing<\/h2>\n
To test a D-Type Flip-Flop requires the generation of a clock. Ideally, we should also examine the outputs of the D-Type Flip-Flop for specific input sequences.<\/p>\n
Let’s look at a testbench to test the following:<\/p>\n
    \n
  • Latching a ‘0’ input<\/li>\n
  • Latching a ‘1’ input<\/li>\n
  • Ignoring input changes between clock edges<\/li>\n<\/ul>\n
    For clarity, this will be limited to functional testing and will ignore timing such as set-up and hold-time violations.<\/p>\n
    library ieee;\t\t\t\t\r\nuse ieee.std_logic_1164.all;\r\nuse ieee.numeric_std.all;\r\n--use ieee.std_logic_unsigned.all;\r\n--use std.textio.all;\r\n\r\nentity dff_test is\r\nend dff_test;\r\n\r\narchitecture v1 of dff_test is\r\n\t--Declare signals\r\n\tsignal D_INPUT     : std_logic;\r\n\tsignal CLK_INPUT   : std_logic := '0';\r\n\tsignal Q_OUTPUT    : std_logic;\r\n\tconstant Tclk      : time  := 50 ns;\r\n\tconstant Tsim\t   : time  := 1000 ns;\r\n\r\n\t--Simple procedure to check the level of a signal\r\n\tprocedure checkOutput(expected : std_logic) is\r\n\tbegin\r\n\t\tassert(Q_OUTPUT = expected)\r\n\t\t\treport \"DFF output incorrect\"\r\n\t\t\tseverity error;\r\n\tend checkOutput;\t\r\n\t\r\n\t--Simple procedures to wait on clock edges\r\n\tprocedure waitForClockToFall is\r\n\tbegin\r\n\t\twait until (CLK_INPUT'EVENT and CLK_INPUT = '0');\r\n\tend waitForClockToFall;\r\n\r\n\tprocedure waitForClockToRise is\r\n\tbegin\r\n\t\twait until (CLK_INPUT'EVENT and CLK_INPUT = '1');\r\n\tend waitForClockToRise;\r\n\r\nbegin\r\n\t--Instantiate v1 of the component type dlatch_primative\r\n\tu1: entity work.dff_primitive(v1) PORT MAP (\r\n\t\tD   => D_INPUT,\r\n\t\tCLK => CLK_INPUT,\r\n\t\tQ   => Q_OUTPUT\r\n\t);\r\n\r\n\tclock_process:\r\n\tprocess\r\n\t\tvariable t : time := 0 ns;\r\n\tbegin\r\n\t\tloop\r\n\t\t\tt := t + Tclk;\r\n\t\t\twait for Tclk;\r\n\t\t\tCLK_INPUT <= not CLK_INPUT;\r\n\t\t\texit when t >= Tsim;\r\n\t\tend loop;\r\n\t\twait;\r\n\tend process;\r\n\r\n\tmain_process:\r\n\tprocess \r\n\t\t--Declarations here\r\n\tbegin\t\r\n\t\t--Set on falling edge of clock so signal is stable on rising\r\n\t\twaitForClockToFall;\t\r\n\t\r\n\t\t-- latching a zero on the output\r\n\t\tD_INPUT <= '0';\r\n\r\n\t\t--Check output\r\n\t\twaitForClockToRise;\r\n\t\tcheckOutput('0');\r\n\r\n\t\t--test latching a one\r\n\t\twaitForClockToFall;\r\n\t\tD_INPUT <= '1';\t\t\r\n\t\t\r\n\t\twaitForClockToRise;\t\r\n\t\tcheckOutput('1');\r\n\r\n\t\twaitForClockToFall;\r\n\t\tcheckOutput('1');\r\n\t\t\r\n\t\t--show that input is ignored elsewhere\r\n\t\tD_INPUT <= '0';\r\n\t\twait for (Tclk \/ 10);\r\n\t\tcheckOutput('1');\r\n\r\n\t\tD_INPUT <= '1';\r\n\t\twait for (Tclk \/ 10);\r\n\t\tcheckOutput('1');\r\n\r\n\t\tD_INPUT <= '0';\r\n\t\twait for (Tclk \/ 10);\r\n\t\tcheckOutput('1');\r\n\r\n\r\n\t\tD_INPUT <= '0';\t\r\n\t\twaitForClockToFall;\r\n\t\twaitForClockToRise;\r\n\t\tcheckOutput('0');\r\n\t\t\r\n\t\t\t\t\t\r\n\t\t--End of test is to wait forever\r\n\t\twait;\r\n\tend process;\r\n\t\t\r\nend v1;<\/pre>\n
    Before we examine this in more detail, let’s look at the simulation output:<\/p>\n
    \"\"<\/p>\n
    There are some points of interest:<\/p>\n
      \n
    • At time < 100ns, the input is undefined.<\/li>\n
    • At time < 150ns, the output is undefined (suggesting this device may need a reset input)<\/li>\n
    • At times 150ns and 350ns there is a rising edge of clock, and a correct output transition to value ‘0’. This is shown to latch<\/li>\n
    • At time 250ns there is a rising edge of clock, and a correct output transition to value ‘1’. This is shown to latch<\/li>\n
    • At time 300ns and shortly after, there are some perturbations in the input. These are shown to be correctly ignored<\/li>\n<\/ul>\n
      This is not exhaustive, but provides good coverage for illustrative purposes. Let’s now look more closely at the test-bench where we meet some new concepts:<\/p>\n
      The component under test is instantiated as we’ve done before:<\/p>\n
      \tu1: entity work.dff_primitive(v1) PORT MAP ( D => D_INPUT, CLK => CLK_INPUT, Q => Q_OUTPUT );<\/pre>\n
      Therefore, we see that we should stimulate the D_INPUT<\/span> and CLK_INPUT<\/span> signals, while observing the Q_OUTPUT<\/span> signal.<\/p>\n
      Separation of Concerns<\/h3>\n
      Note there are two process blocks in the testbench,\u00a0clock_process<\/span> which stimulates the\u00a0CLK_INPUT<\/span>\u00a0 signal and main_process<\/span> which stimulates (and checks) the\u00a0Q_OUTPUT<\/span>\u00a0 signal.<\/p>\n
        \n
      • They are separated to help simplify the structure<\/li>\n
      • The run concurrently<\/li>\n
      • Each will stimulate a unique set of signals<\/li>\n<\/ul>\n
        It is good practise to factor out a task in this way. Each process block has a distinct responsibility.<\/p>\n
        Clock Process<\/h3>\n
        The clock process has the single task of generating a clock signal for a defined period of time. In this example, the loop – end loop mechanism is used. We could equally have used a for-loop or some other approach.<\/p>\n
        \tclock_process:\r\n\tprocess\r\n\t\tvariable t : time := 0 ns;\r\n\tbegin\r\n\t\tloop\r\n\t\t\tt := t + Tclk;\r\n\t\t\twait for Tclk;\r\n\t\t\tCLK_INPUT <= not CLK_INPUT;\r\n\t\t\texit when t >= Tsim;\r\n\t\tend loop;\r\n\t\twait;\r\n\tend process;<\/pre>\n
        The highlighted lines show how the clock signal is toggled every 50 ns. Note how a variable is used to keep track of time-elapsed, and that the loop exists once Tsim<\/span> ns have elapsed. To make the code more readable, two constants are defined in the testbench architecture:<\/p>\n
        constant Tclk : time := 50 ns; \r\nconstant Tsim : time := 1000 ns;<\/pre>\n
        Main Process<\/h3>\n
        Given that the clock signal is now managed elsewhere, the main process simply needs to stimulate the\u00a0D_INPUT<\/span>\u00a0 signal at the correct times and to check the output signal Q_OUTPUT<\/span>\u00a0. Here is a sample taken from this process:<\/p>\n
        --Set on falling edge of clock so signal is stable on rising\r\nwaitForClockToFall;\t\r\n\t\r\n-- latching a zero on the output\r\nD_INPUT <= '0';\r\n\r\n--Check output\r\nwaitForClockToRise;\r\ncheckOutput('0');<\/pre>\n
        The procedure is as follows:<\/p>\n
          \n
        1. The input signal D_INPUT<\/span>\u00a0 is forced to logic ‘0’ after the fall of the clock edge (thus ensuring the input is stable for half a clock period before the rising edge)<\/li>\n
        2. The simulation then waits for a rising edge of the clock CLK_INPUT<\/span><\/li>\n
        3. The output signal Q_OUTPUT<\/span> is checked immediately (there is no propagation delay in a functional simulation).<\/li>\n<\/ol>\n
          Note that three VHDL procedures<\/strong> were used to reduce code repetition and improve readability. The first waits for a falling clock edge.<\/p>\n
          procedure waitForClockToFall is\r\nbegin\r\n\twait until (CLK_INPUT'EVENT and CLK_INPUT = '0');\r\nend waitForClockToFall;\r\n<\/pre>\n
          This is invoked by simply writing\u00a0waitForClockToFall<\/span>\u00a0 in the testbench. The second is similar, and waits for a rising clock edge:<\/p>\n
          procedure waitForClockToRise is\r\nbegin\r\n\twait until (CLK_INPUT'EVENT and CLK_INPUT = '1');\r\nend waitForClockToRise;<\/pre>\n
          Finally, the checkOutput<\/span>\u00a0 procedure is defined. This is somewhat different from the preceding two examples as it takes an input parameter. Note that it is possible to have more than one parameter (each is separated by a semi-colon).<\/p>\n
          procedure checkOutput(expected : std_logic) is\r\nbegin\r\n\tassert(Q_OUTPUT = expected)\r\n\t\treport \"DFF output incorrect\"\r\n\t\tseverity error;\r\nend checkOutput;\t\r\n<\/pre>\n
          Automatic Testing with assert<\/h3>\n
          The last example used the all-important assert<\/span>\u00a0 function to test for a specific condition. Where this condition is found to be false, then a message is written to the terminal. The severity is set as note<\/span>\u00a0, warning<\/span>\u00a0,\u00a0error<\/span>\u00a0 or failure<\/span>\u00a0.<\/p>\n
          When we run this simulation, we discover there are two errors reported!<\/p>\n
          # ** Error: DFF output incorrect\r\n# Time: 150 ns Iteration: 1 Instance: \/dff_test\r\n# ** Error: DFF output incorrect\r\n# Time: 250 ns Iteration: 1 Instance: \/dff_test<\/pre>\n
          This might seem strange as the simulation, the output looked correct. Watch the following video to see how this is resolved.<\/p>\n