Hi Cédric, I'll attempt to answer your questions. I'm more familiar with the hardware/HDL side of things.
1. The default clock for rfnoc blocks is rfnoc_chdr_clk and this clock is always present. You can use this clock for everything, unless you need a different clock (e.g., a faster clock to increase DSP throughput). I suggest not using different clocks unless you need to. I don't know why keep_one_in_n uses ce_clk, but any block can use it if the writer of that block wants to. 2. When using AXI-Stream Data the length is automatically calculated, assuming SIDEBAND_AT_END is set to true (which is the default). If you drop all samples, then you don't put anything into the NoC Shell, so no packet would be generated. 3. I'm not familiar with how keep_one_in_n works, but the timestamp is just a count of the samples. So if you wanted to generate a new timestamp, you would just keep a count of the samples. The timestamp for a packet should be the timestamp for the first sample of the packet. 4. The info_fifo_depth effectively controls how many packets can be buffered in the NoC shell at a time. Normally there are only a couple of packets buffered at a time, so it doesn't need to be very big. This FIFO is often implemented using SRLs, so I often use 32, which is the maximum SRL size. 5. Yes. In other words, NIPC sets the width of the tdata port. It's always NIPC items wide. 6. I believe that sw_iface isn't implemented yet and I don't think this key is currently required. I think C++ refers to the RFNoC C++ API and nocsript refers to NoC-Script (a concept from UHD 3.x but not yet implemented in UDH 4). 7. This also isn't implemented yet, but I believe it's a way of identifying the type of metadata. 8. Correct, the "registers" and "properties" sections aren't implemented yet. These sections will allow the tools to generate hardware registers and software properties automatically in the future, making new blocks easier to create. 9. Parts of it are implemented. You can find rfnocmodtool in gr-ettus (see the recent RFNoC 4 Workshop <https://youtu.be/M9ntwQie9vs?t=2315> video for a demo). The rfnoc_create_verilog tool (in UHD) does the hardware generation part (generating the HDL and testbench templates; see the Getting Started document you referred to for an example of using that tool directly). I hope this helps! Thanks, Wade On Wed, Dec 23, 2020 at 12:37 AM Cédric Hannotier via USRP-users < usrp-users@lists.ettus.com> wrote: > Dear all, > > I am reading the RFNoC Specification PDF (version 0.7), > and I have several questions. Any help is appreciated. > > 1. In AXI-Stream Data (2.3.3.3), axis_data_clk is provided. > However, some blocks use ce_clk instead. Why? > In [1] it is stated: > "Many other blocks require the ce (Compute Engine) clock, > which is used for the block's internal DSP". > However, I cannot see any "internal DSP" in rfnoc_keep_one_in_n.v. > In which case should I prefer ce_clk? > > 2. In AXI-Stream Data (2.3.3.3), I have no control over CHDR header. > What happens when the block drop samples (e.g. keep_one_in_n.v)? > Is the NoC Shell updating header field automatically (eg. length field)? > 2bis. What happends if I drop all samples of a packet? > > 3.In rfnoc_keep_one_in_n.v, it seems that it drops the timestamp if > the sample to keep is not the first sample in the packet. > Is the timestamp recomputed afterwards? > If not, how could I compute the timestamp instead of dropping it? > > 4. In NoC Shell Generation Options (2.3.3.4), > there are some fifo parameters (e.g. info_fifo_depth). > What are their purposes? > How should I choose a depth value? > > 5. In AXI-Stream Payload Context (2.3.3.2), it is stated: > "NIPC: The number of items delivered per cycle. > NIPC must 1 or a larger power of 2, such that ITEM_W * NIPC = CHDR_W." > Does it also apply for AXI-Stream Data (2.3.3.3)? > If not, what is the rule for that Data-Plane ? > > In Input Format (4.2), the following keys are not documented: > - sw_iface (nocscript, c++) > - mdata_sig (~, MD5 sum) > > 6. Is the nocscript meaning we have to rely on the UHD C++ RFNoC API to > interact with blocks and the c++ meaning we implement a custom C++ API? > > 7. What is mdata_sig? > > 8. Keys "registers" and "properties" seem unused, should I use them? > > 9. In Figure 16 (4.2), I was unable to find how to use RFNoC ModTool > with a YAML file. Is it not implemented yet? > > [1] > https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Understanding_the_RFNoC_Image_YAML_File > > Kind regards > > Cédric Hannotier > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
