Mce status
The primary purpose of mce_status is to provide a snapshot of the MCE configuration. This is most important just prior to acquiring frame data, in order to properly interpret the frame output in subsequent analysis.
The secondary function of mce_status, or, at least, the primary secondary function of mce_status, is to provide a summary of the mappings that MAS uses to translate card and parameter names into MCE hardware addresses.
Contents
Usage
If mce_status is invoked without command-line arguments, it will produce a snapshot output and exit. Otherwise, mce_status may be invoked as:
mce_status [OPTION]...
where the available options are:
-c <hardware config> choose a particular hardware config file -d snapshot style, dirfile output (See snapshot output below) -f <output filename> redirect output to filename instead of standard output -g dump parameter mapping (See mapping output below) -G dump extended parameter mapping (See mapping output below) -m <mas config> choose a particular mce config file -n <card number> use the configuration for the specified fibre card. Ignored if not running Multicard MAS. -o <output directory> if the file path specified by -f is not absolute, assume it's relative to this directory -s snapshot style, civilized format (See snapshot output below) -h or -? show usage information and exit -v print version string and exit
Snapshot output
When invoked in snapshot mode (i.e. when not passed -g or -G), it scans the MCE hardware configuration file and issues read commands to each card/parameter name pair in the file. The default output format is in runfile format, a pseudo-XML format, but this can be changed with the -d or -s option. The different formats are discussed below.
Runfile format
This is the default format, which will be used if no other format is specified. The output block has the following form:
<HEADER> [...] <RB cc slot_id> 00000008 <RB cc fw_rev> 83886094 <RB cc led> 00000007 <RB cc scratch> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [...] </HEADER>
This is a compliant runfile block, alas. Notably all parameters are reported in decimal, zero padded on the left to 8 digits. The entire output is enclosed in a <HEADER> runfile block.
If an error occurs while fetching a parameter, it will be reported as ERROR and scanning will continue with the next parameter:
<RB cc slot_id> ERROR
Civilized format
This format is selected with the -s option, and is designed to be easy for people to read. Some parameters are output in hexadecimal, indicated by a leading 0x. Parameters are not zero padded and hash-mark (#) delimited header and footer is produced. Sample output:
# Begin snapshot, ctime=1399501383 # Date: Wed May 7 15:23:03 2014 [...] cc slot_id : 8 cc fw_rev : 0x500000e cc led : 0x3 cc scratch : 0 0 0 0 0 0 0 0 [...] # End snapshot, ctime=1399501383
If an error occurs while fetching a parameter, it will be reported as ERROR and scanning will continue with the next parameter:
cc slot_id : ERROR
Dirfile format
This format is selected with the -d option. It produces a Dirfile metadata fragment containing the data. The output conforms to Dirfile Standards Version 8, and should be readable by any version of the GetData library starting with 0.7.0 (released November 2010). It additionally contains information on the origin of the fragment (under the mce_status entry).
Sample output:
/VERSION 8 mce_status STRING "mce status" mce_status/ctime CONST UINT64 1399501193 mce_status/date STRING "Wed 7 May 22:19:53 UTC 2014" mce_status/author STRING "dvw" mce_status/host STRING "mce-ubc-1" mce_status/version STRING "MAS/trunk/801" [...] cc STRING "clock card" cc/slot_id CONST INT16 8 cc/fw_rev CONST UINT16 83886094 cc/led CONST UINT16 3 cc/scratch CARRAY INT16 0 0 0 0 0 0 0 0 [...]
If an error occurs while fetching a parameter, the parameter will be removed from the metadata and replaced by a comment, reporting the error with ERROR, and scanning will continue with the next parameter:
# cc/slot_id ERROR
Mapping output
When invoked with the -g option, mce_status scans the hardware configuration file and outputs first the list of direct hardware mappings (physical maps), and then the list of functional mappings (virtual maps). With the -G option, even more parameter info is given.
One record is output for each parameter in the hardware configuration file, one record per line. There are two different types of records, one for physical mappings (parameters associated with physical cards like cc or rc1, including the special "cards" rca, rcs, and sys), and a different one for virtual mappings (parameters associated with virtual cards like tes or sq1).
Physical maps
With -g, a physical map record looks like:
physical <card_name> <param_name> 0x<param_num> <card_count> cards: 0x<card_num>...
<param_num> and <card_num> are given in zero-padded hexadecimal with a leading 0x. Example:
physical cc slot_id 0x95 1 cards: 0x02 physical cc fw_rev 0x96 1 cards: 0x02 physical cc led 0x99 1 cards: 0x02 physical cc scratch 0x9a 1 cards: 0x02 physical cc upload_fw 0x50 1 cards: 0x02 physical cc config_fac 0x51 1 cards: 0x02 physical cc config_app 0x52 1 cards: 0x02 [...] physical sys row_len 0x30 9 cards: 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a physical rca row_len 0x30 4 cards: 0x03 0x04 0x05 0x06
With -G, this is extended to include an element count and a "write-only" flag:
physical <card_name> <param_name> x<elem_count> <wonly_flag> 0x<param_num> <card_count> cards: 0x<card_num>...
<elem_count> is given in zero-padded decimal with a leading x. Example:
physical cc slot_id x01 0x95 1 cards: 0x02 physical cc fw_rev x01 0x96 1 cards: 0x02 physical cc led x01 0x99 1 cards: 0x02 physical cc scratch x08 0x9a 1 cards: 0x02 physical cc upload_fw x58 ! 0x50 1 cards: 0x02 physical cc config_fac x01 ! 0x51 1 cards: 0x02 physical cc config_app x01 ! 0x52 1 cards: 0x02 [...] physical sys row_len x01 0x30 9 cards: 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a physical rca row_len x01 ! 0x30 4 cards: 0x03 0x04 0x05 0x06
NB: the "write-only" flag, which appears as an exclamation mark (!), is set for every parameter which is skipped by mce_status in snapshot output. This includes a few parameters which can be read back (such as the rca/row_len above). So, a better name would be something like "non-status" flag.
Virtual maps
With -g, a virtual map record looks like:
virtual <card_name> <param_name> maps: <map> [map]...
One or more maps may appear, depending on whether the virtual card maps to more than one physical card. A map looks like:
[(<first_index>,<count>)->('<card_name> <param_name>'+ <offset>)]
which indicates that elements <first_index> through <first_index>+<count> (inclusive) of the virtual card parameter are mapped to elements <offset> through <offset>+<count> of physical <card_name>/<param_name>. The <offset> parameter is left-padded with spaces. Example:
virtual sq2 bias maps: [(0,16)->('bc1 flux_fb'+16)]
virtual sq1 servo_mode maps: [(0,8)->('rc1 servo_mode'+ 0)] [(8,8)->('rc2 servo_mode'+ 0)]
virtual sa fb maps: [(0,16)->('bc1 flux_fb'+ 0)]
virtual sa bias maps: [(0,8)->('rc1 sa_bias'+ 0)] [(8,8)->('rc2 sa_bias'+ 0)]
With -G, this is extended with the element count:
virtual <card_name> <param_name> x<elem_count> maps: <map> [map]...
<elem_count> is given in zero-padded decimal with a leading x. The map format is not changed. Example:
virtual sq2 bias x16 maps: [(0,16)->('bc1 flux_fb'+16)]
virtual sq1 servo_mode x16 maps: [(0,8)->('rc1 servo_mode'+ 0)] [(8,8)->('rc2 servo_mode'+ 0)]
virtual sa fb x16 maps: [(0,16)->('bc1 flux_fb'+ 0)]
virtual sa bias x16 maps: [(0,8)->('rc1 sa_bias'+ 0)] [(8,8)->('rc2 sa_bias'+ 0)]
