LATC as a system doesn't provide an interface for manipulating the LATC xml as a system. Also, due to some features of the LATC compiler (LATC_parser), there are subtleties in attempting to simply "chain" different sets of XML together to create a correct description of the detector
The <foo> package contains a simple interface to an in-memory model of the LATC register space. A top level object, LATC_LAT, is provided which constitutes the top level interface to the LATC register hierarchy. This package contains several base classes: LATCComponent, LATCComponentDict, LATCRegister. The top level object is instantiated with a simple:
The base class of all LATC component objects (such as LATC_LAT, LATC_TEM, LATC_AFE). LATCComponent objects contain sets of LATCComponents and sets of LATCRegisters. These sets may be empty.
All LATCComponent objects define the following methods:
There also exists a more intuitive interface for LATCComponents. The user can reference the components and registers of a component by name. For example, the following two code snippets are equivalent:
A LATCComponentDict is a dictionary of LATCComponent objects. It inherits from the python dict class. It is used in component() dictionaries as a collection of substantively identical objects, mainly to ease the referencing of these objects.
A LATCRegister is a BitField with an integrated, unchangable field definition. It is constructed with a dictionary indicating the bit field names and positions. For example, the following code creates a LATCRegister with a name of engine_4, initialized to 0, with a set of bitfields spanning bits 0 through 29:
LATCRegisters implement the following methods:
Fields of a LATCRegister can be referenced in the same way as components of a LATCComponent: