<div dir="ltr"><div>Hey Jason,</div><div><br></div><div>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 block.</div><div><br></div><div>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, <a href="http://noc_block_fft_tb.sv">noc_block_fft_tb.sv</a> 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.</div><div><br></div><div>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 class.</div><div><br></div><div>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:</div><div> - For sending / receiving data packets to your RFNoC block under test, use tb_cvita_data / tb_axis_data</div><div> - For sending command packets, use tb_cvita_cmd</div><div> - For receiving response packets, use tb_cvita_ack</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div>Jonathon</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 14, 2016 at 11:30 AM, Jason Matusiak <span dir="ltr"><<a href="mailto:jason@gardettoengineering.com" target="_blank">jason@gardettoengineering.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the quick response Jonathon!<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Since you want to send an EOB or otherwise manipulate the header, use<br>
tb_cvita_data in the testbench. For example, to send a simple 2 sample<br>
packet with EOB set:<br>
</blockquote>
<br></span>
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<br>
<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
~Jason<br>
</font></span></blockquote></div><br></div>