The testbench described in this page provides means for verification of
the proper operation and different configurations of the WR Streamers.
It is configured to run as part of Continuous Integration (CI)
tests which is done by
including the run_ci.do file inside the testbench directory, and
including the path to the testbench as a single line in the
wr_cores/testbench/makefile
.
Testbench structure
A Simulation for the White Rabbit Streamers has been written in SystemVerilog to demonstrate some functionalities in the WR streamers as well as validating them.
Figure 1 below shows a diagram describing the structure of the testbench:
Figure 1 - Diagram of simulation testbench for WR Tx and Rx
streamers
The testbench operates by generating stimulus in the form of data words that are input into the tx streamer. Two types of tests are run in this simulation:
- Data monitoring: These tests check that the output from the Rx streamer corresponds to the transmitter input data (Stored in a SystemVerilog transfer queue). This test is continuous and runs everytime a new block is received.
- Functional Tests: The remaining tests are run by the testbench sequentially, one after the other, to check for specific features in the Tx or Rx streamer.
The testbench fails if any single one of these tests fails, monitoring or functional.
Note: The testbench focuses on creating specific input conditions to
check for particular features or use cases of the streamers.
Nonethelesss, the testbench makes use of some randomisation in terms of
the number of words per block and the number of blocks per frame. So
these will change from one complete run of the tests to the other.
The run.do
and run_ci.do
Tcl scripts, therefore make use of the
-sv_seed random
parameter of vsim in order to properly randomize each
simulation run. The actual seed value is reported at the start of the
simulation by ModelSim and it can be reused (by editing the Tcl script
and replacing the word “random” with the seed value) in order to repeat
a particular run.
Running tx and rx streamers testbench:
To run the testbench follow the instructions on installing hdlmake
(stable version 2.1). In the command line, from the wr-cores
folder:
$ cd testbench/wr_streamers/streamers_multi_test
$ hdlmake makefile
$ make
Once the build is complete, the simulation can be run either in
graphical or command line mode.
For the graphical mode, it is enough to launch vsim and execute the
run.do Tcl script from the ModelSim prompt.
$ vsim
[ModelSim >] do run.do
Note that all the other testbenches in the /testbench/wr_streamers/
folder can be run in the same way after entering their respective
folders
For the command-line mode type:
$ cd testbench/wr_streamers/streamers_multi_test
$ vsim -c -do "run_ci.do"
A sample output transcript is shown below. Note how tests 1 to 6 are run sequentially, whereas monitoring tests are run as and when a block is received.
.........
# [ 36866840 ns]: PASSED - TEST 1 - Tx FLUSH
# [ 36867208 ns]: PASSED - TEST - DATA MONITOR
# [ 36867448 ns]: PASSED - TEST - DATA MONITOR
# [ 36869688 ns]: PASSED - TEST 2 - Tx TIMEOUT
# [ 36870936 ns]: PASSED - TEST - DATA MONITOR
# [ 36871176 ns]: PASSED - TEST 3 - Tx MIN WORDS
# [ 36872744 ns]: PASSED - TEST - DATA MONITOR
# [ 36873016 ns]: PASSED - TEST 4 - Tx MAX WORDS
# [ 36875064 ns]: PASSED - TEST - DATA MONITOR
# [ 36884808 ns]: PASSED - TEST 5 - Rx FIXED-LATENCY
# [ 36884856 ns]: PASSED - TEST - DATA MONITOR
# [ 36884904 ns]: PASSED - TEST - DATA MONITOR
# [ 36884952 ns]: PASSED - TEST - DATA MONITOR
# [ 36886072 ns]: PASSED - TEST 6 - Rx DROP_FRAMES
# [ 36886424 ns]: PASSED - TEST - DATA MONITOR
# [ 36886664 ns]: PASSED - TEST - DATA MONITOR
# [ 36887272 ns]: PASSED - TEST - DATA MONITOR
# ........
Simulation output and results
Functional tests for Tx-streamer:
Figure 2 and 3 depict tests 1-4 that are described below.
- Test 1: Check frame transmission starts when tx_flush_p1_i port is high for one clock cycle.
-
Test 2: Check frame transmission starts when a timeout period
(set by
g_tx_timeout
) has ellapsed after reception of the last data words. -
Test 3: Check frame transmission starts when the transmit
threshold is exceeded (set by generic
g_tx_threshold
). -
Test 4: Check that exceeding the limit of words per frame (set
by vhdl generic
g_max_words_per_frame
) causes multiple frames to be sent.
(Note that the maximum words per frame is also the maximum words per block, as currently the streamers do not support splitting one block across multiple frames).
Figure 2 - Simulation run showing Tx streamer operation for frame
transmission
Figure 3 - Simulation output showing Tx streamer sending multiple
frames when the number of words per frame is exceeded
Functional tests for Rx-streamer:
Figure 4 depicts test 5 and Figure 5 depicts test 6 as described below.
-
Test 5: Check that when the fixed latency input signal
cfg_fixed_latency_i
is not set to zero then the Rx does not ouput the contents of the frame until the fixed latency has ellapsed. See figure
Figure 4 - Simulation run showing fixed latency check test for Rx
streamer
-
Test 6: Check that when frames are lost (purposefully dropped in
the case of the WR streamers testbench), then this is properly
signalled on the ouput port (
rx_lost_p1_o
andrx_lost_frames_p1_o
) and that the output count (rx_lost_frames_cnt_o
) is also correct. See figure
Figure 5 - Simulation run showing how lost frames are signalled at Rx
streamer
12 May 2020