I'm starting work on a application that consists of multiple sub-panels which each present a specific subset of the hardware functionality. The hardware appears to the host mostly as memory-mapped registers. I'm considering implementing the hardware interface in an Action Engine (AE) so that LV will automatically arbitrate among the hardware access requests from the sub-panels and because it (seems to me) to make the data flow more clear than the current implementation that uses a veritable plethora of queues, notifiers, and rendezvous to send requests and results between the sub-panels and the hardware interface at the top-level.
The challenge is this, though: Certain hardware addresses need to be modeled in multiple sub-panels -- maybe data at a certain address changes the functionality of some other addresses, or maybe different bit-fields within an address are part of different functional groups.
So any of sub-panel can request a read or write to the hardware, but often several of them need to see the resulting data.
In order to keep the design modular and expandable I don't want to hard-code anything in the hardware AE that is specific to the sub-panels. Instead, I intend to have the sub-panels "register" with the hardware AE indicating for which addresses they need to receive updates when some hardware address is read or written to. This means the AE will have to keep the "registration" data in an un-initialized shift-register (USR). But I want the hardware accesses to run as fast as possible, so I would like to ask for some suggestions how to implement this as efficiently as possible (avoiding, for example, clusters of arrays...)
I imagine the sub-panel registration info might consist of a user-defined event reference (created inside the sub-panel VI) and a list of hardware addresses that the sub-panel is modeling. Then when the hardware AE gets a request to read or write at some address it will also generate events to broadcast the data to the sub-panels that have registered for that address. This will probably include 20-25 subpanels registering for a collective total of about 700 hardware addresses.
I'm less concerned about memory than speed.
So, a few possibilities come to mind for how to implement the registration data in the AE USR:
A) Have one 2-D array where the array contains one row per hardware address (~320), and columns contain the event refs for all the sub-panels registered for that address. The width of the array would depend on whichever address has the greatest number of sub-panels registered for it (maybe 4-5?), but that still means the array would be pretty large (about 6.5 kbytes if a reference is a 32-bit value?)
On the other hand, indexing into this array to look up the sub-panel references for the current address would be relatively quick and easy since the hardware address is the row number.
B) Have two arrays where the array size is the number of sub-panels: One 1D array for the registered event refs and one 2-D array for the addresses. But different sub-panels will have different quantity of addresses registered, so that means the "width" of the address array would be as big as the largest number of addresses registered by one sub-panel (maybe 20?). This would use a total of only about 1.5 kbytes, but I would have to search through all 25 address arrays to see if the current address is registered.
C) or, some other way that I have not though of.
Once the "registration" data is received from the sub-panels during program initialization it is never changed, only read. So at first glance it would seem (A) would be the faster implementation. But I don't know what, if any, performance hit there would be from having such a large array in a USR, which is why I'm asking here.
Any thoughts or suggestions would be greatly appreciated.
Thank you and Best Regards,
-- J.
