On Fri, Jan 6, 2023 at 2:56 PM Rob Kossler <rkoss...@nd.edu> wrote: > On Fri, Jan 6, 2023 at 2:09 PM Brian Padalino <bpadal...@gmail.com> wrote: > > > > On Fri, Jan 6, 2023 at 1:11 PM Rob Kossler <rkoss...@nd.edu> wrote: > >> > >> On Thu, Jan 5, 2023 at 7:46 PM Brian Padalino <bpadal...@gmail.com> > wrote: > >> > Before RFNoC 4.0, there was a generic NoC shell that was used instead > of one being generated for each of the blocks. > >> > > >> > I see there is a noc_shell_generic_ctrlport_pyld_chdr, but it isn't > used anywhere. > >> > > >> > Is there a reason that a generic one isn't utilized and that ones are > being generated individually for each block? > >> > >> With RFNoC 4.0, you have various options for which interface you would > >> like for payload data and packet context data. These options, which > >> are in the block XML file, determine which signals get passed in and > >> out of your block. So, the reason it is custom is to handle the > >> variety of interface options. > > > > > > There are no more XML files, right? It's all YAML? Right? > > My mistake. You are right. > > > > > In the specification: > > > > https://files.ettus.com/app_notes/RFNoC_Specification.pdf > > > > ... section 2.5.5.3 shows axis_chdr, axis_pyld_ctxt, and axis_data. But > beyond that, I don't see any descriptions of the differences. Moreover, I > am unsure if I change the YAML and use rfnoc_image_builder to build things, > does that regenerate the underlying noc_shell_<block>.v file in the OOT > description? Or is it just an input to some other tool? I am also > confused by Figure 18 at the end of the document. I'm not sure I see any > XML files or the rfnocmodtool GUI? > > > > Lastly, I see rfnoc_blocktool in uhd under host/utils/rfnoc_blocktool > which has rfnoc_create_verilog.py which looks are fpga_iface but I didn't > see anything get installed from UHD. Is rfrnocmodtool from gr-ettus not > the right thing to use anymore? > > > > I might just be getting confused by out of date tutorials and > specifications, but figured I'd try to get my bearings straight. > > If we set aside "rfnocmodtool" for a sec (since this only seems to > come with gnuradio uhd which I don't have), I can say that the > procedure is the following: > - choose your desired options in the block yaml > - run rfnoc_create_verilog.py (it is in the UHD repo) to process the > yaml and produce several files including the custom noc_shell. Note > that this will overwrite existing files so you have to take > appropriate steps if you have some existing code and you later want to > change the yaml and re-run rfnoc_create_verilog. Note that the other > files produced are templates for your custom block and for a test > bench. > - modify the created templates to implement your desired logic > - run rfnoc_image_builder (or you can do the same thing with running > 'make' from an OOT build folder) to build the custom image. Although > this tool does access your block yaml, it does not produce a noc_shell > or other custom files. This is done as mentioned above with > rfnoc_create_verilog. > > If you use "rfnocmodtool", steps might be slightly different - I > haven't tried it since moving to UHD 4.x. > > Let me know if this is unclear or if you still have questions. >
I appreciate the clarifications. So it just seems the YAML is used for initial generation to help generate a noc shell that is customized but never recustomized by rfnoc_image_builder. Thanks, Brian
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
