A Software Package for the Configuration of Hardware Devices following a Generic Model

This paper describes a software package developed in C++ under the Linux environment that is intended for automatic hardware configuration in VME or PCI buses. Based on a generic model, users specify the configuration procedures and data in configuration files. Actual hardware configuration is performed by the software package, accessed through a simple C++ interface. The model is well suited for storage of configuration data in XML files or databases. The package is now being used in the local data acquisition system of the Electromagnetic Calorimeter of the CMS experiment at CERN.


Item Builder
The Item Builder allows the association of a hardware register, called item, to a data structure. These structures must be defined in a XML file, the Item Builder Structure file. Figure 1 shows the relationship among classes in the item builder package. There are two basic types of items: single and composite ones. Single items are associated with only one data field, while composite items manage contiguous memory regions. Users can specify if the memory region associated with the item is to be transferred into/from the hardware as a set of single bus accesses (default) or using block transfer operations. The access address can be set to be incremented automatically upon access (default) or to remain constant (FIFO access). A priority attribute can be specified. This is used when users want to build a list of ordered items. Memory regions can be defined as a set of words forming a contiguous block of bit segments (see example in Figure 2) or as a set of words, each one defining a set of bit segments (see example in Figure 3). In Figure 2 a composite item named CHANNELS is defined with a block of two words divided in single bit segments, each bit representing a channel state. The size of each word is the size defined in the HAL address table for the corresponding item (in this case 4 bytes, see also Table 1). In Figure 3 a composite item named WEIGHTS is shown with a block of 1000 words, each word with two 12-bit segments, representing two different weights (WEIGHTA and WEIGHTB).  After instantiation of an item object, the object is responsible for memory management allowing setting or getting any defined bit field. As an example consider a composite item as shown in Figure 3: If we want to set all weights A to value1 and all weights B to value2 we write: The data content of the item can be transferred into/from the hardware with the methods write/read (in this case as block transfers): Users may inspect all bit segments defined in the item through the method to see all the memory contents regardless the bit segments definition.  <CompositeItem name="WEIGHTS" blockTransfer="on" priority="2"> <SegmentedBlock length="1000"> <BitsSegment name="WEIGHTA" width="12" position="4" /> <BitsSegment name="WEIGHTB" width="12" position="16"/> </SegmentedBlock>

Configuration Model
Configuration data are classified as single or segmented configurables. Single configurables have a single data field that is associated with the data contents of a given single item (defined in Section 3). Segmented configurables are bit fields of a given composite item (defined in Section 3). In order to group configurables we introduce the Structure entity. Modules are specialization of structures with a given associated address (see Figure 4). A hardware device is represented as a module. The main module may contain sub-modules. When configuring items of a given sub-module their address offset will be determined according to the modules to which they belong. The model allows users to configure devices either from XML files or databases. In both cases the input of the Generic Configurator is a Document Object Model (DOM) [4] tree representing the device configuration. In order to minimize database storage space, it was chosen to represent modules and structures in terms of database tables and the module address, single and segmented configurables as columns of those tables. Concerning XML files, each element is characterized by a ¡ £ ¢ ¥ ¤ § ¦ © ¥ attribute. For modules and structures the tag name with its ID must also be specified as an attribute that is related to the table key in the database. For single configurable elements the tag name must be equal to the associated item name. For segmented configurable elements the tag name corresponds to the segment name and the respective index in which the data must be written. Figure 5 shows an example of a simple configuration with one main module, two sub-modules and one structure. Figure 5: Example of a configuration XML file and its representation in terms of a database scheme. The Dstore application allows independent access to XML files or databases (ORACLE and MySQL).

Configuration Procedure
In order to configure hardware modules, user applications must interface with the Device Configurator (see Figure 6). When requested to load a new configuration, the Device Configurator triggers the parsing of the configuration DOM tree as shown in the sequence diagram in Figure 7. Whenever a new module is found the base addresses of the main module and associated sub-modules are calculated.
When configurable elements are found in a module or a structure, the configurator tries to find out if the item with the offset given by the tree level has already been instantiated. If there is no such item a new item is created by the item builder. Items are added to the container list according to their priority, allowing the definition of priority dependent configuration procedures.  After the data has been copied into the item memory, the data are ready to be transferred to the hardware. This is done through the method allows to read-back data from hardware registers for validation purposes. In case of error(s) diagnostic information is given to the user. The configuration data are kept in memory allowing an optimized reconfiguration or configuration check at any time.
In the user application, after having built a new Device Configurator object, the configuration procedure is executed by the following code:

Conclusions
A new package has been described that allows automatic device configuration. Three inputs are needed: the proprieties of hardware registers to be accessed (HAL address table), the definition of the data structure associated to each hardware address (Item Builder Structure) and, finally, a DOM tree with the configuration data. The package is being successfully used to configure complex electronic devices, like the Electromagnetic Calorimeter Data Concentrator Card in CMS, which has more than 11000 configurable parameters.