5.4 Setting up the readout format

This page is part of the ING document INS-DAS-31 Design notes for UltraDAS

Basic procedure

The readout format determines which pixels of the detector are read out by the camera at each readout and how they are treated in the DAS.

The associations for format setting are shown in Figure 5.4.1.

Figure 5.4.1: Associations during the setting of a readout format

When the programme starts up or is reset, the main module does the work of the Camera-facade in this scheme. When the format changes as a result of an action, the camera-facade controls the change.

Figure 5.4.2 shows the sequence of operations in detail, for the case of the WINDOW action. The calls are the same for other format-setting actions.

Figure 5.4.2: sequence of calls in setting a format.

The important and complex parts of the operation are making the readout section and the readout template and the mapping of the Pixel-stream. The challenging parts of the mapping are making the window table (if the format involves windows) and mapping the multiplexed stream of pixels to Regions of input.

Making the readout section

The readout section, as defined in INS-DAS-19, is the raster of pixels read from a readout channel of the camera when the camera is not windowed. The readout section is expressed in r-space and changes size in response to binning. It is represented by a Region.

In UltraDAS, the extent of the readout section must the same for all channels. This restriction comes from the camera hardware, which doesn't work well unless all all the channels do the same readout operations at exactly the same time, but the restriction is also exploited to get a big simplification in udas_camera. The readout sections of a multi-channel camera are technically not identical, as the r-space is different for each channel.

The Formatter holds the size of the unbinned readout-section and the current binning factors; it calculates a Region equivalent to the readout section from these numbers. If the size of the unbinned readout-section isn't an exact multiple of the binning factors, the Formatter discards any fractional pixels at the high-x and high-y edges.

Making the readout template

The readout template is a Mosaic with one input tile for every useful Region of pixels read out by the camera, and one output tile for every Region of pixels required in the output FITS-files. The Formatter creates the template, adds the tiles and makes the input-output mappings.

The formatter can make templates for three kinds of format:

full frame if no readout windows are enabled;
windowed if one or more of windows 1..4 are enabled and window 0 is not enabled;
"grab" if window 0 is enabled.

If the template is for a full-frame readout, it must contain one input tile for each readout channel. Each of these tiles is a copy of the readout section for the channel.

If the template is for a windowed or grab readout, it contains one input tile for each Region where an enabled window intersects a readout section. There could be four times as many of these tiles as there channels in the most-extreme case.

For a full-frame readout, there may be one output tile for each input, or the inputs may be mapped to a smaller set of inputs tiles and hence stitched together. This choice is part of the configuration and the Formatter gets it by interrogating the Config-D/B.

For a windowed readout, all the input tiles resulting from a given window are mapped to one output tile. There are exactly as many output tiles as there are enabled windows. If the inputs do not exactly cover the outputs, then the outputs will have some areas filled with zero pixels; the outputs are not truncated to match the available inputs.

For a grab readout, there is one enabled window by definition, and there is one output tile which the same d-space coordinates as this window.

The output tiles are expressed in i-space, so the rasters of the input tiles may have to be transformed to that space before copying the pixels. (The transformation and copying is part of the readout process, not of the formatting process.) In general, there is a different i-space for each channel. If an output tile combines input from more than one channel, it takes its channel number, and hence its i-space, from the lowest-channel-numbered input tile that is mapped to it.

Mapping: making the window table

The window table is introduced in INS-DAS-20 and specified in detail in INS-DAS-18, Annex A. It expresses exactly how the camera should read out in terms of parallel reads, parallel skips, serial reads and serial skips.

Each line of the table describes one block of readout, where a block is defined like this:

inside a block, each row of readout is done exactly the same way, starting with a parallel read and then followed by a pattern of serial skips and serial reads;
the operations in a block are applied identically to all channels of the camera;
each block is preceded by zero or more parallel skips, representing parts of the detector that aren't in any window;
a block may contain exactly zero parallel reads, in which case it generates no pixels at the outputs.

In fact, the table is required to have a last block in which there are no parallel reads. For a CCD, this ensures that all rows are moved down into the serial register and avoids leaving charge on the chip that could degrade the next readout.

