blaster interface and block methods

[jsturdy]

Brief summary of issue

To implement the BLASTER config interface, we need to take BLOB inputs (probably just uint32_t* or std::vector<uint32_t>), and block write them to the HW.
Such functions currently exist for uhal, but I don't see anything equivalent in ctp7_modules (perhaps it is defined elsewhere, i.e., xhal?). There is a readblock, so I suppose writeblock just needs to be implemented similarly.

Types of issue

• Feature request (request for change which adds functionality)

Expected Behavior

RAM interface functions

Adding the following RAM interfaces, for some form of finer granularity (could consider further granularity for very specific config access):

bool writeConfRAMLocal(localArgs *la, uint32_t* blob);
bool writeGBTConfRAMLocal(localArgs *la, uint32_t* gbtblob);
bool writeOptoHybridConfRAMLocal(localArgs *la, uint32_t* ohblob);
bool writeVFATConfRAMLocal(localArgs *la, uint32_t* vfatblob);

block transaction functions

It would probably be good to have some distinction between read/write from/to successive addresses, and read/write from/to an actual block.
In the former, no validation is needed, in the latter:

• writeBlock (or something) should do validation on the address being written to, to validate the size and type
  • data being written must fit in the address space
  • address/register provided should be declared as a block
• readblock (or something) should possibly do the same validation, as the current implementation doesn't make any semantic connection to a block, other than that the address space be continuous.

[jsturdy]

Configuration methods (writing down thoughts):

• The configuration source should be able to be:
  • taken from CTP7 based text files
  • taken from CTP7 BLASTER RAM
  • taken from passed data
• For a given class of hardware, one should be able to configure:
  • a single device
  • all devices specified by a "mask"
  • all supported devices (possibly with a check on connectivity)

Sources

BLASTER RAM configuration

• Currently, at the most granular, configurations are accessible only on a per OH
• For configuration of a specific GBT/VFAT, manipulation on the returned data must be performed to select the appropriate data to send to a function that can interface with a specific, single device.

Input data

Text files

• Already in place for VFATs

Interfaces

• configure<device>(<device>N)
• configure<device>s(<device>Mask): default to all for GBT and VFAT, what for OH?

[jsturdy]

I've got things more or less set up here (and corresponding interfaces in cmsgemos)
I don't know if I'm completely satisfied with things, but I think the overall structure will not change.