The testbench has start_test() and end_test() calls around each test. There's a timeout in the start_test() call, and there's also a global timeout (part of start_tb(), but I think 10 ms by default). If the end_test() doesn't occur within a certain amount of time of the start_test(), then the testbench assumes something went wrong. Otherwise, the simulation could just keep running forever.
So you'll need to look at your simulation to see where things are getting stuck. Also, make sure what you're doing doesn't just need more time. Wade On Thu, May 19, 2022 at 2:29 PM Jeffrey Cuenco <jeffrey.cue...@gmail.com> wrote: > Thanks Wade! I used the rfnoc_create_verilog and it generated code that > contained ce_clk and added > > output wire ce_rst; > > following the ce_clk declaration around line 32 of rfnoc_block_conv.v in > the generated file, then plugged it into .ce_rst of noc_shell_conv later in > the file and also used it in my axi_conv instantiation. > > After doing that and building I was able to get the testbench to run but I > now get a fatal timeout, something about time limit exceeded. > > Is there something that needs to be wired in so that it knows when things > finish? Thanks! > > -Jeff > > On Thu, May 19, 2022 at 12:23 Wade Fife <wade.f...@ettus.com> wrote: > >> I think those versions are fine, but your gr-ettus might be out of date. >> I'm not very familiar with the GNU Radio integration. You could try >> updating your gr-ettus then regenerate your block, or you could run the >> rfnoc_create_verilog tool using the YML file as an input if you need to >> customize the YAML to add the ce_clk/ce_rst signals. It's really up to you >> if you need those signals. But your IP needs to be clocked and probably >> reset by something, and you need to make sure the generated noc_shell uses >> the same clock domains you're expecting to use. >> >> >> Wade >> >> On Wed, May 18, 2022 at 10:10 PM Jeffrey Cuenco <jeffrey.cue...@gmail.com> >> wrote: >> >>> Neel recommended I use UHD v4.1.0.5 and GRC v3.8.5.0 so that’s what I’ve >>> been using - does this version not generate the right items? If not which >>> version of UHD should I update to, and which version of GRC works best with >>> it? Thanks! >>> >>> -Jeff >>> >>> On May 18, 2022, at 19:59, Wade Fife <wade.f...@ettus.com> wrote: >>> >>> >>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_gr-2Dettus_blob_master_python_rfnoc-5Fmodtool_templates.py-23L994&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=Y3cOHwFMBDXttsqnINKoCyXB-ta6yD08QrmMzW9aeZY&m=1DdbigE2N0YgkBb5QwxGwLoaLzBicQiQrNdYgLIklkzVPw_RkRIL9bq4dINC9Cqd&s=fKouuct_wr3CdcChBQjBmaL6WDVq7l3U1zAVR7DcnDY&e=> >>> >>> https://github.com/EttusResearch/gr-ettus/blob/master/python/rfnoc_modtool/templates.py#L1384 >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_gr-2Dettus_blob_master_python_rfnoc-5Fmodtool_templates.py-23L1384&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=Y3cOHwFMBDXttsqnINKoCyXB-ta6yD08QrmMzW9aeZY&m=1DdbigE2N0YgkBb5QwxGwLoaLzBicQiQrNdYgLIklkzVPw_RkRIL9bq4dINC9Cqd&s=g8-XZVaLen6JS347_frcJqnHnCFTxWbAtw1WcLKrtzA&e=> >>> >>> 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 >>>>>>>>>>>> >>>>>>>>>>> -- > > > > Jeffrey Cuenco > Tech & Marketing Specialist | Cooperative Capitalist > (619) 840-4508 > jeffrey.cue...@gmail.com > > LinkedIn: > https://www.linkedin.com/in/jeffrey-g-cuenco/ > >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
