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 >>>>> >>>>> >>>>> 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 >>>>>> >>>>>> 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
