You have to specify context_fifo_depthwhen using axis_pyld_ctxt. See, for example, the addsub block.
On Tue, Mar 16, 2021 at 11:56 AM Julian Casallas <[email protected]> wrote: > Jonathon, > > Based on the specification I tried the following options using the same > gain.yml created according to the RFNoC 4 video. The python tool used is > *rfnoc_create_verilog.py.* > > 1. axis_data. Results *ok* but with all the AXI signals. > 2. axis_chdr. Results *ok* but with the chdr signals. > 3. axis_pyld_ctxt. unfortunately this is the error I am getting: > > File "rfnoc_create_verilog.py", line 104, in run > block = tpl.render(**{"config": self.config, > File "/usr/lib/python3/dist-packages/mako/template.py", line 476, in > render > return runtime._render(self, self.callable_, args, data) > File "/usr/lib/python3/dist-packages/mako/runtime.py", line 878, in > _render > _render_context( > File "/usr/lib/python3/dist-packages/mako/runtime.py", line 920, in > _render_context > _exec_template(inherit, lclcontext, args=args, kwargs=kwargs) > File "/usr/lib/python3/dist-packages/mako/runtime.py", line 947, in > _exec_template > callable_(context, *args, **kwargs) > File > "/home/wisp/uhd/host/utils/rfnoc_blocktool/templates/noc_shell_template.v.mako", > line 198, in render_body > <%include file="/modules/axis_pyld_ctxt_modules_template.mako"/>\ > File "/usr/lib/python3/dist-packages/mako/runtime.py", line 795, in > _include_file > callable_(ctx, **kwargs) > File > "/home/wisp/uhd/host/utils/rfnoc_blocktool/templates/modules/axis_pyld_ctxt_modules_template.mako", > line 56, in render_body > .CONTEXT_FIFO_SIZE ($clog2(${port_info['context_fifo_depth']})), > KeyError: 'context_fifo_depth' > > This is the *demo.yml* file which is the same *gain.yml* but with > different name and highlighted is the key that I used for the data > interface. > > 1 > 2 schema: rfnoc_modtool_args > 3 module_name: demo > 4 version: 1.0 > 5 rfnoc_version: 1.0 > 6 chdr_width: 64 > 7 noc_id: 0x0000DE30 > 8 makefile_srcs: > "/home/wisp/rfnoc_ws/rfnoc-test/rfnoc/fpga/rfnoc_block_demo/Makefile.srcs" > 9 > 10 clocks: > 11 - name: rfnoc_chdr > 12 freq: "[]" > 13 - name: rfnoc_ctrl > 14 freq: "[]" > 15 - name: ce > 16 freq: "[]" > 17 > 18 control: > 19 sw_iface: nocscript > 20 fpga_iface: ctrlport > 21 interface_direction: slave > 22 fifo_depth: 32 > 23 clk_domain: ce > 24 ctrlport: > 25 byte_mode: False > 26 timed: False > 27 has_status: False > 28 > 29 data: > 30 * fpga_iface: axis_pyld_ctxt* > 31 clk_domain: ce > 32 inputs: > 33 in: > 34 item_width: 32 > 35 nipc: 1 > 36 info_fifo_depth: 32 > 37 payload_fifo_depth: 32 > 38 format: int32 > 39 mdata_sig: ~ > 40 outputs: > 41 out: > 42 item_width: 32 > 43 nipc: 1 > 44 info_fifo_depth: 32 > 45 payload_fifo_depth: 32 > 46 format: int32 > 47 mdata_sig: ~ > > > Thanks > > On Tue, Mar 16, 2021 at 12:24 PM Jonathon Pendlum < > [email protected]> wrote: > >> Hi Julian, >> >> Generally, ctrlport and axis_pyld_ctrl are the correct choices. One >> exception is when writing a block that changes sampling rate. You may want >> to use axis_chdr so you can easily interface with the axi_rate_change >> module. The DDC / DUC are examples of that use case. >> >> Jonathon >> >> On Tue, Mar 16, 2021 at 11:52 AM Julian Casallas <[email protected]> >> wrote: >> >>> Dear Jonathon, >>> >>> Thanks for your prompt reply, I checked the specification but before >>> your reply, I was looking into the *rfnoc_create_verilog.py script *and >>> the block *demo* yaml file. I found the key *fpga_iface, *for control >>> and data, has 2 options: >>> >>> 1.ctrlport or axis_ctrl >>> 2. axis_chdr or axis_pyld_ctxt >>> >>> The specification mentioned them too. However, the RFNoC 4 video talks >>> about payload/context interface so could you please advise which should we >>> use to be consistent? >>> >>> Thanks >>> J >>> >>> On Tue, Mar 16, 2021 at 11:13 AM Jonathon Pendlum < >>> [email protected]> wrote: >>> >>>> Hello Julian, >>>> >>>> For a multiple input / output port block, you will need to use >>>> rfnoc_create_verilog with your own block definition yaml file. The RFNoC >>>> specification ( >>>> https://files.ettus.com/app_notes/RFNoC_Specification.pdf) has >>>> information on the yaml file format in section 4.2.2. You can also look at >>>> the existing blocks in the UHD source tree for inspiration: >>>> https://github.com/EttusResearch/uhd/tree/master/host/include/uhd/rfnoc/blocks. >>>> For example, take a look at addsub.yml for a block with two fixed input / >>>> output ports and fir_filter.yml for a block where the number of ports is >>>> based on a parameter called NUM_PORTS. >>>> >>>> Jonathon >>>> >>>> On Tue, Mar 16, 2021, 10:15 Julian Casallas <[email protected]> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I went through the Getting Started with RFNoC UHD 4 guide and I >>>>> followed the RfNoC 4 WorkShop - GRCon 2020 to design a RFNoC block, this >>>>> is >>>>> what I did: >>>>> >>>>> 1. Created the gain block and it works fine following the RFNoC 4 >>>>> video. I checked the HDL files, and I could see the interfaces payload and >>>>> context were created between NoC Shell and the User Logic as expected. >>>>> >>>>> 2. Then I went ahead and created my own block, *not* using the >>>>> *rfnocmodtool *but in this case using the *rfnoc_create_verilog.py *tool >>>>> following the UHD 4 guide based on the same gain.yml file for testing >>>>> purposes, however, the verilog files created in this case do not use >>>>> payload/context approach. >>>>> >>>>> I was hoping that following the UHD 4 guide to design new blocks using >>>>> the python script I could get the same verilog files used in the video. >>>>> >>>>> Therefore, my question is, what is the process to add a block with >>>>> multiple inputs and outputs using RFNoC 4? >>>>> >>>>> Thanks >>>>> J >>>>> _______________________________________________ >>>>> USRP-users mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> >>>> _______________________________________________ > USRP-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
