PICTURE Camera Interface Functional Specification

Size: px

Start display at page:

Download "PICTURE Camera Interface Functional Specification"

Chester Gordon
5 years ago
Views:

1 Rev ECO Date Change Summary Author JAN 2006 Initial Draft D. Gordon MAY 2006 Changed to multiplexed DMA, added testmode and FPGA D. Gordon version readback, other minor corrections, additions SEPT 2006 Enhanced Testmode Added overflow error detect (DMA timeout) Corrected PIXSYNCH Polarity as per observed system behavior Changed phasing of Command Data transition with respect to Command Clock D. Gordon PICTURE Camera Interface Functional Specification Dwg. No Rev September 2006 D. Gordon References. 1. PICTURE, System Block Diagram, Revision 02, M. Doucette, 5/25/05, ( ) 2. Octagon Systems, 2050 PC/104 CPU User s Guide 5867(0403) 3. MPU & PPU Interface Timing Requirements, AXIS-0004, Rev 0.03, R. Foster, 12/12/96 4. PICTURE Camera ICD, Rev. 06, November 9, September Rev 0.03

2 Table of Contents 1.0 Introduction PDC Functional Description Timing/Clocks Command Interface Status Interface Pixel Data Interface Test Mode September Rev 0.03

3 1.0 Introduction The PICTURE Camera Interface (aka the CTU) is a component of the PICTURE experiment. The frontend interfaces to the AE box (two CCDs, their controllers and a thermo-electric subsystem). The backend interfaces to a JPL computer via Ethernet. Ext Reset (Switch Closure) Frame Synch Ethernet 100BaseT PC/104 CPU Pentium I Class 128 MHz Ext Reset PC104 bus Protocol/ Data Control AE Box Serial Interfaces PowerIn (+5V, Sense, Gnd) FIGURE 1. PICTURE Camera Interface (CTU): Overall Block Diagram The CTU, shown in Figure 1, receives commands and status queries via the ethernet from the JPL computer (Ethernet TCP/IP) and performs the necessary steps to communicate effectively with the AE box. It returns status to the JPL computer (Ethernet TCP/IP). Pixel data, from the AE box is buffered and transferred to the JPL computer (Ethernet UDP). This document describes the Protocol/Data Control board, a dedicated Interface Converter and a component of the CTU. Future revisions will include an overall description of the CTU software. PC/104 Card The PC/104 card, an Octagon Systems 2050, is a single-board computer with a 10/100 Ethernet Interface. A PC compatible (AT class), it can be configured to run MS-DOS or LINUX. (LINUX is the target OS for the PICTURE controller application.) The 2050 implements the standard PC/104 bus, identical in protocol to the AT ISA Bus. It supports memory and or I/O reads/writes at data widths of 8 or 16 bits. The ISA bus incorporates interrupts and DMA (used for AE Camera pixel data transfer). Protocol/Data Control (PDC) The PDC is a daughter card that plugs into the PC104 bus, communicating with the 2050 via standard ISA protocol. It contains an FPGA (Xilinx Spartan series), a local oscillator, and buffers. It receives power service (+5VDC) from the AE box, which is forwarded to the The Ext Reset signal, directly forwarded to the 2050, is driven by the Rocket Telemetry Subsystem. The FrameSynch signal, received by the JPL computer, drives their CPU Interrupt input. 07 September Rev 0.03

