Hi Nick, Maybe others will chime in but I'll share what I know. The intent was to have a new block tool that would generate Verilog and C++ templates for a complete block, but it wasn't completely finished for the UHD 4.0 release. It currently generates all the HDL, but register generation and the software template generation wasn't completed. That's why there's a "registers" section in the YAML. I'm not familiar with the plans regarding merging the modtool and block_tool.
As for rfnoc_chdr_clk and ce_clk, you are correct. These are analogous to bus_clk and ce_clk in UHD 3.15 and earlier. In some cases, the clock used for DSP needs to be faster than rfnoc_chdr_clk, so some blocks allow you to use a different clock (ce_clk) for the internal DSP. In other blocks this isn't necessary, often because they can keep up with the full rate of rfnoc_chdr_clk. The name "ce_clk" in UHD 4.0 is arbitrary (you can rename it to whatever you want for a block) but the rfnoc_chdr_clk is required by each block. Thanks, Wade On Mon, Nov 23, 2020 at 7:31 PM Nick Foster via USRP-users < usrp-users@lists.ettus.com> wrote: > Just had a few q's regarding RFNoC in UHD 4.0 as I migrate my applications > to it. > > > 1. In the style of a tedious conference Q&A session, this is more of a > comment than a question: I noticed NoCScript is dead: great! But it sure > would be nice if there were something which filled the role of obviating > the need for explicit block controllers for simple blocks. > 2. I noticed both the "registers" sections of the YAML definitions are > unused in stock UHD blocks and unlooked-for in rfnoc_blocktool's > templating process. I also noticed a lot of <block_name>_regs.vh > register definition files in the RFNoC Verilog blocks included in UHD, > which look suspiciously like autogenerated boilerplate. Seems like > something which would be reasonably straightforward (I say, having not done > it myself) to implement in rfnoc_blocktool. What am I missing? > 3. I'm a little unclear on the difference between the rfnoc_chdr clock > and ce_clk. Some block definitions just use one, some use both. I'm > assuming the rfnoc_chdr clock is equivalent to the old bus_clk. Is the > lack of a ce_clk in the block definition just to avoid having to route > ce_clk to logic which doesn't require it? Is ce_clk decoupled entirely > from radio_clk now on X310? > 4. Is there a plan to integrate rfnoc_modtool and rfnoc_blocktool? At > least within the same repository? The overlapping functionality between > them is confusing. It would be a huge reduction in boilerplate madness if a > single YAML block definition could result in both Verilog blocks and > coordinated C++ block controllers being generated. > > Thanks for all the work on this: UHD 4.0 looks like a major improvement. > > Nick > _______________________________________________ > 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
