[USRP-users] making sense of the RFNoC testbench files

Jonathon Pendlum jonathon.pendlum at ettus.com
Mon Mar 14 20:58:08 EDT 2016

Hey Jason,

Did you take a look at the block diagram in sim_rfnoc_lib.svh? That
describes how test benches look like when using the RFNoC test bench
infrastructure. Basically, your RFNoC block is connected to the crossbar by
using `RFNOC_ADD_BLOCK(). `RFNOC_SIM_INIT() sets up the test bench RFNoC
block (noc_block_tb). My previous post explains how noc_block_tb exposes
interfaces such as tb_cvita_data that lets you send packets to your RFNoC
block. From a high level perspective, you can think of this as setting up a
RFNoC flowgraph in simulation like this: noc_block_tb -> XBAR -> Your RFNoC

The RFNoC test bench infrastructure is designed to test your blocks at the
RFNoC block level. It is not intended to test individual components in your
RFNoC block. For example, noc_block_fft_tb.sv tests the whole FFT RFNoC
block and not the Xilinx FFT core by itself. Of course, by testing the FFT
RFNoC block it does exercise and test the Xilinx FFT core, but it also
tests things like the magnitude calculation logic, setting the control
registers, etc.

As for driving the AXI stream signals, we have classes (cvita_bus /
cvita_master / cvita_slave in sim_cvita_lib.svh & axis_bus / axis_master /
axis_slave in sim_axis_lib.svh) that have tasks that will handle those
signals automatically. The AXIS classes are for sending and receiving data
on AXI stream buses. The CVITA classes inherit and build on top of the AXIS
classes to allow sending and receiving CVITA packets (which is RFNoC's
packet format). This class based abstraction approach is a feature of
SystemVerilog we use to make it easier to write test benches. For example,
if you want to send a CVITA packet you don't need to worry about
controlling tvalid / tready / tlast and write a lot of control code, you
just need to use the one line task push_pkt() defined in the cvita_bus

It may seem daunting how to actually setup and use these classes and
interfaces in your test bench. That is why I wrote sim_rfnoc_lib.vh and
have macros like RFNOC_SIM_INIT. That macro setups up noc_block_tb, the
interfaces, and the classes so all you have to know is:
 - For sending / receiving data packets to your RFNoC block under test, use
tb_cvita_data / tb_axis_data
 - For sending command packets, use tb_cvita_cmd
 - For receiving response packets, use tb_cvita_ack

For example, if you want to send a data packet your RFNoC block with only
one sample, you could use tb_axis_data.push_word({16'd0,16'd1} /* You
sample */,1 /* set tlast */) in your test bench.

Finally, with all that said, you may just want to test an individual
component in your design like the FFT in the FFT RFNoC block. You can use
AXIS class instances to drive the varous AXI stream buses in your design.
You will have to instantiate them yourself and looking at sim_rfnoc_lib.vh
is a good example on how to do so.


On Mon, Mar 14, 2016 at 11:30 AM, Jason Matusiak <
jason at gardettoengineering.com> wrote:

> Thanks for the quick response Jonathon!
> Since you want to send an EOB or otherwise manipulate the header, use
>> tb_cvita_data in the testbench. For example, to send a simple 2 sample
>> packet with EOB set:
> Actually my noc_block is going to set the eob internally, so the incoming
> packets can have it or not (I ignore the eob), I just need the other side
> to either ignore that I am sending it, or trigger based on it
> I need to reread your email a couple more times to get it to absorb, but
> it looks very thorough, that will be helpful.  What I don't see (though may
> pop-up upon cross referencing the files you mentioned is how the flags are
> handled.  Meaning if I have a register of 100 32b values (16b I/Q), and I
> want to pass through samples to mu block one sample at a time, I don't see
> where the testbench sets valid/last flags and looks for ready flags from
> me.  Since my block takes many clocks to calculate a value on each sample,
> it is pretty different from most of the examples and I wondered if I needed
> to modify my testbench to compensate for that.
> ~Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160314/36e7669e/attachment-0002.html>

More information about the USRP-users mailing list