INS-DAS-18 :
Interfacing the DAS computer to SDSU Detector-controllers
Issue 8.5, written on 8th April 2010
Richard Bassom, ING - rab@ing.iac.es
Introduction
Purpose of this document
This is the interface-control document governing the connection between
the DAS SPARCstation and SDSU detector-controllers when used in the UltraDAS.
Descriptions of UltraDAS programmes should note conformance to a particular
issue of this document. If a programme is found not to match the definitions
below, then the programme should be changed.
The current issue is provided for review and discussion; some important
points remain to be resolved. It is not ready to be used as a basis for
construction.
Document history
Issue 1.1, 1998-09-28:
Original document.
Issue 2.1, 1998-10-01:
The full-frame readout details and the windowing flag were added to the
X noticeboard of the timing DSP. It was noted that the window table
(called the "readout table" in issue 1) is not used for full-frame readouts.
Issue 3.1 1999-04-31:
The PFL command is now specified to be executed by the utility DSP instead
of the timing DSP. PFL is no longer allowed to return ERR.
The parameters in the input noticeboard for the timing DSP that set the
details of full-frame readout were withdrawn. These details are to be coded
in the DSP programme and may not be set by the DAS.
The LGN and HGN commands were added. These commands make obsolete the locations
in the input noticeboard for setting gain and readout speed; the locations
are withdrawn. The output noticeboard has been rearranged in respect
of these data.
Units of milliseconds for shutter and preflash timing, and millikelvin
for cryostat temperature, were confirmed.
The expression of video gain in the output noticeboard was changed to be
an integer showing actual gain times 1000.
The values for the shutter-state item in the noticeboard were simplified.
Issue 4.1, 1999-06-05
It was noted that RDC and TDL are exceptions to the transaction model.
The bad behaviour after a hardware reset was noted. The proper use of the
message-packet preamble is described. The sole, working way of resetting
the camera was recorded. The syntax of TDL and RDC was corrected. The discussion
of states and modes, and the specification of the CLK command were added.
The clock-state datum was added to the Y-noticeboard of the timing DSP.
Issue 5.1, 1999-06-08:
The use of the camera-ID code is defined. The CEX (change exposure) instruction
is introduced and replaces FEX.
Issue 5.2, 1999-06-16:
The CLK command was dropped and IDL and STP were reinstated to replace
it. The discussion of states and modes was adjusted to suit. CEX was found
to be unnecessary and was eliminated.
Issue 6.1, 1999-06-24:
The locations in P memory of NBAX and NBAY have been specified. A 10-second
timeout was noted for all transactions. The noticeboard for the utility
DSP has been rearranged. Gain has been dropped from the noticeboard of
the timing DSP. The description of the PFL command was corrected.
Issue 7.1, 2000-03-15:
The format of the window table was changed, roughly halving the amount
of memory needed to hold the table. The application of the window table
to multi-channel cameras was changed completely. Binning is now stated
to change the numbers in the window table. The X noticeboard of the timing
DSP was rearranged. The ABR command is now specified not to return any
status.
Issue 7.2, 2000-05-05:
HGN was renamed HSP; LGN was renamed LSP. The frames-read and gain-stage
items were deleted from the noticeboard, leaving all the other noticeboard
items at the same addresses (i.e. there is now a small gap in the noticeboard).
The maining of "size of window table" was clarified.
-
Issue 7.3, 2001-05-14:
-
Additions for IR UltraDAS. Addition of MRA n and GRB mnemonics. Addition
of utility board Y noticeboard variables for temperature monitoring point
2, temperature monitoring point 3, and cryostat pressure. Addition of timing
board X noticeboard variable for readout data mode.
-
Issue 8.1, 2002-01-10:
-
Additions for the PCI card interface. Addition of the Read Up the Ramp
interface (RDT command). Additional noticeboard values for flow sensor
rate.
-
Issue 8.2, 2002-04-09:
-
Additional noticeboard values for Peltier status.
-
Issue 8.4, 2003-01-15:
-
Modified for PCI card interface Version 1.7: Added IIA command, changed
RDA command, and added X noticeboard locations for use with RDA command.
-
Modified description of RDT (read at time) command to be in accordance
with SDSU Interface Control Document Version 5.0.
-
Issue 8.5, 2010-02-10:
- Added QUCAM commands.
- Added extra information on command sequences for IR and CCD run, bias, and dark runs. See Annex C and D.
- Added extra information on command sequences during camera startups. See Annex E.
Scope of the interface
The server programme for a camera is connected to one or more SDSU detector
controllers. The server can communicate directly and rapidly with the DSP
on the controller's timing-board, and less intimately with the DSP on the
controller's utility-board.
The interface between one controller and the DAS computer is described.
All such interfaces are identical. The interface defines:
-
the means of connection;
-
the communicating entities;
-
the protocol of communication;
-
the commands that may be sent to the controller;
-
the memory locations in the controller to which the DAS is allowed access.
The API used by programmes to work this interface is not described here.
References
-
[1]
-
Communicating regions of interest to SDSU detector controllers
ING document INS-DAS-20
by Guy Rixon
-
[2]
-
DSP software
Manual section by the CCD laboratory, San Diego State University
http://www.astro-cam.com
-
[3]
-
SDSU generation 2 user's manual
Manual section by the CCD laboratory, San Diego State University
http://www.astro-cam.com
Physical connection
The connection is a pair of fibre-optic leads running between the DAS computer
and the detector controller. A camera that has more than one detector controller
has a pair of leads for each one. The leads are 62.5/125 µm multi-mode
fibres, with AT&T ST-type (bayonet) connectors.
At the DAS computer, the leads plug into the back panel of an interface
board in the SBUS or PCI bus of the computer; each board connects only
one detector controller, but may be attached to different controllers at
different times. The sockets are exposed at the rear of the computer's
case. At the controller, the leads plug into sockets on the timing board.
Each fibre-optic lead carries data in one direction only and it is vital
that the connections not be crossed over. Leads and sockets should be marked
"to controller", "from controller", "to DAS" or "from DAS" and the labels
on mated connectors should match.
The downlink lead, from the DAS to the controller, is clocked
at 4MHz. The uplink lead, from the controller to the DAS, is clocked
at 50MHz.
The fibre optic interface is mounted on the timing board of the controller
and is managed by the timing DSP. There is no physical link between the
DAS computer and the utility DSP except through the timing board. Hence,
the handling of communications to the utility DSP depends on what the timing
DSP is doing.
Logical connection
The SDSU system has four processors: the timing DSP of the controller;
the utility DSP of the controller; the DSP in the interface board of the
DAS computer; the DAS computer's CPU. Each processor can address all the
others directly. This hides the fact that all messages to the controller
from the DAS go through the interface board, and all messages from the
DAS to the utility DSP go through the timing DSP.
In the UltraDAS, not all possible connections are used. These are the
paths that are relevant to this interface.
-
The DAS sends commands to the timing DSP.
-
The DAS sends commands to the utility DSP.
-
The timing DSP sends stati to the DAS.
-
The utility DSP sends stati to the DAS.
-
The timing DSP sends pixel data to the interface DSP.
Protocol
The communication on the paths listed above takes two forms: command-and-status
exchanges (transactions) and pixel packets.
Transactions
Transactions are started by the DAS and never by the controller. Transactions
are atomic: the DAS may not overlap transactions on a given interface.
This applies even to pairs of transactions on different DSPs of the same
controller.
Each complete transaction consists in exactly one command sent to the
DSP and one status message sent back. The messages are strings of DSP words
with the syntax described below. Failure to get a
status for a command within one seconds plus the expected length of the
commanded operation implies a fault in the software or in the communications
hardware; it is improper for the DSP to reject a command by ignoring it.
The command to start a readout (RDC) does not return status: it is a
messy exception to the transaction model. The command is retained in this
inferior form for compatibility with SDSU's application ccdtool.
The command to abort a readout (ABR) does not return status either.
The command to test the fibre-optic link to the camera (TDL) also departs
from the transaction model. This command returns status but with a different
syntax. The reason is the same as for RDC.
Transactions are processed independently. The history of commands, and
the resulting states of the controller, do not affect the protocol. However,
the success or failure of a command does depend on the state of the controller.
If the controller does not understand a command (e.g. because the appropriate
DSP programme has not been loaded), or cannot obey the command (e.g. because
it is busy reading out), then the controller sends a status message indicating
failure.
Some commands read from or write to DSP memory by specific address.
When writing to memory, one command is executed for each word loaded. The
address and value are words of the command. Similarly, when reading from
memory, one command is executed per word read. The address is sent as a
word of the command and the value is returned as a word of the status.
If the detector controller is reset other than by the DAS (e.g. by pressing
the reset switch on the power supply), then the response to the next command
from the DAS is undefined; the system has become unusable. Control can
be recovered by resetting and reprogramming the camera but there is no
reliable way for the DAS to detect this situation: hence, the system fails.
The system is required to be broken in this way for compatibility with
SDSU's software.
Most transactions complete within a few milliseconds. The transactions
for the ABR, CLR, PFL and DEX commands may take longer, depending on circumstances.
If any transaction has been active for 15 seconds without returning data
(this includes the demi-transactions for TDL and RDC), then the transaction
is considered to be timed out.
Pixel packets
A pixel packet describes one pixel as a 16-bit, unsigned integer value.
Pixels are sent by the timing DSP to the interface DSP. The result of
sending pixels to the DAS CPU itself is undefined and is likely to disrupt
the system.
Pixels are sent as a result of a readout command and not otherwise.
If the timing DSP needs to read out pixels at any other time, it may not
send them to the interface DSP.
Before the readout is invoked, both the timing DSP and the interface
DSP must be aware of the number of pixels expected. The readout is completed
when the expected number of pixels has arrived at the interface DSP, or,
failing that, after a timeout period. There is no handshake to synchronize
the DSPs at the end of readout. If no pixels are received at the DAS in
a period of 15s during a readout, then the readout is timed out and the
DAS will abort it.
Pixels are sent as a result of a readout command but are not a part
of that command's transaction: they follow the sending of the status for
the readout command. Hence, other transactions may be started during a
readout. However, the only commands to which the timing DSP is required
to accept are the reset and abort-readout commands. The DSP may not ignore
any command, but it may reject other commands out of hand.
Data framing
On the fibres, command and status messages are sent as sequences of 32-bit
words each preceded by a start bit. Of these bits, the eight most significant
are a "preamble" used by the communications hardware and the remaining
24 are data for applications.
Pixel packets are 16 bits long with one start bit. They have no
preamble.
The packets are assembled and disassembled by SDSU's hardware and the
exact bit-pattern is not clear from the documentation. Reference
3 is the published source.
Message packets sent to the DSPs in the camera
are received as 24-bit words (the DSP's natural word-length). The preamble
byte is stripped off by the communications hardware on the timing board
of the camera. Packets sent from the camera to the DAS are sent as 24-bit
words and the communications hardware adds the preamble.
Message packets sent to the camera by the DAS are sent as 32-bit words:
the preamble byte is visible to the software and is passed across the bus
of the DAS computer. However, the communication hardware on the DAS' bus-interface
board overwrites whatever was in the preamble byte. When packets are received
by the DAS, the preamble byte is visible at the front of each 32-bit word.
The DAS has to mask out the preamble to recover the true value of the word.
Message packets normally have ACh in the preamble. If the camera receives
a preamble byte of 53h, then the communications hardware in the timing
board causes a reset of the camera. See the description of the RST
command below for the semantic of this reset. See the documentation of
the API for the bus-interface board for the means by which the 53h preamble
may be sent.
Syntax
This section describes the data that are visible to the processors after
the framing bits and the preamble are stripped off.
A word, in the current context, is a DSP word of 24 bits. Words
carrying numbers are to be treated as hexadecimal integers unless otherwise
noted. The most-significant byte of the word comes first in memory.
The same syntax is used for commands and stati. The syntax is taken
from SDSU's manual [2].
The first word of the command is a header containing:
-
byte 1:
-
source of message
-
byte 2:
-
destination of message
-
byte 3:
-
number of words in the message, including the header.
The message can have from two to seven words, because the header word is
included in the count. The source and destination are encoded as follows:
-
0:
-
DAS computer
-
1:
-
interface DSP in DAS computer
-
2:
-
timing DSP in controller
-
3:
-
utility DSP in controller
Code "1" is not used in this interface: the messages discussed here pass
between the DAS and the controller DSPs directly. Messages to the interface
DSP are dealt with in another document.
The second word of a message contains three ASCII characters forming
a label for the command or status. Case is significant; by tradition, all
message labels are in upper case, but mixed case could be used. The labels
for stati are "DON" for success, "ERR" for failure and "SYR" after a DSP
reboots. Labels for commands are listed below,
along with the semantics of the commands.
Any subsequent words are arguments and their meaning varies from message
to message.
When a word of a command is an address, the high bits determine which
of the DSP's three banks of memory is addressed.
-
Bit 20
-
implies P: memory when set
-
Bit 21
-
implies X: memory when set
-
Bit 22
-
implies Y: memory when set
-
Bit 23
-
is never set.
Only one of these bits may be set.
The command TDL ("test data link") does not return a standard status.
If it succeeds, it returns a header word and then the number that was sent
in the first argument of the command; no status label is sent.
Semantics
Commands provided in all DSP programmes
These commands are available at all times. They are the only commands guaranteed
to be available when an application programme is not running on the DSP.
-
RST
-
reset the DSP. The command and status each have two words. After a successful
reset, the status label is "SYR". This command only works when sent with
the 53h preamble described above. In
fact, the preamble causes the reset and the rest of the command is ignored.
The standard command-syntax is used for consistency.
-
TDL
-
test the data link to the DSP. The command has three words and the status
has two. The third word of the command is an arbitrary number which
is written back in the second word of the status; the DAS compares the
sent and received values to check that the link is not corrupting bits.
This command does not return a status label.
-
WRM
-
write a word of DSP memory. The command has four words and the status two.
The third word of the command is the address to be set. The fourth word
of the command is the value to be written.
-
RDM
-
read a word of DSP memory. The command has three words and the status has
two. The third word of the command is the address to be read. The second
word of the status is the value. This command does not return a status
label.
-
LDA
-
run a an alternate DSP-programme from the DSP's boot PROM. The command
has three words and the status has two. The third word of the command is
an integer that tells the DSP which of a set of numbered programmes to
run; the programmes are numbered 0..10 for the utility DSP and 1..10 for
the timing DSP. LDA is not needed in normal operation. After the DSP is
reset, the DSP automatically loads the correct boot programme and the DAS
then overlays this with an application loaded with the WRM command.
-
Memory locations valid at boot time
After the camera is reset or powered on - i.e. when the DSPs are running
only their boot programmes - the DAS may not expect memory locations to
have predictable or useful values. All the locations that the DAS expects
to read in normal operation get their values only after a programme is
started (by LDA or by download using WRM) on the DSP that owns the memory.
In particular, I/O ports of the utility DSP that are mapped into memory
only become active when a programme is running on that DSP.
There is one exception to this, and it is vital to UltraDAS. The camera's
ID code is read from a dongle on the cryostat, and the dongle is cabled
to an 8-bit parallel-I/O port on the utility board. The I/O port is mapped
at location Y:$0000 in the utility DSP's RAM, and the 8-bit ID code appears
in the least-significant byte of that word. The DAS determines the ID code
by reading Y:$0000 with the RDM command and masking out the two most-significant
bytes.
When the utility DSP is booted, the cryostat-ID code is read into Y:$0000
once. That is, it samples the ID setting at one instant part-way through
the boot sequence.
Commands provided by the timing DSP
These commands exist only in application programmes.
-
CLR
-
clear the detector. Command and status both have two words. The DSP clears
the detector and then sends the status.
-
RDC
-
read out the detector. The command has two words. The DSP reads out the
camera immediately. No status message is sent either before or after the
readout; instead, the DAS has to count the pixels (or wait for a timeout
from the device-driver of the bus-interface board) to detect the end of
the readout. The act of reading out switches the communications link from
the
camera
to the DAS from message-packet (32-bit) mode to pixel-packet
(16-bit) mode; the link in the other direction remains in message-packet
mode. In consequence, the camera can accept commands during a readout but
cannot reply to them unless it aborts the readout. Hence, the only command
that is valid during a readout is ABR.
-
ABR
-
abort a readout. The command has two words; no status is sent for this
command. The DSP abandons the readout as soon as is practical, probably
at the end of the next row of the detector.
-
LSP
-
set low video-gain and readout-speed. The DSP selects the lower of two
hard-coded readout-speeds and selects a gain-stage to match. These settings
apply to all subsequent readouts until LSP or HSP are next executed.
-
HSP
-
set high video-gain and readout-speed. The DSP selects the higher of two
hard-coded readout-speeds and selects a gain-stage to match. These settings
apply to all subsequent readouts until LSP or HSP are next executed.
-
IDL
-
turns on idle mode: see below .
-
STP
-
turns off idle mode: see below .
These commands are only applicable to the IR detectors:
-
MRA n
-
Execute multiple non destructive read consisting of an array reset, n reads,
integration, n reads. Controller transmits 16 bit image data. This is a
3 word command.
-
GRB
-
Execute multiple non destructive read consisting of an array reset, 1 read,
integration, 1 read. Controller transmits 16 bit image data.
-
RDT n
-
Readout at time. Execute n readouts at time t=0. Thereafter, execute n
readouts when the integration timer is equal to or exceeds the demand integration
time. The demand integration time is in units of milliseconds. See Annex
B for details.
These commands are only applicable to the QUCAM detectors:
-
MRC n
- Execute multiple frame reads consisting of a
detector clear, followed by n reads each with an integration time set
in the demand integration time utility board noticeboard. Controller
transmits 16 bit image data. This is a
3 word command.
States and modes of detector clocks
The detector clocks have four states:
Inactive:
no clock waveforms are generated. Static voltages on the clocks do not
retain charge in the pixels.
Clearing:
the clocks purge the detectors of charge.
Integrating:
the clocks are set to a static level that allows charge to accumulate in
the pixels during an integration.
Reading out:
the clocks move charge around on the detectors.
Clearly, the clocks are in the clearing state during CLR and in the
reading state during RDC.
If "idle" mode is turned on, the clocks go to the clearing state when
no command is in progress on the timing DSP. If idle mode is turned off,
the clocks go to the integrating state between commands. Idle mode is turned
on by the IDL command and turned off by the STP command.
After a reset, the clocks go to the inactive state. All the programmes
for the timing DSP start by turning on idle mode, putting the clocks into
the clearing state. There is then no way to get the clocks back to the
inactive state except by resetting the DSP and losing the programme.
Memory locations in the timing DSP's RAM
The DAS may access the DSP's memory at any time except during a transaction
or a readout.
These locations can be set by the DAS to control the timing DSP. They
may also be read back by the DAS.
-
Windowing flag
-
determines whether windows should be applied. The value 1 in this
word means "apply windows"; 0 means "do the full-frame readout instead".
-
Window table
-
defines the sequence of skips and reads that make up a readout in the current
format. This is set by the DAS each time an aspect of the format changes.
The table is complex; details are in an annex.
-
Binning factors
-
one word to set the x binning, and one for the y. The range
is 1..10 for each factor.
These locations may be read as telemetry but may not be written.
-
Number of rows in window table
-
The this is the number n, as discussed in Annex
A. It happens to be equal to the number of window fragments that the
table can describe.
-
Readout speed
-
One word holding 1 for the slower speed and 2 for the higher. This is set
at initialization and by the HSP and LSP commands.
-
Pixel rate
-
The greatest rate, in pixels per second as one word, at which pixel values
are output for the current readout speed. That is, adjacent pixels in a
row are dispatched from the controller at this rate. This is set at initialization
and by the HSP and LSP commands.
-
Clock state
-
the current state of the detector clocks expressed as a code: 0 = inactive,
1 = clearing, 2 = integrating, 3 = reading out.
-
errno
-
One word holding an integer code that describes the result of the last
command. The code is zero if the status label was "DON" and greater than
zero if the label was "ERR" (i.e. this location behaves like the errno
variable in Unix system-calls). The actual condition-codes are TDB but
must form part of this ICD when they are known.
-
UltraDAS' flag
-
the DAS writes a non-zero value into this location to show that it is charge
of the interface. This causes the camera to select different implementations
of some commands to those it would use when CCDtool is in charge. If UltraDAS
suspends its use of the interface to allow other software to see the camera,
then the DAS must clear this word to zero before the other software engages.
The DAS must then reset the word to a non-zero value when it resume command
of the interface. This flag should be set to 1 for the SBUS interface,
and 2 for the PCI interface.
-
Readout mode
-
Determines the type of data that is transmitted during readouts. When set
to 0, the SDSU transmits real data. When set to 1 or 2, the SDSU transmits
test data.
-
Number of columns in readout (PCI interface only)
-
This is the number of columns to be sent in a readout. UltraDAS must set
this value when changing the number of pixels that are expected to be received
during readouts.
-
Number of rows in readout (PCI interface only)
-
This is the number of rows to be sent in a readout. UltraDAS must set this
value when changing the number of pixels that are expected to be received
during readouts. This is used in conjunction with the number of columns,
as the parameters of the RDA command sent by the controller to the PCI
card at the start of readouts. Typically one of these locations is set
to 1, and the other is set to the total number of pixels expected during
a readout. This allows for complex windowed readouts where the number of
pixels cannot be represented in terms of number of rows and number of columns.
See the RDA command for further information.
The locations listed above form a noticeboard arranged in memory as follows:
-
P:$01FE
-
the address of the start of the noticeboard in X memory, denoted as "NBAX"
below.
-
P:$01FF
-
the address of the start of the noticeboard in Y memory, denoted as "NBAY"
below.
-
X:NBAX
-
window table
-
X:NBAX + FFh - 6
-
Number of rows in readout
-
X:NBAX + FFh - 5
-
Number of colums in readout
-
X:NBAX + FFh - 4
-
Readout mode
-
X:NBAX + FFh - 3
-
UltraDAS' flag
-
X:NBAX + FFh - 2
-
binning factor in x
-
X:NBAX + FFh - 1,
-
binning factor in y
-
X:NBAX + FFh
-
windowing flag
-
Y:NBAY
-
errno
-
Y:NBAY+1
-
number of rows in window table
-
Y:NBAY+4
-
readout speed
-
Y:NBAY+5
-
pixel rate
-
Y:NBAY+6
-
clock state
Notably, the variables in the X noticeboard are specified at both ends
of a 256-location patch of memory. This allows the window table to grow
up and the list of scalar variables to be extended downward without moving
any of the existing data.
Commands provided by the utility DSP
These commands exist only in application programmes.
-
PON
-
power up analogue circuits. Command and status each have two words.
-
POF
-
power off analogue circuits. Command and status each have two words.
-
BEX
-
begin exposure. Command and status each have two words. The controller
zeroes the exposure counter, opens the shutter, and records a timestamp
for it opening. The controller starts the exposure counter running. At
the end of the demanded exposure, the controller closes the shutter and
records the length of the exposure. The transaction completes when the
exposure has started (or failed to start). The timing and ending of the
exposure is a background process that happens outside any transaction.
-
PEX
-
pause exposure. Command and status each have two words. Close the shutter
and halt the exposure timer but do not zero the timer.
-
REX
-
resume paused exposure. Commands and status each have two words. Open the
shutter and restart the exposure timer. Do not zero the timer before restarting
it.
-
DEX
-
detect end of exposure. Command and status each have two words. Wait until
the exposure is finished (shutter closed and exposure time recorded) then
return status. If there is no exposure in progress, return good status
immediately. The DAS is not required to issue a DEX for every BEX,
but it will normally do so.
-
OSH
-
open shutter. Command and status each have two words.
-
CSH
-
close shutter. Command and status each have two words.
-
PFL
-
light preflash lamps. The command and status each have two words. The DSP
lights the lamps for the indicated duration and then sends the status.
Since the controller has no way of telling whether the lamps are taking
any current (or even if any lamps are present), the status "DON" is always
sent.
-
GEN
- Return the generation code of the controller. Generation 3
controller should respond with the code 3. Generation 2 controllers do
not support this command, and so will return the error message ERR.
- It is expected that any future generation 4 controller will return 4 in response to this command.
- See Annex E for more information on how this command is used at camera startup.
Memory locations in the utility DSP's RAM
These locations can be set by the DAS to control the utility DSP.
-
Demanded exposure
-
defines how long the shutter should be opened for in the operation started
by BEX. In the case of MRA or GRB, this is the demanded integration time
between MNDR reads. This is one word, an unsigned integer stating the exposed
time in units of milliseconds. If the value is changed during an exposure,
then the DSP detects this within 10ms and reacts accordingly. If the demanded
exposure is greater than the time already exposed, then the actual exposure
goes on to the new length and finishes normally. If the demanded exposure
is less than the time already exposed, the exposure finishes immediately.
-
Demanded temperature
-
defines the temperature that the cryostat should be kept at. One word,
an unsigned integer stating the temperature in units of millikelvin.
-
Demanded preflash
-
the demanded duration of preflash in milliseconds.
These locations may be read as telemetry but may not be written.
-
Current exposure
-
the time that the shutter has been open for in the operation started by
BEX. This is one word, an unsigned integer stating the exposed time in
units of milliseconds [units TBC]. The DSP updates this location at least
every five seconds during the exposure and again at the time that it closes
the shutter. In the case of a camera which supports MNDR readout mode,
this value is the time in milliseconds between the start of the first non-destructive
read sequence after an MRA or GRB, and the start of the last non-destructive
read sequence.
-
Current temperature
-
the temperature in the cryostat. One word, an unsigned integer stating
the temperature in units of millikelvin. The DSP updates this at least
once per minute.
-
Current preflash
-
the time for which the preflash lamps have been lit in the current preflash,
or the time for which the lamps were lit in the most-recent preflash if
no preflash is currently in progress. The time is in milliseconds.
-
Shutter state
-
an integer showing what the shutter is doing: 0 = open, 1 = closed, 2 =
fault. "Fault" covers, jammed, disconnected, switched off, wandering away
from the command position and any other bad conditions that the shutter
drive can detect. The DSP updates this location at each shutter event it
commands and also at each shutter event it senses. (That is, it reports
unexpected movements and failure to move when required as well as normal
operations.)
-
errno
-
One word holding an integer code that describes the result of the last
command. The code is zero if the status label was "DON" and greater than
zero if the label was "ERR" (i.e. this location behaves like the errno
variable in Unix system-calls). The actual condition-codes are TDB but
must form part of this ICD when they are known.
-
Monitoring point 1 temperature
-
the temperature at temperature monitoring point 1. One word, an unsigned
integer stating the temperature in units of millikelvin. The DSP updates
this at least once per minute.
-
Monitoring point 2 temperature
-
the temperature at temperature monitoring point 2. One word, an unsigned
integer stating the temperature in units of millikelvin. The DSP updates
this at least once per minute.
-
Cryostat pressure
-
the current cryostat pressure. One word, an unsigned integer stating the
pressure in ADU. Conversion from ADU to mBar is performed by the camera
server. The DSP updates this at least once per minute.
-
ID-code
-
The camera-ID code discussed under "Memory locations
readable at boot time ", above. Running the application on the
DSP does not change the ID bits that were set at boot time (although the
other, non-ID bits may well change). The ID-code is at Y:$0000, in the
least-significant eight bits of the DSP word.
The locations listed above form a noticeboard arranged in memory
as follows:
-
P:$01FE
-
the address of the start of the noticeboard in X memory, denoted as "NBAX"
below.
-
P:$01FF
-
the address of the start of the noticeboard in Y memory, denoted as "NBAY"
below.
-
X:NBAX
-
demanded exposure
-
X:NBAX+1
-
demanded temperature
-
X:NBAX+2
-
demanded preflash
-
Y:$0000
-
the ID-code.
-
Y:NBAY
-
current exposure
-
YNBAY+1
-
current cryostat temperature - temperature monitoring point 1
-
Y:NBAY+2
-
current preflash
-
Y:NBAY+3
-
shutter state
-
Y:NBAY+4
-
errno
-
Y:NBAY+5
-
Temperature monitoring point 2
-
Y:NBAY+6
-
Temperature monitoring point 3
-
Y:NBAY+7
-
Cryostat pressure (ADU)
-
Y:NBAY+8
-
Flow sensor flow rate (ADU)
-
Y:NBAY+9
-
Peltier status (0=off, 1=on)
-
Commands provided by the PCI DSP (PCI card interface only)
The following commands are provided by the PCI card DSP, for use by the
controller over the fibre link:
IIA
Instruct the PCI card DSP to initialise its image address prior to any
readout. This command must be sent by the timing board DSP to the PCI card
DSP before sending the RDA command, and before the transmission of any
pixel data. In the case of cameras which support non destructive readouts,
this command should be sent once at the start of a block of each block
of n reads. For example when processing an 'MRA 2' command, the timing
board DSP should send the IIA and RDA command, perform 2 array readouts,
integrate, send the IIA and RDA command, and then perform the 2 post integration
readouts.
RDA x y
Instruct the PCI card DSP to prepare to receive x*y pixels of 16 bit pixel
data. This command must be sent by the timing board DSP to the PCI
card DSP immediately prior to the transmission of a 16 bit pixel data stream.
The x and y values determine the number of pixels that are to be sent by
the controller, where x is the number of columns and y is the number of
rows. In the case of cameras which support non destructive readouts, this
command should be sent once at the start of a block of each block of n
reads. For example when processing an 'MRA 2' command, the timing board
DSP should send the IIA and RDA x y command, perform 2 array readouts,
integrate, send the IIA and RDA x y command, and then perform the 2 post
integration readouts.
Discussion
The commands are chosen to provide a fine-grained set of parts for building
sequences, with the server programme doing the sequencing. Each of the
commands can be fully executed in one DSP; there are no cases where a DSP
has to act on to a command but must also send on a sub-command to another
processor. For example, the RDC command presumes that the DAS has already
set up the interface DSP to receive data; it doesn't require the timing
DSP to set up the interface.
Most of the commands are copied directly from the example programmes
supplied by SDSU. This is a deliberate choice to preserve compatibility
with SDSU's applications ccdtool and voodoo which UltraDAS uses as a laboratory
and engineering interface. These commands are specific to UltraDAS
and are not in the SDSU software: BEX, FEX, DEX, MRA, RDT and GRB.
Each of the application commands requires a DSP to do or stop doing
something. Transactions that just plant information for later use (e.g.
setting the demanded exposure-time) are done by writing to memory using
WRM. Similarly, telemetry gathering is done by reading from memory using
RDM. This presumes that single-word data can be written or read atomically
while the DSP concerned is working with them. For example, retiming a running
exposure requires that the demanded-time location be changed between the
BEX and DEX transactions while the utility DSP is counting the exposure.
"Direct" access of DSP memory is necessary because one of the datasets
to be moved, the readout table, is far too large to fit in one command.
Once one allows the direct access in one place, it makes sense to exploit
it to simplify the command set and the application code.
The arrangement of the noticeboards in the three banks of memory is
deliberate. Each noticeboard is split into input and output side in opposite
banks of data memory to make it easier to tell if an output location is
being accidentally written by the DAS or if an input is being read. The
addresses of the noticeboard halves are in P: memory as they are part of
the DSP programme. The input side of the noticeboard needs to be kept separate
from the safety-critical code of the DSP programme, particularly the parts
that set voltages on the detector. It is intended that the critical code-sequences
be kept in the P: memory and the rest of the code kept to P: or Y: memory.
The DAS only needs to write to X: memory, so the chance of it corrupting
the DSP programme through an address error is very small.
The DEX command is provided to avoid having a transaction on the utility
DSP that lasts for the entire exposure time. Such a transaction would prevent
polling for telemetry under the rule, above, that prohibits overlapping
transactions. The normal sequence for the DAS would be
-
Set demanded-exposure-time location.
-
BEX
-
Wait until just before the end of the exposure; poll telemetry as normal.
-
DEX
-
Read exposed-time location.
Because the timing DSP reads the demanded exposure-time continually during
the exposure (it polls the noticeboard location one every millisecond),
there is no need for commands to retime or to finish the exposure.
The FEX and CEX commands listed in previous issues of this document have
been discarded.
The units of data in the noticeboard are specified to be true integers
instead of the DSP's native, fractional format: this is to aid comprehension
by the non-DSP programmers who have to work with the interface. No floating-point
numbers are used in the interface; scaled integers are used where necessary.
The full-frame format of a channel is coded in the DSP programme and
and can't be changed by the DAS. This simplifies the interface and allows
optimization of the code for the full-frame readout. The format can't be
read from the noticeboards either: this is a deliberate simplification.
Instead, the DAS keeps the format in a configuration file.
Annex A: The window table
A window table defines exactly the windowed readout for one channel of
a camera in terms of the following atomic operations:
-
skip one row ("parallel skip");
-
clock one row into the output register ("parallel read");
-
skip one column in a row ("serial skip");
-
read one pixel in a row ("serial read").
The window table does not apply to unwindowed readouts. (This is
a significant change from version 1of this interface.)
Where a camera has more than one output, it must always read one pixel
from each output in strict sequence. For example, a detector with four
quadrants reads the first pixel from quadrant 1, the first from quadrant
2, the first from quadrant three, the first from quadrant four, and then
the second from quadrant one, etc. This means that wherever the user wants
to read a pixel on only one channel, then the camera must produce (and
the DAS must receive) "ghost" pixels on all the other channels to preserve
the ordering.
The window table describes the sequence of operations to read one channel.
A multi-channel camera applies the same clocking operations to all its
channels.
The rationale of the table is discussed in reference
1. This is the table format.
Let n be the greatest number of window-fragments that may be
present in the readout. The window table consists in n rows, one
row per window-fragment. Each line contains 2n+2 numbers, where
each number is represented in the camera as one word of DSP memory.
The words in one line of the table have the following meaning;
-
Word 1
-
PSKIP: a count of parallel skips.
-
Word 2
-
PREAD: a count of parallel reads.
-
Words 3, 5,.., 2n+1
-
SSKIP: counts of serial skips.
-
Words 4, 6, 8, ..., 2n+2
-
SREAD: counts of serial reads.
The camera shall use the numbers as direct instructions thus:
For each row of the table:
Execute PSKIP parallel skips.
Repeat PREAD times:
Execute one parallel read.
Repeat n times:
Execute SSKIP serial skips.
Execute SREAD serial reads.
Each of the words in the table is an unsigned integer. Any of the counts
may be zero. Depending on the number of windows set and their relative
positions in y, some of the rows at the end of the table may contain
no reads (i.e. zero in word 2).
When the system is windowing and binning at the same time, PREAD and
SREAD are in units of binned pixels but PSKIP and SSKIP are in units of
unbinned pixels. That is, the read operations move the charge pattern by
a number of physical pixels equal to the binning factor, while the skip
operations move the charge pattern by exactly one physical pixel.
The total length of the table is 2n2
+ 2 words.
Annex B: The Readout at Time command (RDT n)
This command provides access to read up the ramp mode for cameras which
support non-destructive readouts. It is also intended that this command
provide access to accurately timed rapid spectroscopy readouts.
The command instructs the controller to perform n readouts when
the elapsed integration timer has reached the demand integration time.
If the demand integration time is less than the current elapsed integration
timer, then the readout is performed immediately.
The demand integration time is in units of milliseconds.
The elapsed integration time is reset on receipt of the RDT n command.
The table below shows the sequence for a read up the ramp observation
of n reads at times 0, t1, t2 .... tn:
| HOST |
CONTROLLER |
| Send CLR. |
Clear detector. |
| Send RDT n. |
Reset integration timer. Store <actual_integration_time>
at start of readout. Readout detector. |
| Wait for controller to complete sending pixels. |
|
| Get actual integration time at start of last readout (RDM <actual_integration_time>). |
Reply <actual_integration_time>. |
| Wait until host timer reaches t1 - 1s. |
|
| Set demand integration time to t1. |
Wait until integration timer >= t1. Store <actual_integration_time>
time at start of readout. Readout detector. |
| Wait for controller to complete sending pixels. |
|
| Get actual integration time at start of last readout (RDM <actual_integration_time>). |
Reply <actual_integration_time>. |
| Wait until host timer reaches t2 - 1s. |
|
| Set demand integration time to t2. |
Wait until integration timer >= t2. Store <actual_integration_time>
time at start of readout. Readout detector. |
| Wait for controller to complete sending pixels. |
|
| Get actual integration time at start of last readout (RDM <actual_integration_time>). |
|
| : |
: |
| : |
: |
| Wait until host timer reaches tn - 1s. |
|
| Set demand integration time to tn. |
Wait until integration timer >= tn. Store <actual_integration_time>
time at start of readout. Readout detector. |
| Wait for controller to complete sending pixels. |
|
| Get actual integration time at start of last readout (RDM <actual_integration_time>). |
Reply <actual_integration_time>. |
| Send ABR |
End NDR readout mode. |
Annex C: CCD Run Sequences
The following tables show the command sequences between UltraDAS (the host), and the SDSU controller for all typical run types.
Run
The command sequence for a typical CCD run using the run command:
run 100
| HOST |
CONTROLLER |
| Send STP. |
Stop the clocks. Reply DON. |
| Send CLR. |
Clear the detector. Reply DON. |
Send WRM 0x2000F8 0x186A0 to utility board- set demand integration time to 100000ms
| Sets the demand integration time in the utility noticeboard to the required number of milliseconds. Reply DON. |
| Send STP. | Stop the clocks. Reply DON. |
Send BEX.
|
Begin the exposure. Open the shutter. Start the exposure timer. Reply DON. |
Wait until host timer reaches (100 - 2) seconds
|
|
Send DEX.
|
Wait until the exposure timer equals 100. Shut the shutter. Reply DON.
|
Send RDM 0x4000F8 to utility board - get the actual integration time
|
Return the actual integration time in the utility noticeboard in milliseconds.
|
Send RDC.
|
Read out the detector.
|
| Wait for controller to complete sending pixels. |
|
Send IDL.
|
Set the detector clocks idling. Reply DON.
|
|
|
Bias
The command sequence for a typical CCD bias using the bias command:
bias
| HOST |
CONTROLLER |
| Send STP. |
Stop the clocks. Reply DON. |
| Send CLR. |
Clear the detector. Reply DON. |
| Send STP. | Stop the clocks. Reply DON. |
Send RDC.
|
Read out the detector.
|
| Wait for controller to complete sending pixels. |
|
Send IDL.
|
Set the detector clocks idling. Reply DON.
|
|
|
Dark
The command sequence for a typical CCD dark exposure using the dark command:
dark 100
| HOST |
CONTROLLER |
| Send STP. |
Stop the clocks. Reply DON. |
| Send CLR. |
Clear the detector. Reply DON. |
| Send STP. | Stop the clocks. Reply DON. |
| Wait until host timer reaches 100 seconds |
|
Send RDC.
|
Read out the detector.
|
| Wait for controller to complete sending pixels. |
|
Send IDL.
|
Set the detector clocks idling. Reply DON.
|
|
|
Flash
The command sequence for a typical CCD flash exposure using the flash command:
flash 4
| HOST |
CONTROLLER |
| Send STP. |
Stop the clocks. Reply DON. |
| Send CLR. |
Clear the detector. Reply DON. |
| Send STP. | Stop the clocks. Reply DON. |
Send PFL 0xFA0 - sent to utility board with 4000ms.
|
Preflash the camera for 4000 milliseconds. Reply DON.
|
Send RDC.
|
Read out the detector.
|
| Wait for controller to complete sending pixels. |
|
Send IDL.
|
Set the detector clocks idling. Reply DON.
|
|
|
Annex D: IR camera Run Sequences
The following tables show the command sequences between UltraDAS (the host), and the SDSU controller for all typical run types.
Run
The command sequence for a typical IR camera run using the run command with 1pre-integration and post-integration read:
run 1
| HOST |
CONTROLLER |
| Send STP. |
Stop the clocks. Reply DON. |
| Send CLR. |
Clear the detector. Reply DON. |
Send WRM 0x2000F0 0x3E8 to utility board- set demand integration time to 1000ms
| Sets the demand integration time in the utility noticeboard to the required number of milliseconds. Reply DON. |
Send MRA 0x1
| Set for MRA with 1 pre and 1 post read
|
|
Read out the detector for the pre-integration read |
Wait for pre-integration read to complete
|
|
|
Read out the detector for the post-integration read |
| Wait for post-integration read to complete |
|
Send RDM 0x4000F0 to utility board - get the actual integration time
|
Return the actual integration time in the utility noticeboard in milliseconds.
|
Send IDL
|
Set the detector clocks idling. Reply DON.
|
|
|
The command sequence for a typical IR camera run using the run command with 2 pre-integration and post-integration reads:
run 1
| HOST |
CONTROLLER |
| Send STP. |
Stop the clocks. Reply DON. |
| Send CLR. |
Clear the detector. Reply DON. |
Send WRM 0x2000F0 0x3E8 to utility board- set demand integration time to 1000ms
| Sets the demand integration time in the utility noticeboard to the required number of milliseconds. Reply DON. |
Send MRA 0x2
| Set for MRA with 2 pre and 2 post reads
|
|
Read out the detector for the 2 pre-integration reads |
Wait for pre-integration reads to complete
|
|
|
Read out the detector for the 2 post-integration reads |
| Wait for post-integration reads to complete |
|
Send RDM 0x4000F0 to utility board - get the actual integration time
|
Return the actual integration time in the utility noticeboard in milliseconds.
|
Send IDL.
|
Set the detector clocks idling. Reply DON.
|
|
|
The command sequence for a typical IR camera run using the run command
with 2 clearing reads, 1 pre-integration and post-integration read:
run 1
| HOST |
CONTROLLER |
Send RDC
|
Read out the detector |
Send RDC
|
Read out the detector |
| Send STP. |
Stop the clocks. Reply DON. |
| Send CLR. |
Clear the detector. Reply DON. |
Send WRM 0x2000F0 0x3E8 to utility board- set demand integration time to 1000ms
| Sets the demand integration time in the utility noticeboard to the required number of milliseconds. Reply DON. |
Send MRA 0x1
| Set for MRA with 2 pre and 2 post reads
|
|
Read out the detector for the 2 pre-integration reads |
Wait for pre-integration reads to complete
|
|
|
Read out the detector for the 2 post-integration reads |
| Wait for post-integration reads to complete |
|
Send RDM 0x4000F0 to utility board - get the actual integration time
|
Return the actual integration time in the utility noticeboard in milliseconds.
|
Send IDL.
|
Set the detector clocks idling. Reply DON.
|
|
|
Bias
The command sequence for a typical IR camera bias using the bias command:
bias
| HOST |
CONTROLLER |
| Send STP. |
Stop the clocks. Reply DON. |
| Send CLR. |
Clear the detector. Reply DON. |
Send WRM 0x2000F0 0x1 to utility board- set demand integration time to 1ms
| Sets the demand integration time in the utility noticeboard to the required number of milliseconds.
1ms is the minimum time that can be set. Reply DON. |
Send MRA 0x1
| Set for MRA with 1 pre and 1 post read
|
|
Read out the detector for the pre-integration read |
Wait for pre-integration read to complete
|
|
|
Read out the detector for the post-integration read |
| Wait for post-integration read to complete |
|
Send RDM 0x4000F0 to utility board - get the actual integration time
|
Return the actual integration time in the utility noticeboard in milliseconds.
|
Send IDL.
|
Set the detector clocks idling. Reply DON.
|
|
|
Annex E: Startup Sequence
The following table shows the command sequence between UltraDAS (the host), and the SDSU controller during camera startup.
| HOST |
CONTROLLER |
Send RESET_CONTROLLER native command to PCI card.
|
Reset the controller.
|
| Send GEN to utility board. |
Reply <gen> where gen = 3 for Gen 3 controllers, or reply ERR for Gen 2 controllers.
|
| Send RDM 0x400000 to utility board - get the camera's ID code. |
Reply <camera-id>. |
| Send WRM sequence to timing board to program the timing board lod file. | Reply DON to each WRM.
|
| Send WRM sequence to utility board to program the utility board lod file. | Reply DON to each WRM.
|
Send PON to utility board.
|
Power on the controller, and reply DON.
|
Send WRM <demand temp noticeboard> <demand temp> to utility board.
|
Set the demand temperature in the noticeboard and reply DON.
|
Send IDL to timing board.
|
Set the detector clocks idling. Reply DON.
|
Send HSP or LSP to timing board.
Note: The command sent is camera dependent, based on the 'rspeed'
setting in the camera's udas_<camera>.dat configuration file.
|
Set the readout speed to high (for HSP) or low (for LSP). Reply DON.
|
|
|