I was looking at your code to answer your question when I noticed that the noc_shell code doesn't seem to match your YAML, so I'm wondering if the YAML was modified after you generated your noc_shell? The noc_shell is missing the ce_clk declared in your YAML.
To answer your question, I'm going to assume you want a ce_clk that's different from rfnoc_chdr_clk and rfnoc_ctrl_clk and you want your DSP and the registers to use ce_clk. In that case: 1. Regenerate your block to get a new noc_shell_conv. This will add a ce_clk input and a ce_rst output to noc_shell_conv. Again, be careful to not overwrite your existing code when regenerating your block. 2. In rfnoc_block_conv, connect the ce_clk input port to the ce_clk input port of noc_shell_conv. 3. In rfnoc_block_conv, declare a ce_rst wire at the top and connect it to the ce_rst output port of your noc_shell. 4. Update your registers and custom logic to use ce_clk and ce_rst. The answer is slightly different if you want to use the current noc_shell. But in general, you say what clocks you want to use in the YAML file. When the noc_shell is generated, it will take as inputs the clocks you declared in the YAML, it will output resets that you can use for those clock domains, and it will output on ctrlport_clk and axis_data_clk whatever clocks you said in the YAML that you wanted to use for those interfaces. This can be a bit confusing because it means you can have multiple versions of the same clock under different names (e.g., ce_clk, ctrlport_clk, and axis_data_clk might all be the same clock, just on different signal names). Wade On Fri, May 13, 2022 at 1:09 PM Jeffrey Cuenco <jcue...@ucsd.edu> wrote: > Thanks Wade! > > I went ahead and restored the signal sizes to 32-bit as you suggested. > > For using ce_clk, does it suffice for me to create a wire for ce_clk in > the .v file and then reference it from the yaml? Is ordering important or > just ensuring the name matches the wire? Thanks! > > -Jeff > > > On May 12, 2022, at 10:29, Wade Fife <wade.f...@ettus.com> wrote: > > > 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
