Hi Jeffrey, Very curious that you're getting that CTRL_STS_OKAY error, since it looks like you're not using the status. I assume ctrlport:has_status is set to False in your block's YAML? In that case the status should always be OK.
1) For different input/output packet sizes, you need to modify the context to set the payload length of the outgoing packet. That's the block of code starting on line 283 in the rfnoc_block_conv.v file you sent. There's an example in rfnoc_block_logpower, in which the output packet length is half the length of input packets. In your case you'll need to set it to 3/2 instead of 1/2. See here: https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_logpwr/rfnoc_block_logpwr.v#L202 2) The testbenches typically have an ITEM_W constant that indicates the size of the data type you want to work with. The ITEM_W is normally set to the sample size (e.g., 32 for sc16 samples). Since you want to work with bytes, you could change that to 8 then create an item_t array and send it as a single packet using blk_ctrl.send_items(). Then you can call blk_ctrl.recv_items() to get the data output packet, and inspect the items array that is returned. Take a look at PkgRfnocBlockCtrlBfm to see what other send/recv methods are available. Here's a quick example assuming the item size is 8-bit: item_t sent[$], received[$]; sent = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; // Whatever values you want for the input packet, one byte per element blk_ctrl.send_items(0, sent); blk_ctrl.recv_items(0, received); foreach(received[i]) begin // Compare the expected value to the byte in received[i] and see if it matches end Wade On Mon, May 9, 2022 at 1:30 PM Jeffrey Cuenco via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi all, > > Long time no see! I am currently on a final stretches of completing a > masters project for my wireless embedded systems program that involves a > USRP X310 with RFNoC 4.0 and GNURadio that implements a Hierarchical > Modulation design using nested 4QAM / QPSK (final constellation "appears" > like 16QAM but has embedded high priority and low priority layers that can > adapt based on SNR). > > I am currently attempting to integrate the Xilinx Convolutional Encoder > v9.0 IP block into the template rfnoc_block_conv.v design that was created > using rfnocmodtool and modeled after the Ettus FFT example. With a bit of > work I was able to get the .xci file loaded by Vivado when the make target > is executed for the testbench, and the testbench appears to build without > much modification. > > When executing 'make rfnoc_block_conv_tb' it appears to fully execute the > build process to the end, but I receive a fatal "Did not receive > CTRL_STS_OKAY status" message in the process which I attribute to either > something not being configured in the testbench file or something not being > configured right in my verilog module file. > > I've attempted to summarize where I'm stuck and need help on in the below > three summary points / questions: > 1) I have configured the convolutional encoder with rate 1/2 and punctured > (effective rate 2/3), which I assume will require me modifying the > "axi_wrapper" so that the output to input ratios are set properly - are > there additional examples that I can follow for this? > > I've seen the axi_wrapper migration note but as I'm still a novice at > Verilog and System Verilog additional examples would be helpful. :) > > > 2) I would like to modify my testbench so that I send 10 bytes (80 bits) > of data, and read out the 15 bytes (120 bits) that get spit out and verify > that the encoded bytes coming out of the core match ground truth data I > would generate using MATLAB. > > Do we have any additional testbench examples or additional documentation > that show sending 1 or more bytes of data through an IP core? The IP core's > *s_axis_data_tdata* and *m_axis_data_tdata *are 8-bit while most of the > examples show sending 32 bits. Aside from setting the assignments to [7:0] > are there any other adjustments that need to be made in any of the signal > declarations and/or block definition wires earlier in the file? > > I've provided the IP core documentation for reference just in case: > https://docs.xilinx.com/v/u/en-US/pg026_convolution > > I've also included the module and testbench files as well as the xsim log. > > Thanks in advance! > -Jeff > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
