Rectangle Mode Data

Yesterday Bryce and I were talking about paths towards a new rectangle readout mode. The following is a recommendation for the rough structure of the system that I think will be easy to manage and provide a maximum flexibility for backwards compatibility and future expansion.

The current rectangle mode is simpler than the planned one because the clock card and readout card need only agree on the number of data to readout, and no addditional waiting/synchronization is required between the clock card and readout card. The readout frame data sizes, internally and externally, are the same for everyone. The new mode is much more complex, because now the readout card has to accumulate several samples from each pixel into its internal buffer before sending the data to the clock card, and the clock card needs to ask for the right amount of data, which is probably some multiple of the rectangle size and is not necessarily a multiple of 8 or the number of multiplexing rows.

Anyway, the point is that here is a simple and flexible way to parametrize the new mode parameters and manage synchronization, and to provide flexibility and backwards compatibility.

1. The meaning of num_rows remains unchanged. It will always be a multiplexing parameter that all cards need to agree on.

2. The readout card has parameters (prepend "readout_" to all of these, if you want) "row_index", "num_rows", "col_index", "num_cols" that describe the rectangle of interest.

3. The clock card is programmed with a pair of numbers "readout_mult1" and "readout_mult2", that it uses to determine how many words of data to query the RCs for:

  N_data = readout_mult1 * readout_mult2.

These numbers are analagous to "num_rows_reported" and "num_cols_reported", but the idea is to kill the idea of "rows" and "columns" in the readout frames because the payload size is not a simple product of n_rows * n_cols. The clock card continues to support "data rate", which indicates the period at which data queries are sent to the RCs. Software will handle the details of getting these factors right. Eventually we will only use one of mult?; the other is for backwards compat.

4. In the RC: at each mux frame, data from the desired rectangle is copied into a large buffer. The RC continues filling the buffer until the CC asks for data. When RC receives a request for N data from the CC, it returns the first N data in the buffer, and resets its write index to the start of the buffer. If the CC doesn't ask for data, and the RC buffer write index increments all the way past the end, the RC takes _no storage action_ in subsequent steps (i.e. it writes all new data to "/dev/null").

Setting up rectangle mode then proceeds as follows. Suppose the RC buffer size is 1600 and I want to readout a 4 x 33 patch of the array:

1. Software computes that 4x33 = 132 words fits into 1600 about 12 times. So it sets "cc data_rate" to 12, and the product of "mult1" and "mult2" to 12 * 132 = 1584. It also sets the readout card row and col rectangle parameters.

2. Software triggers frame acquisition. For the _first_ frame read out, the clock card and readout card may not be synchronized; i.e. the readout card's buffer almost certainly contains ancient, stale data. So the first frame is discarded. But since the first frame query sent the the buffer write index to 0, the data from subsequent frames is fresh and ordered. Because the clock card is asking for N data at the same rate that the RC can N-fill the buffer, this results in a contiguous data stream.

This scheme is simple because: 1. CC has only enough information to ask the readout cards for the right amount of data at the right times. 2. RC only needs to know the rectangle of interest, and it basically lets the CC manage the resetting of the buffer. 3. It is backwards-compatible with existing firmware; mult1 and mult2 can masquerade as num_rows_reported and "8" (num_cols_reported).

The scheme minimizes the amount of information that must be shared between the RC and CC, which provides flexiblity. With "mult" approach, the CC can remain truly ignorant as to what the RC is doing. In this scheme I have emphasized the rectangle mode features, but I also envision it being useful in raw mode firmware, since a lot of the features (such as a large, flexible RAM block in the RC) would seem useful in that context. (For raw mode you would need to add a lock to the buffer so that it could be read out with multiple queries.)