I suggest looking at the simulation waveform of the inputs and outputs going to/from the IP core. Make sure all the inputs are driven (no red/blue signals; everything should resolve to green 0 or 1), check that the clocks and resets are doing the correct things (double check the IP documentation/configuration for reset polarity and reset duration requirements), and make sure the other inputs going into the IP are doing what they should be doing, then see what happens on the IP's output. Refer to the documentation to know what the IP needs on its inputs to work correctly and what the expected output should be.
Wade On Fri, May 20, 2022 at 4:02 AM Jeffrey Cuenco <jcue...@ucsd.edu> wrote: > Thanks Wade, I ended up regenerating using axis_pyld_ctxt and was able to > use the logpwr example again for generating a 2 to 1 output to input ratio > context. > > Now the testbench builds but it seems the IP block times out when I wait > for the output data to come out of the block.... at this point I'm not sure > what could be the root cause so I've attached a link to my entire project > tree containing the axi_conv.xci IP file, and all my logic for the noc > shell, rfnoc block, and testbench just in case there's something I'm doing > wrong in wiring up the IP core; the default for the IP core is rate 1/2 its > a fairly simple block that takes a stream of data in and outputs an > convolutional encoded stream of data out that is 2x the length of the data > going into it. > > > https://drive.google.com/drive/folders/1dOl9VMCPmuQLiXN4jSTTqgtFCQ19FmJT?usp=sharing > > I also posted the verilog files outside the tar.gz for convenience in case > you catch something obvious on first glance - want to make sure I didn't > miss anything in terms of clocks, data widths, etc. thanks! > > -Jeff > > > > On Thu, May 19, 2022 at 3:13 PM Wade Fife <wade.f...@ettus.com> wrote: > >> Regarding the payload/context change, it looks like the modtool sets the >> fpga_iface to axis_pyld_ctxt, but in conv.yml you changed it to axis_data? >> So when you ran rfnoc_create_verilog, it changed the interface type used by >> the NoC shell. You can read about "AXI-Stream Payload Context" and >> "AXI-Stream Data" interface types in the RFNoC Specification >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__files.ettus.com_app-5Fnotes_RFNoC-5FSpecification.pdf&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=Y3cOHwFMBDXttsqnINKoCyXB-ta6yD08QrmMzW9aeZY&m=iWIZIMJmjHh1GpWVAWXO6iGs641IqKVp_sQbEVackRZ-O08h4pR3Yi11Ui9cE0vs&s=_MwzXrHQa4GWT2C7uefcJvZJn_fsZMZuuJEPEl5eXzg&e=>. >> I think either could be used. >> >> Wade >> >> On Thu, May 19, 2022 at 4:18 PM Jeffrey Cuenco <jeffrey.cue...@gmail.com> >> wrote: >> >>> Thanks Wade! I just remembered that I forgot to set my output to input >>> ratio which may be explaining why the timeouts are happening even with the >>> extended delay. >>> >>> When I used the rfnoc_create_verilog, I noticed that the client >>> interface only has m_in_axis_* and s_out_axis_* connections and no >>> separation between context and payload for the template of noc shell used >>> by the tool. >>> >>> As such the logpwr example you shared with me earlier isn't >>> straightforward to port over and the duc example appears to be most >>> compatible pin-out wise with axi_rate_change so I'm about to attempt to >>> hook it up it but wanted to clarify that there aren't any additional >>> changes I would need to do aside from adjusting MAX_M, MAX_N, and ensuring >>> the input/output wire names match what are in my signal declarations >>> section? Thanks! >>> >>> -Jeff >>> >>> >>> >>> >>> >>> >>> >>> On Thu, May 19, 2022 at 12:36 PM Wade Fife <wade.f...@ettus.com> wrote: >>> >>>> 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/ >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_jeffrey-2Dg-2Dcuenco_&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=Y3cOHwFMBDXttsqnINKoCyXB-ta6yD08QrmMzW9aeZY&m=iWIZIMJmjHh1GpWVAWXO6iGs641IqKVp_sQbEVackRZ-O08h4pR3Yi11Ui9cE0vs&s=ZGYCaHwWOMjpAqMmR-3m3IR5aUs6l32qanEYTxW5gwU&e=> >>>>> >>>>>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
