If you want to customize the YAML and regenerate from your modified YAML, then I think you need to use rfnoc_create_verilog (part of UHD). So you could do something like:
python3 uhd/host/utils/rfnoc_blocktool/rfnoc_create_verilog.py -c conv.yml -d ./rfnoc_block_conv However, I see ce_rst in the modtool templates: https://github.com/EttusResearch/gr-ettus/blob/master/python/rfnoc_modtool/templates.py#L994 https://github.com/EttusResearch/gr-ettus/blob/master/python/rfnoc_modtool/templates.py#L1384 Perhaps you're using an older version of modtool? Wade On Wed, May 18, 2022 at 12:33 PM Jeffrey Cuenco <jeffrey.cue...@gmail.com> wrote: > Spoke too soon - sent last one out too fast so apologies for the message > clutter: > > What I see in rfnoc_block_conv.v is ce_clk as an input wire within the > rfnoc_block_conv module declaration. > > However, I don't see ce_rst anywhere in either the noc_shell_conv.v nor > the rfnoc_block_conv.v files. > > Is this something I should be concerned about, or will I need to manually > add this wire in? Please advise - thanks! > > -Jeff > > > On Wed, May 18, 2022 at 10:26 AM Jeffrey Cuenco <jeffrey.cue...@gmail.com> > wrote: > >> To clarify - I see them in rfnoc_block_conv.v but not in noc_shell_conv.v >> - just want to ensure that is okay; I ended up regenerating from scratch as >> I had used the gain block as a base the first time and it seems it was >> generated with an older RFNoC 3.x codegen. >> >> Will proceed with this and let you know my results. Thanks! >> >> On Wed, May 18, 2022 at 7:55 AM Jeffrey Cuenco <jeffrey.cue...@gmail.com> >> wrote: >> >>> Thanks Wade! >>> >>> I tried to regenerate using rfnocmodtool and noticed that the ce_clk and >>> ce_rst wires aren't present in the template code and the yaml files get >>> overwritten - is there another command for rfnocmodtool that I should be >>> using to regenerate after customizing the yaml? Thanks! >>> >>> -Jeff >>> >>> On Mon, May 16, 2022 at 11:07 AM Wade Fife <wade.f...@ettus.com> wrote: >>> >>>> 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
