Hi Jeff, I took a look and noticed a couple things.
- There are some signal width mismatches in rfnoc_block_conv.v. Take a look at s_rfnoc_ctrl_tdata, m_rfnoc_ctrl_tdata, m_in_payload_tdata, s_out_payload_tdata. They have different widths than what the noc_shell expects. I think it's possible to change the payload_tdata width to 8 on the noc_shell by changing the item_width in your YAML, but you'll want to regenerate the noc_shell to do that (be careful not to overwrite your other files if you do this). But the ctrl bus must be 32-bit. - The ctrlport_clk has no driver. It looks like you specified ce_clk as the clock domain in your YAML, so perhaps that's the clock you want to use? Try resolving these issues and see where that gets you. Wade On Wed, May 11, 2022 at 2:19 PM Jeffrey Cuenco <jeffrey.cue...@gmail.com> wrote: > Hi Wade, > > Please see attached. Thanks! > > -Jeff > > > > > On May 11, 2022, at 08:42, Wade Fife <wade.f...@ettus.com> wrote: > > > 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
