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
