LATC_parse Input Verification

Background

LATC_parse

LATC_parse (or command-line equivalent LATC_parser) accepts as input a list of xml files specifying register settings. It outputs one or more binary files (up to 15 with current design). There is at most one output file per component class (GEM, AEM, ARC, AFE,...). An output file for a particular class will be generated if

Most component classes include multiple instances; e.g. there may be a TEM instance for each tower. If a particular component (e.g. TEM for tower 1) is not represented in the collection of TEM binaries used to initialize the LAT, registers in that component will be initialized using the values specified in DFT (default component). From the LATC Users' Guide:

LATC contains the concept of a default (DFT) or "golden" configuration. This default configuration contains one block of data for each component, specifying the default values of that component's registers. When the LAT is configured this default configuration is applied first. Any instances that have non-default (sometimes termed exceptional) configurations are then reloaded with new values.

NOTE: If only some of the TEM register values have been specified for a particular instance the registers whose values are unspecified will not, in general, be set to the values in DFT because configuration information is applied for a full component at a time. Registers not specified by the user in the exceptional configuration input will nonetheless have a value in the binary output (cleared) and these values will overwrite the values in DFT.

The authoritative references for LATC_parse operation are the LATC Users' Guide and the LATC Design document.

MOOT use of LATC_parse

The LATC partitioning of LAT configuration into components is strongly influenced by the electronics design: registers accessible by a common electronics path tend to end up in the same component. However the LATC component division can be inconvenient for configuration management; for example the TEM component lumps together registers "belonging" to CAL with others "belonging" to TKR. While all registers in the CFE component would normally be managed by CAL, new values for thresholds may be be generated on a different time scale than those for enables.

One of the goals of MOOT is to bridge the gap between the electronics-based register partitioning of LATC and a partition more suitable for higher level configuration management. Ultimately, MOOT must generate a collection of binaries which respect the component division imposed by LATC, but at the source level it is possible to subdivide more finely. The expectation is that MOOT will generate a single binary for most component classes (e.g., one TEM binary for all 16 TEM instances). The TFE component class, since instances can be quite large, is a likely candidate for division into per-tower binaries; there may be others. (At this time MOOT has no machinery to keep track at the binary stage of finer than per-tower division, but it could be added if necessary, as long as no single component is split across multiple binaries.) Each of the binaries will be generated by supplying a list of source files—which need not individually cover entire components—as input to LATC_parse. For example, there might be two input files for CFE: one defining enables and range selection for all CFE component instances, the other for thresholds.

Specification of the Verifier

Input to the Verifier will consist of

The Verifier must have access to the dtd (latc.dtd) which governs the form of LATC input files, but this dtd does not impose all the constraints needed to insure that even a single file is sensibly constructed, let alone the list of files the parser will see. At a minimum, for component classes other than DFT, GEM and AEM, the Verifier should check:

  1. no register field is initialized in more than one file
  2. if one register for a particular component instance is initialized, all registers (all owned by LATC, that is) for that component instance are initialized somewhere in the list of files (need not be in the same file, however). This check will protect against unintuitive LATC behavior.
  3. If a list of component instances has been supplied, check that all registers appearing in the xml source files belong to one of the instances in the list.

Analogous checks should be made for default (DFT), AEM and GEM component classes, each of which only has one instance:

  1. no register field is initialized in more than one file
  2. all register fields owned by LATC in these components must be initialized.
  3. only registers belonging to the single component instance in the class may appear in the xml source files.
Initial draft: 2 Oct 2006
Last revised: 		J. Bogart jumping