On Mon, Nov 7, 2022 at 6:29 PM Marcus Müller <marcus.muel...@ettus.com> wrote:
> Hi sp, > > That sounds like a bad idea. How are you planning to synchronize access to > that register? > > Generally, in almost *any* context, avoid global state. That makes things > complicated and > error prone; this is true for python as much as it is for C++, as much as > it is for > digital hardware design (in verilog or any other way); it's even true for > design of > mechanical machine factory floors (if you make each processing step as > independent from > the other as possible, you increase reliability). > As a point of order, though, reducing redundancy is also an admirable goal. I think the idea of sharing registers between multiple RFNoC blocks is not a bad idea. It's the idea of a single configuration space with fanouts to multiple consumers. In C++, imagine it as a singleton of configuration parameters to be referenced during execution. As a practical example, imagine you have a TDMA system which needs timings defined by which the TX and RX both adhere. Or a modulation/coding scheme which is shared between RX and TX. These are independent blocks with common configuration items. A suggestion to duplicate registers would not be seen as appropriate - there is a singular configuration space with fanout to multiple blocks. >From an FPGA perspective, it is not unheard of that a registerfile may be common amongst numerous individual blocks which make up a system. The suggestion earlier, I believe, was to have a custom input to the block which is the shared configuration space. Now, speaking in terms of RFNoC, I imagine this as an RFNoC block which is the configuration space, and has no flows in or out but only exists in the register space. It has outputs which fanout but no other inputs. Is there a document which describes how to build this type of system with RFNoC? Custom output/input port automatically instantiated with the system? Or does it need to be a custom instantiation after the rest of it has been templated? Thanks, Brian
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
