Can you also share your block's YML and the noc_shell you generated? Wade
On Wed, May 11, 2022 at 4:27 AM Jeffrey Cuenco <jcue...@ucsd.edu> wrote: > Hi Wade, > > Yes, I have the ctrlport:has_status set to False in the block YAML... I > ended up having to comment out that test sequence to move onto the part > that sends samples into and out of the block; now I have an error that > states > > > *Fatal: Timeout: Test "Test passing through samples" time limit exceeded* > so I must be doing something that it isn't liking :) I've attached my > updated .v and .sv files that I modified based on your guidance in your > first response, as well as the updated xsim.log. Please let me know if > there are any additional things I may need to change such as sizes and what > not - thanks! > > -Jeff > > On Mon, May 9, 2022 at 3:12 PM Wade Fife <wade.f...@ettus.com> wrote: > >> 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 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_uhd_blob_master_fpga_usrp3_lib_rfnoc_blocks_rfnoc-5Fblock-5Flogpwr_rfnoc-5Fblock-5Flogpwr.v-23L202&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=Y3cOHwFMBDXttsqnINKoCyXB-ta6yD08QrmMzW9aeZY&m=GXbgyQxDz4yiy7ZI94I9ia-1XvF2rdmrbxprVfQojmcljlWVOVrjE1Z7g7qsBL_a&s=WkFBbmpL8IpvF2oHp-4Vfhy73qA49jSJD2tHoTQ0anQ&e=> >> >> 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 >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.xilinx.com_v_u_en-2DUS_pg026-5Fconvolution&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=Y3cOHwFMBDXttsqnINKoCyXB-ta6yD08QrmMzW9aeZY&m=GXbgyQxDz4yiy7ZI94I9ia-1XvF2rdmrbxprVfQojmcljlWVOVrjE1Z7g7qsBL_a&s=VpTL0Eev0xGrPxywg6lGumMok1Lx8kj5t4uFefeMWNA&e=> >>> >>> 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
