Difference between revisions of "Virtual card"

From MCEWiki
Line 1: Line 1:
 +
== Description ==
 +
 
Unlike hardware (or "physical" cards), virtual cards are associated
 
Unlike hardware (or "physical" cards), virtual cards are associated
 
with a certain function (such as a squid amplifier stage).  A single
 
with a certain function (such as a squid amplifier stage).  A single
Line 18: Line 20:
 
Where possible, virtual card addresses should be used instead of
 
Where possible, virtual card addresses should be used instead of
 
hardware card addresses.
 
hardware card addresses.
 
== Reading and writing virtual cards ==
 
 
Only read and write commands are supported on virtual cards.  The RB,
 
WB, RRA, and WRA all have the natural behaviour when operating on
 
virtual cards.  For example, the following are equivalent:
 
 
rra bc3 bias 10 4
 
rra sq2 bias 10 4
 
 
Many virtual card parameters are shared across multiple hardware cards
 
(usually, these are per-column parameters shared across all the
 
readout cards).  In this case, the virtual card data is assembled from
 
each readout card, starting with rc1.  For example, compare
 
sq2  Second stage squid control (fb, bias)
 
sa    Series array control (fb, bias, offset)
 
tes  Detector and heater control (bias)
 
 
Virtual cards are useful for two reasons.  The first is to provide the
 
user with a more intuitive mnemonic set.  The second is to provide a
 
layer of abstraction between function and hardware; this allows higher
 
level programs and scripts to be written that are independent of the
 
hardware configuration.
 
 
Where possible, virtual card addresses should be used instead of
 
hardware card addresses.
 
 
== Reading and writing virtual cards ==
 
 
Only read and write commands are supported on virtual cards.  The RB,
 
WB, RRA, and WRA all have the natural behaviour when operating on
 
virtual cards.  For example, the following are equivalent:
 
 
rra bc3 bias 10 4
 
rra sq2 bias 10 4
 
  
 
Many virtual card parameters are shared across multiple hardware cards
 
Many virtual card parameters are shared across multiple hardware cards
Line 73: Line 40:
 
  Line  5 : ok : 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
 
  Line  5 : ok : 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
  
(In v2 systems, which can only hold 2 readout cards, such parameters
+
 
will only return 16 values.  In systems with empty readout card slots,
+
== Support for virtual card addresses ==
the data in virtual card parameters will be padded to account for the
+
 
missing cards.)
+
The virtual card abstraction layer is provided by mce_library.  The virtual cards are accessible to a scripting / interactive user through mce_cmd.
 +
 
 +
Each subrack configuration has an associated mce.cfg file (which lives in /etc/mce/) which describes the hardware cards present in the system and the mapping from virtual addresses to hardware addresses.  (This file should not require regular editing!)
 +
 
 +
== Sub-rack version and population variation ==
 +
 
 +
Many virtual addresses possess (on a full sub-rack) 32 values, one for each column of a
 +
squid array.  In v2 systems, which have at most 2 readout cards (and thus at most 16
 +
columns of squids), such parameters will only return 16 values.  However, in systems with
 +
empty readout card slots, virtual addresses will read out at full width (as if the rack was
 +
completely populated), but with any missing readout cards' columns padded with zeros.
 +
Writes to those missing columns will be ignored and not cause failures.
 +
 
 +
This means that, for example, the 8  values of "rc2 sa_bias" always corresponds to the second set of 8 values in "sa bias" regardless of whether the system possesses rc1. 
 +
 
 +
== Commanding virtual cards ==
 +
 
 +
Only read and write commands are supported on virtual cards.  The RB,
 +
WB, RRA, and WRA all have the natural behaviour when operating on
 +
virtual cards. For example, the following are equivalent:
 +
 
 +
rra bc3 bias 10 4
 +
rra sq2 bias 10 4
  
 
For TES bias lines, the mapping will depend on the experiment's
 
For TES bias lines, the mapping will depend on the experiment's
Line 84: Line 73:
 
== Detail of mappings ==
 
== Detail of mappings ==
  
To get a list of the mappings on your system, run mce_status with the
+
To get a list of the mappings on your system, run
-g option.  (This does not require an MCE to be connected, and it will
+
mce_status -g
not issue any MCE commands.)
+
(When invoked with the '-g' option, mce_status will not issue MCE commands and no MCE or SDSU PCI card need be present.)
  
The output from "mce_status -g" is interpreted as follows...
+
For a description of the output formatting, see [[ mce_status ]].

Revision as of 22:41, 5 March 2008

Description

Unlike hardware (or "physical" cards), virtual cards are associated with a certain function (such as a squid amplifier stage). A single virtual card, parameter address can span multiple physical cards.

Currently, the virtual cards implemented in mas are:

sq1   First stage squid control (fb_const, bias, servo_mode)
sq2   Second stage squid control (fb, bias)
sa    Series array control (fb, bias, offset)
tes   Detector and heater control (bias)

Virtual cards are useful for two reasons. The first is to provide the user with a more intuitive mnemonic set. The second is to provide a layer of abstraction between function and hardware; this allows higher level programs and scripts to be written that are independent of the hardware configuration.

Where possible, virtual card addresses should be used instead of hardware card addresses.

Many virtual card parameters are shared across multiple hardware cards (usually, these are per-column parameters shared across all the readout cards). In this case, the virtual card data is assembled from each readout card, starting with rc1. For example, compare

rb rc1 sa_bias
Line   1 : ok : 0 1 2 3 4 5 6 7
rb rc2 sa_bias
Line   2 : ok : 8 9 10 11 12 13 14 15
rb rc3 sa_bias
Line   3 : ok : 16 17 18 19 20 21 22 23
rb rc4 sa_bias
Line   4 : ok : 24 25 26 27 28 29 30 31

to

rb sa bias
Line   5 : ok : 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31


Support for virtual card addresses

The virtual card abstraction layer is provided by mce_library. The virtual cards are accessible to a scripting / interactive user through mce_cmd.

Each subrack configuration has an associated mce.cfg file (which lives in /etc/mce/) which describes the hardware cards present in the system and the mapping from virtual addresses to hardware addresses. (This file should not require regular editing!)

Sub-rack version and population variation

Many virtual addresses possess (on a full sub-rack) 32 values, one for each column of a squid array. In v2 systems, which have at most 2 readout cards (and thus at most 16 columns of squids), such parameters will only return 16 values. However, in systems with empty readout card slots, virtual addresses will read out at full width (as if the rack was completely populated), but with any missing readout cards' columns padded with zeros. Writes to those missing columns will be ignored and not cause failures.

This means that, for example, the 8 values of "rc2 sa_bias" always corresponds to the second set of 8 values in "sa bias" regardless of whether the system possesses rc1.

Commanding virtual cards

Only read and write commands are supported on virtual cards. The RB, WB, RRA, and WRA all have the natural behaviour when operating on virtual cards. For example, the following are equivalent:

rra bc3 bias 10 4
rra sq2 bias 10 4

For TES bias lines, the mapping will depend on the experiment's needs. By default, the parameter "tes bias" is a 3 word block that maps to "bc1 bias", "bc2 bias", and "bc3 bias".

Detail of mappings

To get a list of the mappings on your system, run

mce_status -g

(When invoked with the '-g' option, mce_status will not issue MCE commands and no MCE or SDSU PCI card need be present.)

For a description of the output formatting, see mce_status .