Figure 5.4.3 illustrates the concept of blocks using a pattern of windows that overlap in r-space (windows may overlap in r-space provided that they don't overlap in d-space).

Figure 5.4.3: blocks derived from simple (left) and from overlapping (right) windows. Windows are shown hatched. Block boundaries are shown as dashed lines

Where the windows are disjoint in the y co-ordinate, they form one block each, plus one block to clear the unused rows of the readout section. Where windows overlap in y, whether or not they overlap in x, they form one block for each row of the readout section that intersects exactly the same set of windows, plus one extra to clear the unused rows.

The algorithm for making the table works in two stages, finding firstly the y-limits of the blocks and secondly the x characteristics.

This determines the y-limits:
    Start with zero in each location in the window table.
    Let R be a table recording which of the Regions in the readout template intersects the current row.
    Start at the first block of the window table.
    Start at the first row of the readout section.
    Repeat until all rows of the readout section have been considered:
        Calculate R.
        Repeat while R includes no Regions:
            Count one more parallel skip for the current block.
            Go on to the next row of the readout section.
            Calculate R.
        Repeat until R changes:
            Count one more parallel read for the current block.
            Go on to the next row of the readout section.
            Calculate R.
        Go on to the next block in the window table.

This determines the x characteristics:
    Start with zero in the x-characteristic parts of the window table.
    Repeat for each block in the window table:
        Start at the first serial-skip entry in the block./
        Consider the first row in the readout section that is part of the block.
        Start at the first pixel of the row.
        Repeat until all pixels in the row have been considered:
            Repeat while the current pixel is not in any window and the row's end has not been reached:
                Count one more serial skip in the current entry.
                Go on to the next pixel in the row.
            Go to the next entry in the block.
            Repeat while the current pixel is in any window and the row's end has not been reached:
                Count one more serial read in the current entry.
                Go on to the next pixel in the row.

Mapping: making the map

The map of the pixel-stream - i.e. of the torrent of pixels in the readout, rather than of the Pixel-stream object - is an array with one element for each pixel read out from the camera. The values in the array state indices of Regions to which the pixels should be copied. The map array is used in order, pixel by pixel, and the pixels are put into the target regions in raster order.

The Regions to which the pixels are mapped are generated like this:

Extract (extort?) references to each Region in the readout template.
Store the references in an array local to the Pixel-stream. Start at element one, not at element zero.
Sort the array of references into increasing order of channel number.

The indices of the array of references to Regions now define the set numbers that need to be put into the map of the pixel-stream. The value zero in the map indicates a pixel that is read out from the camera but is not mapped to any Region of the template; this is a "ghost" pixel and its use is explained below.

If the format is for full-frame readout, the mapping is easy. The readout consists of a number of "rounds" of pixels, and in each round the channels each produce a pixel in turn, in increasing order of channel number. Because the array of references to template-Regions has been sorted by channel number, the round sends one pixel to each region of the template in the order in which they are indexed. (Note that this need not be the order in which the input tiles appear from the template itself.) There is one round of pixels for each (x,y) location in the readout section.

If the format is for windowed readout, the camera sends the same round of pixels to the DAS as for the full-frame readout, and it sends one round at each point in the readout section where the window table indicates a serial read; this follows from the constraint that the output electronics do the same thing at the same time on all channels. However, unlike the full-frame readout, not all the pixels read out can be mapped to a Region of the template. Most pixels come from a region of d-space in which there is no window, and these are mapped as ghosts: they are read into the DAS at each readout but are then ignored and are discarded at the end of the readout. This means that although the round of pixels is always the same, the mapping of the round can vary discontinuously between any two pixels of the readout section.

Figure 5.4.4 illustrates a mapping for two windows on a four-quadrant detector. The two windows are input regions 1 and 2 respectively, and pixels for these Regions are marked with those numbers; ghost pixels are marked with zero. Pixels with no numbers are skipped, and these do not appear in the map.

Figure 5.4.4: mapping of pixels - example.

The true positions of the windows are shown by solid-bordered rectangles. Although the windows are separate in d-space, they overlap in r-space; the r-space positions are shown by dashed-bordered windows. The rounds of pixels are calculated by checking the channels in turn to see which regions are claiming pixels. For example, there is no readout at all up to r-space (1,4). At r-space (2,4), the round is [0, 0, 2, 1], presuming that the bottom-left quadrant is readout-channel 1 and the other channels follow round in anti-clockwise order (i.e. like INGRID). At r-space (8,4), the round is [0, 0, 2, 0] etc. Note that entries in each round are still in order of channel numbers, not in order of Region indices.

In practice, a windowed map is calculated from the window table using this algorithm.

Let the round be an array of integers indexed by channel number.
Repeat for each block of the table:
    Repeat for each detector row y read out by this block:
        Repeat for each pair of serial-skip/serial-read entries in the block:
            Repeat for each detector column x read out by this entry:
                Prepare a note of the round of pixels, setting all entries to zero.
                Repeat for each indexed Region:
                    If the Region includes the current (x,y):
                        Get the region's channel-number, c.
                        At the point in the round indexed by c, write the index of the Region.
                    Copy the numbers from the round into the next available set of elements of the map.

Clearly, the algorithm includes some very tight loops. The algorithm can run quite slowly for large windows, but all the code-optimizations that have yet been tried make the algorithm invalid for some window patterns. We seem to be stuck with it. In practice, the speed of the algorithm is unimportant except during GRAB actions.