|
|
# streamers\_multi\_test
|
|
|
|
|
|
While the testbench described in this page provides means for
|
|
|
verification of the proper operation and different configurations of the
|
|
|
WR Streamers, the other testbenches have more demonstrative purpose.
|
|
|
Thus, only the `streamers_multi_test` testbench is configured to run as
|
|
|
part of Continuous Integration (CI) tests. This 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:
|
|
|
|
|
|
[![](/uploads/c08094333c870ac85d04e80fdff1ec96/wr_streamers-TB-small.png)](/uploads/309a03632ce8794d645fe10bfbcccdaf/wr_streamers-TB.png)
|
|
|
*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.
|
|
|
|
|
|
<!-- end list -->
|
|
|
|
|
|
- **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
|
|
|
$ 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).
|
|
|
|
|
|
[![](/uploads/7056ff6269d5ddbaf884610b2065118b/wr_streamers-tx-sim-small.png)](/uploads/0e389f5328d6ffe2a872690297e30b7b/wr_streamers-tx-sim.png)
|
|
|
*Figure 2 - Simulation run showing Tx streamer operation for frame
|
|
|
transmission**
|
|
|
|
|
|
[![](/uploads/60cd630fdd268d87318da3979d6641fa/wr_streamers-tx-max_wrds-small.png)](/uploads/952645caacd321ecb9d5d1d93245f33f/wr_streamers-tx-max_wrds.png)
|
|
|
*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
|
|
|
4.
|
|
|
|
|
|
[![](/uploads/c0d09260dd16f77c49bdd4a6d17318d0/wr_streamers-rx-fxd_lat-small.png)](/uploads/45c334f9276a07698d0e8e983ef63cb0/wr_streamers-rx-fxd_lat.png)
|
|
|
*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` and
|
|
|
`rx_lost_frames_p1_o`) and that the output count
|
|
|
(`rx_lost_frames_cnt_o`) is also correct. See figure
|
|
|
5.
|
|
|
|
|
|
[![](/uploads/c48ab3689c08423d0d09fbeddb747ace/wr_streamers-rx-drp_frm-small.png)](/uploads/7b8dee396adfb9ea25ff5062c95c39d4/wr_streamers-rx-drp_frm.png)
|
|
|
*Figure 5 - Simulation run showing how lost frames are signalled at Rx
|
|
|
streamer**
|
|
|
|
|
|
-----
|
|
|
|
|
|
6 July 2017
|
|
|
|
|
|
|
|
|
|
|
|
### Files
|
|
|
* [wr_streamers-TB.png](/uploads/d3eb9a9e872fb0679c2eb726246e081a/wr_streamers-TB.png)
|
|
|
* [wr_streamers-TB-small.png](/uploads/c08094333c870ac85d04e80fdff1ec96/wr_streamers-TB-small.png) |
|
|
\ No newline at end of file |