4 2.0 PDC Functional Description The heart of the PDC resides in the FPGA, which contains a series of registers that facilitate information flow between the 2050 and the AE box. The registers are memory mapped into the ISA Address Space as follows: Address Read Register Write Register 0xD0000 PDC Control - same as write value PDC Control D[8] - Enable DMA Subsystem D[7:6] - PIXDATENB - Enables Camera I/Fs (Bit 6 corresponds to CAM0, Bit 7 to CAM1) D[5] - PIXTESTMODE - Supplies canned pixel stream (8x8 Grid) D[4] - FSYNCHSEL - selects source of the Framesynch interrupt (0-> CAM0, 1 -> CAM1) D[3:2] - AECMDMASK - Determines the recipients of the next AE Command. (Bit 2 corresponds to CAM0, Bit 3 to CAM1) D[1] - AERSTCMD - If this bit is set, the next command sent to the AE box will be a hardware pulsed reset. Note, this value supersedes whatever is currently in the AECMDDAT register, which becomes a DONT-CARE when AERSTCMD is asserted. D[0] - XMIT NOOPs - If this bit is cleared (default), pixels tagged with the codes 0 or 8 will not be transferred to the CPU. (The PDC simply bit-buckets them.) 0xD0002 PDC Status D[15:8] - FPGA Version D[7:6] - OVFLERRDET[1:0] - separate flag for each camera indicates if a pixel has been dropped (DMA Timeout) D[4] - PXDMAINT - latched PXDMAINT D[3] - CMDLOADED - If CMDIFBUSY and this bit is clear, do not write to the AECMD registers. PDC Pulse D[7:6] CLROVFLERRDET[1:0] - clear latched overflow error detect D[4] - CLRPXINT - clear latched PXDMAINT D[3] - unused D[2] - DOCMD - start command transmission using the values in AECMDMASK, AER- STCMD, and CMDDATA fields. If this bit is set, the next command can be D[1] - CLRSTATRCD1- clear latched STATRCD written. flag from CAM1 D[2] - CMDIFBUSY - Command I/F is currently D[0] - CLRSTATRCD0 - clear latched STATRCD shifting. Do not change AERSTCMD or AECflag from CAM0 MDMASK when this bit is asserted. DOCMD is ignored if issued when CMDIFBUSY D[1] - CAMSTATRCD1 - Flag indicating that a status word has been received from CAM1 D[0] - CAMSTATRCD0 - Flag indicating that a status word has been received from CAM0 0xD0004 AECMD Data Low - same as write value AECMD Data Low - Bits[15:0] -> AECMDDAT[15:0] 0xD0006 AECMD Data High - same as write value AECMD Data High - Bits[7:0] -> AECMDDAT[23:16] 0xD0008 CAM0STAT Data - not used Bits[15:0] -> CAM0STATDAT[15:0] 0xD000A CAM1STAT Data - Bits[15:0] -> CAM1STATDAT[15:0] not used TABLE 1. PDC FPGA Based Registers 2.1 Timing/Clocks The PDC System Clock (SCLK) is generated by a local oscillator operating at MHz. 07 September Rev 0.03

5 Note: all references to the AE box refer to both sides (each side representing one camera). In most cases, separate logic services each camera. The exception is the Command Interface, which is shared but buffered independently for each camera. The overall AE interface timing, outlined in Reference 3, was verified using the current PIC- TURE AE box (a copy of the ASTRO-E Camera Subsystem). The PDC-AE interface conforms to the reference with some exceptions due to signal inversions in the actual system. CMDCLK (61.44KHz clock) generated by the PDC is forwarded to the AE box (two copies, one for each camera). Command data is synchronized to this clock. The AE subsystem generates its own system clock, from which it creates the pixel clock (492KHz), used to shift out the pixel data streams. Additionally, Status Data is returned from each camera, along with a dedicated status clock (61.44KHz). Each camera is considered asynchronous; its Pixel and Status clocks are treated as separate clock domains, resynched to the PDC master clock as necessary. 2.2 Command Interface Command transmission is based on the protocol defined in Reference 3: 1 start bit (active high) followed by the 24 bit command, followed by at least one stop bit (active low). Command data is shifted out by the PDC 3.7µs following the rising edge of CMDCLK, which provides 4.5µs setup time before the falling edge and approximately 20µs setup time setup prior to the CMDCLK rising edge. (The reason for this timing: it is not clear which edge of the clock the AE-subsystem uses to sample the data.) The CPU can initiate commands by a series of register writes: AECMD-DATALO, AECMD- DATAHI, the Control Register (AECMDMASK and AERSTCMD), and the Pulse Register (DOCMD). The Command Mask steers the command to the addressed camera(s). Note: the mask can be set to address either, both or none of the cameras (In the null case, the shift still occurs, but both command I/Fs are kept inactive). If the AERSTCMD bit is set, the command shift subsystem does not use the AECMDDATA field. Instead, a DOCMD pulse just activates the AERST signal to the addressed camera(s). The RESET pulse, 16 µs, is active low. Following a DOCMD pulse, the PDC sets a CMDIFBUSY flag, which is readable via the PDC status register. During this time, no command transmission related register bits should be altered. (This includes AECMD-DATA, AECMDMASK, and AERSTCMD, as well as the DOCMD pulse.) Approximately 20 µs following the assertion of CMDIFBUSY, the CMDLOADED flag asserts. At this time, the AECMD-DATA registers can be loaded with the next command. The end of transmission (approximately 400 µs after the DOCMD pulse is issued) is indicated by the deassertion of both the CMDIFBUSY and CMDLOADED flags. 07 September Rev 0.03

