On 9/17/20 12:38 AM, Rob Kossler via USRP-users 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
Hi Rob, great questions. I'll take a stab: > * 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. As of yet, we don't have Noc-Script support or anything similar. That means you actually do need a C++ block controller for every block. We are aware that this isn't great for simple use cases, but we're also not convinced that Noc-Script itself is the way to go. For a start, it was getting difficult to expand the capabilities of Noc-Script, and in this use case, an existing language (instead of a DSL) might be more appropriate. > * Are there any plans to have rfnoc modtool part of UHD rather than > gr-ettus (in the near future)? This makes way more sense. Yes, at we've started doing parts of that. What we haven't decided yet is how to implement the exact relationship between GNU Radio code and non-GNU Radio code. So let's ignore GNU Radio for a second. The UHD part shall come from UHD, as you say. > * 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)? You don't have that same 16-port limitation (more is possible), but the crossbar scales with O(N**2) IIRC. The idea is certainly to keep the number of SEPs as small as possible to minimize the footprint of the crossbar. > * 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? There are no performance implications in this case. The resource utilization will go down if you combine more ports into one block. The disadvantages of doing that are: - Every block is a consumer of commands. That means you will be sending more commands to the same block which could theoretically become a bottleneck. - Possibly worse match to a mental model (this is clearly subjective). In our X310 image, we have 2 DDC blocks for 4 DDCs total. This just looks and feels better: Every radio is matched one DDC block. The image core YAML is less confusing. If we want to leave out the DDCs on one channel, it's more clear what to remove. And so on. - Block controllers could possible become more complicated, but that's use case specific. - Block parameters are often per-block, not per-channel. That could be implemented differently, but that's up to the block author. For example, the max CIC decim/interp values are per-block. > * 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. It doesn't matter for the hardware. For us humans, we decided that with UHD 4, we'll stop mixing and matching the addressing schemes. There were some things (usually memory-mapped registers) where the steps-of-four is obviously necessary. RFNoC blocks in UHD 3 used steps of 1. Because the former (memory-mapped) is not something anyone wants to change, we decided that all register peeks/pokes, regardless of if they're really memory-mapped or not, shall be treated as such. Hence the steps-of-four. > * 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 the X310 radio block, we probably won't. There's a lot of debugging in there, and the X310 peripherals (which still use settings bus) wouldn't benefit from an update. For the DDC/DUC blocks, we intend to move away from settings bus in the long run. I don't have a list of blocks using settings bus, but in principle, we want to get rid of it as much as possible, it's just there's more important stuff to do. > * 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. What's presently implemented is the same as in 3.15. That said, the time is no longer the "radio time", so custom blocks could also trigger off of real time just like the radio does. --M _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
