and one more question: - How do we include 'rfnoc_chdr_utils.vh' in our out-of-tree rfnoc module? Is there a way to specify an include path so that we don't have to hardcode it?
On Wed, Sep 16, 2020 at 6:38 PM Rob Kossler <[email protected]> wrote: > Hi, > After playing around with UHD 4.0 and migrating existing applications & > custom blocks to 4.0, I have several questions (see below). > Thanks. > Rob > > - What is the status of the need for block controllers vs using > nocscript? The rfnoc spec shows example yml files with “registers” and > “properties” sections (and nocscript commands), but all blocks from Ettus > have these sections blank and all of the blocks have custom block > controllers. At NEWSDR, I asked a similar question to Jonathan Pendlum / > Michael West and they indicated that in UHD 4.0, the need for custom block > controllers should be relatively rare. > - Are there any plans to have rfnoc modtool part of UHD rather than > gr-ettus (in the near future)? This makes way more sense. > - Is there a limitation on the number of stream endpoints (e.g., is it > similar to the limitation of 16 CEs in UHD 3.15)? > - What are the advantages/disadvantages of making a multi-port block > vs having multiple one-port blocks for blocks like ddc, window, > keep_one_in_n, etc, that are really just multiple instances of 1-in, 1-out > modules? For example, are there resource or performance implications if I > build two 1-port DDC blocks or one 2-port DDC block in my image? > - Why does it matter if the addresses for user registers are in steps > of 4 rather than 1 if we are just using the addresses as essentially > identifiers? I understand that the address is intended as a byte address > of a 4-byte value, but it seems that the examples I have seen are just > using the address as an identifier. > - Will Ettus be providing replacements for blocks with deprecated > features such as settings bus registers? For example, in order to use > axi_rate_change, which uses settings registers, it’s easiest to use the > ctrlport_to_settings_bus module rather than using ctrlport directly. Should > we expect in the future that axi_rate_change (and similar blocks) will be > replaced by a future block? > - For timed commands in 3.15, only the Radio blocks were using the mb > time to trigger the desired action whereas other blocks such as DDC & DUC > implemented timed commands by comparing to timestamps in the CHDR stream. > Is this still true for 4.0? My question is not about “what is possible” > but rather “what is presently implemented” in Ettus blocks. > > > >
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