6 2.3 Status Interface Status, returned to the PDC by the AE box only in response to a query command, uses a protocol similar to the command interface. The AE box shifts status data synchronous to a dedicated STS-CLK. Status data, clocked on the rising edge by the AE box, is sampled on the falling edge by the PDC receiving circuitry. This agrees both with Reference 3 and observed AE-GSE Interface behavior. Data consists of 1 start bit (active high) followed by 16 data bits, followed by many stop bits (because each status word is generated only in response to a command). Following initiation by the AE box, a status transmission requires approximately 275 µs to shift. However, there s an additional delay incurred by the response time lag of the AE box to the query. This delay is dependent on the AE box sequencer program, and could vary between (TBS: minimum delay) and infinity. The PDC provides separate shift registers for each camera (allowing status queries to be sent simultaneously to both cameras). The CAMSTATRCD flag (one for each camera) asserts upon completion of a status word reception. Readable via the PDC Status Register, it must be explicitly pulsed clear by the CPU. The Status Interface subsystem freezes the last value if another word shifts in when the CAMSTATRCD flag is still set. Since clearing the CAMSTATRCD flag also resets the shift-register, the CAMSTATDAT register should be read out prior to clearing the CAMSTATRCD flag. A typical operational scenario might be: (1) Pulse the CAMSTATRCD flag clear; (2) Send Query Command; (3) Wait for the CAMSTATRCD flag to assert; (4) Read the CAMSTATDAT. 2.4 Pixel Data Interface Pixel data arrives to the PDC in a 12-bit serial format. In addition to the four serial data lines (the A,B,C,D video chains) per camera, there is a common Pixel Code that is shared between the four chains. As per Reference 3, Pixel Synch is active low (although it is active high for the AE- Box GSE, most likely due to a differential pair wire-swap). Upon arrival of a set of four pixels, a series of four 16-bit words are transferred via DMA to the host processor via the ISA bus. This Pixel Quartet (PQ) is structured as follows: PQ Word # Bits[15:12] Bits[11:0] Word 0 PQ Start Code: 0x7 Data Video Chain A Word 1 Pixel Code Data Video Chain B Word 2 Camera ID Data Video Chain C Word 3 PQ End Code: 0x5 Data Video Chain D Camera ID is either one or zero, depending on the data source. Pixel data interfaces for each camera operate independently, but the PQ groups are transferred onto a common ISA bus DMA channel (ISA Bus DMA Channel 5). Thus, it is possible that eight 16 bit words may be DMAed on the ISA bus per 26 µs shift period. (A PQ group is never split.) The PDC may discard certain pixels depending on the state of the XMIT_NOOPS control bit. If XMIT_NOOPS is set to one, all pixels are transferred. If cleared, pixel codes 0 and 8 are discarded. 07 September Rev 0.03

7 The ISA bus interrupt (IRQ5) that activates when 32 (TBR) PQ groups have been transferred via the DMA I/F (corresponding to 256 bytes). The processor can read the interrupt flags (latched until explicitly pulsed cleared by the CPU) via the status register. The backplane interrupt is a pulse, active low, of approximately 135 ns in duration. The PDC drives a FRAMESYNCH output, activated by the reception of pixel code 0xA (corresponding to the frame-synch pixel code). This active-low pulse, approximately 135ns, is driven by an open collector driver (with an option for a pull-up resistor at the source). Either camera can drive FRAMESYNCH, controlled via the FSYNCHSEL bit of the PDC Control Register. Overflow Error (per camera interface) status flags are provided to indicate if a pixel has been lost. This condition may occur if the camera interface is enabled, but DMA has not been activated, or if there are gaps in the DMA servicing. These status flags must be explicitly cleared by the CPU via the pulse register Test Mode Test mode allows for the transmission of a predetermined pattern in stand-alone mode (no AE box). While in Test Mode, the camera pixel inputs are ignored. Instead each Pixel Data Controller transfers an 8x8 grid of pixels. Since the two subsystems are controlled by common logic, pixels from both Pixel Data Controllers are queued to the DMA I/F simultaneously. The PIXDATENB field enables/disables each Pixel Data Controller during testmode, as it does during normal operation. The Test Mode data for each PQ group is: Camera 0: COUNT; X"001"; X"002"; NOT(COUNT); Camera 1: NOT(COUNT); X"005"; X"006"; COUNT; Camera 0 shows an incrementing pattern in Word0, and a decrementing pattern in Word3. Camera 1 shows a decrementing pattern in Word0, and an incrementing pattern in Word3. Constants are used for Word1 and Word2. Pixel code (in hex) arrangement is shown below: 1 B B B B B B D 2 B B B B B B E (2 => line start; 1 => frame start; B => active pixel; D => line end; and E => frame end). 07 September Rev 0.03

Hello, and welcome to this presentation of the STM32 Universal Synchronous/Asynchronous Receiver/Transmitter Interface. It covers the main features

Hello, and welcome to this presentation of the STM32 Universal Synchronous/Asynchronous Receiver/Transmitter Interface. It covers the main features of this USART interface, which is widely used for serial