Hybrid row select for mux11d

From MCEWiki
Revision as of 10:18, 7 January 2015 by Mhasse (talk | contribs) (Created page with "'''This document is under active development.''' In standard mux11d, the S1 selection signals (row_select) are provided by the Adress Card (AC). "Hybrid row select" refers to t…")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This document is under active development.

In standard mux11d, the S1 selection signals (row_select) are provided by the Adress Card (AC). "Hybrid row select" refers to the use of Bias Card (BC) flux_fb DAC lines to augment the number of addressable S1.

  • Without any firmware modifications, it should be possible to multiplex any combination of AC and BC DACs, with num_rows up to 64. However, without some firmware modification, one can configure at most 58 of those channels for servo and readout.
  • With some communication protocol modification, it should be possible to configure and readout any subset of 64 rows.

Software modifications

The software components affected by hybrid row select are:

  • MAS low-level and mce_script -- internal code often assumes num_rows <= 41. These instances shouldn't be too hard to find and remove.
  • mux_lock -- rs_servo must be able to ramp the row_select DACs.
  • config script system -- must be able to map selected row_select values to correct MCE registers.

mce.cfg considerations

The AC and BC are set up differently for fast switching, and thus a low-level solution based on virtual card remappings is not feasible.

  • AC accepts lists of on_bias and off_bias values, and order of their application is set by the row_order register.
  • BC allows a completely arbitrary matrix of flux_fb values, which is more general than the AC model. There is no equivalent of row_order, since the matrix rows themseleves can be modified to produce the equivalent reordering of output values.

The biggest obstacle here is that supporting a "row_order" behaviour transparently would require a persistent dummy register for the BC row_order... and that's not a thing.

Alternately one could change the way "row select" and "row deselect" are mapped into the AC, so that the values written are always applied at the corresponding MUX cycle, rather than being associated with a particular bias line. This should be considered further.