Firmware Topics

From NOAOWiki

Jump to: navigation, search

Contents

Torrent Firmware Discussion Page

Return to the Torrent home page

DHE Communication link bandwidths

There are four communication channels available on the Torrent DHE. The table below shows the available bandwidth for these links and their intended use.

DHE Communication Channels
Channel Bit Rate Command Bandwith (32-bit Words) Video Data Bandwith (18-bit Words) Purpose
Systran 1.0625 GBit/sec 26.5 Meg/sec 26.5 (53 for 16-bit packed pixels) Meg/sec Primary command downlink, Primary data uplink.
Sync In/Out 39.8 Meg/sec 1.0 Meg/sec n/a Inter-DHE communications, commands, synchronization
UART 9600 240 / sec n/a Engineering and maintenance
GIGe Vision Gigabit Ethernet 412.5 K/sec 26.5 Meg/sec (16-bit words). Alternate control downlink and data uplink

Return to top of Firmware Topics#top

LCB Clock Sources and Frequencies

There are several clock sources available from the LCB clock synthesizer hardware (U28). These clocks provide synchronization to specific areas of the Torrent hardware and firmware. The table below lists the clock name, the nominal frequency and their intended application.

Available LCB clock sources
Clock Name Frequency (Mhz) Purpose
OCLK (internal) 106.25 LCB Oscillator used during LCB Initialization and in Master mode.
sync_in_clk (internal) 39.84375 Master clock input when in Slave mode. OCLK is shut down
BCLK (internal) 106.25 (Master) / 39.84375 (Slave) Clock source for the clock synthesizer. OCLK or sync_in_clk
SysClk (internal) 106.25 General logic, Wishbone bus clock
LCLK 106.25 Low jitter clock source for the GTP Transceiver (SFPDP comms)
PCLK 159.375 Memory.
DCLK 79.6875 AFE interface bridge logic.
TCLK 39.84375 AFE ADC data clock
MCLK 39.84375 Sync port communications and synchronization logic

These clocks are derived from U28 (LMK03000) using the following register constants

LMK03000 Programming Scheme for Master DHE (BCLK = 106.25 MHz)
Clock Name Phase detect Freq. (Mhz) VCO Freq. (Mhz) Divide by 'R' Value VCO Divider Value Divide by 'N' Value Clock Divider Value
SysClk 13.28125 1275 8 2 48 6
LCLK 13.28125 1275 8 2 48 6
PCLK 13.28125 1275 8 2 48 4
DCLK 13.28125 1275 8 2 48 8
TCLK 13.28125 1275 8 2 48 16
MCLK 13.28125 1275 8 2 48 16

For DHE Slave operation, where the BCLK frequency is 39.84375 MHz, the value of the Divide by 'R' value changes to 3. All other constants remain the same. Return to top of Firmware Topics#top

Clock Sources for Master sync clock

There are two clock sources available to provide the master OUTSYNC_CLK. The FPGA internally generated source and a source generated directly from the clock synthesizer hardware (U28). These clocks provide synchronization to the slave DHE systems. The table below lists the combinations available by writing to the SyncClkSelect attribute.

SYNC clock sources and routing
Attribute value OUTSYNC_CLK Source FPGA SYNC CLK source Attribute value OUTSYNC_CLK Source FPGA SYNC CLK source
0x0 U28 U28 0x8 Invalid state Invalid state
0x1 FPGA U28 0x9 Invalid state Invalid state
0x2 U28 FPGA 0xA U28 Disabled
0x3 FPGA FPGA 0xB FPGA Disabled
0x4 Disabled U28 0xC Disabled Disabled
0x5 Invalid state Invalid state 0xD Invalid state Invalid state
0x6 Disabled FPGA 0xE Invalid state Invalid state
0x7 Invalid state Invalid state 0xF Invalid state Invalid state

Return to top of Firmware Topics#top

RS232 Communication Channel Command Codes

The LCB supports an engineering RS232 communication port for engineering use. The available commands (shown below) are prefixed with the 'plus' (+) character (0x2B) and completed with a 'Line Feed' character (0x0A). The standard format of 9600 Baud, 8 bits, no parity is supported. Upper or lower case characters are recognized. All address and data values must be expressed in hex. Fields must be separated by a space or tab character. Backspace clears the current command (although currently the display looks messy).

Torrent engineering commands for RS232 link
First Field Second Field Third Field Forth Field Command description
+A 16-bit vector (valid range 0x0 through 0xFFFF) Not Used Not used Forces an Asynchronous Command to synchronize the communication channels after reset
+R Module number (valid range 0x01 through 0xFF) Module Address (valid range 0x0 through 0xFFFF) Not used Returns the 32-bit contents of the addressed register (in hex)
+W Module number (valid range 0x01 through 0xFF) Module address (valid range 0x0 through 0xFFFF) 32-bit data value (valid range 0x0 through 0xFFFFFFFF) Writes the 32-bit value to the addressed register
+S 8-bit data value (valid range 0x0 through 0xFF) as sequencer start vector Not used Not used Triggers a 'Start Exposure' event in the sequencer with the 8-bit start vector

Return to top of Firmware Topics#top

Firmware Module Addressing and Identity Codes

As per ICD 6.1 we use a board select code in each command sent to the LCB to address the individual modules that make up the firmware suit loaded to the Virtex part. This note pretends to fix the identity of the modules selected by each bit of the board select bit field used in the command structure. There are 10 bits available in this field. Torrent currently supports the use of the lowest order five bits although eight bits can be specified (with minor modification) in the Torrent architecture. The table below identifies the correspondence:

Torrent firmware module addressing
Board Select Bit Module Selected Module Abbreviation Module Identity Code Module purpose
0 (0x01) LCB Control Module LCB 201 Communications and digital control of the Torrent DHE
1 (0x02) Power Supply Services PSM 202 Safety, Control, and telemetry of the power supply board (PSM)
2 (0x04) Configuration Services CFG 203 Configuration data management (eeprom data), LCB clock control and sequencer (CFG)
3 (0x08) Pixel Data Services PIX 204 Pixel data memory and descrambling logic common to OUV and IR (PIX)
4 (0x10) Analog Front End Control (AFE) AFE 205 Analog front end electronics control and pixel acquisition (IR or OUV).
5 (0x20) Spare select bit SPR1 Not assigned Spare module select bit.
6 (0x40) Spare select bit SPR2 Not assigned Spare module select bit.
7 (0x80) Clock Services CLK 208 Clock control module.

Return to top of Firmware Topics#top

Standard Data Destination Codes for Communication

The LCB_Control module supplies four duplex channels of communications with the DHE. These four comms channels are: Serial FPTP (Systran Emulation), GIGe (Gigabit ethernet), UART (via serial at 9600 Baud, no handshake), and the SYNC port that links to other slave/master DHE's. The comms destination bits set the required destination for these devices. Setting more than one bit results (mostly !) in parallel transmission to all devices.

Comm Device bit assignments
Bit Number Comm Device
0 ("0001") Serial FPDP
1 ("0010") SYNC Port
2 ("0100") UART Port
3 ("1000") GIGe Port

Return to top of Firmware Topics#top

Standard Register Addresses for Firmware Modules

Each firmware module must supply several registers to support the automatic recognition and configuration processes of the PAN computer. These module addresses are shown below with their functional description:

Standard Torrent Module Registers
Address Register Name Write / Read Register purpose
0xFFFF CodeId 32-bit read only Version number of the firmware module code as an integer. Divide by 100 for major / minor version.
0xFFFF RebootCmd 32-bit Write only (data discarded) Write to this register to warm reboot the LCB. All module select bits must be high i.e. 0xFF.
0xFFFE ModuleId 32-bit read only Module identification number of the firmware module - see section on Firmware Module Addressing and Identity Codes
0xFFFE ResetCmd 32-bit Write only (data discarded) Write to this register to reset the module. Multiple module select bits may be specified in the same command. Writing to this location with the all board select bits set high effects a general LCB system reset to all modules and the wishbone bus infrastructure.
0xFFFD Status 32-bit Read only Read of module status word - Data is module specific.

Return to top of Firmware Topics#top

Power Supply Status word definition

The power supply monitors the state of the hardware protection circuits on the LCB-MEZ board. These status bits, when true, indicate a hardware protection fault condition that has interrupted the power supply to one or both of the AFE boards. This status regester is (usually) read as an attribute from the DHE at address 0x016F. The attribute name is PwrSupplyStatus.The status bits and their function definitions are shown below :

Power Supply Status Register
Bit Purpose Bit Purpose
7 AFE-1 VANA Power Protection Active 3 AFE-1 / AFE-2 VHV Power Protection Active
6 AFE-1 VCB Power Protection Active 2 Vbb supply active
5 AFE-2 VANA Power Protection Active 1 AFE Power Up Sequence Complete / AFE Power is _ON_
4 AFE-2 VCB Power Protection Active 0 Power Supply Power Up Sequence Complete / Power is Available

Return to top of Firmware Topics#top

AFE Mezzanine Override register bit definitions

The mezzanine override register allows you to independently control the AFE power enable bits for the mezzanine board. This is _ONLY_ used for testing purposes since indiscriminate enabling power supplies can cause you to exceed the power supply load capabilities. This register is read and write at address 0x202 in the PSM module

Mezzanine Override Register
Bit Purpose Bit Purpose
7 Not used 3 Not used
6 AFE 2 +/- VHV supply enable 2 AFE 1 +/- VHV supply enable
5 AFE 2 +/- VCB supply enable 1 AFE 1 +/- VCB supply enable
4 AFE 2 +/- VANA supply enable 0 AFE 1 +/- VANA supply enable

Return to top of Firmware Topics#top

DheTempSensorSlct Register Value Significance

This register select which temperature sensor in the DHE is to be used for feedback in the DHE temperature servo loop. The selection of the sensor is based upon a 1 Of 8 (3-bit) code set into the DheTempSensorSlct attribute. The codes are :

DheTempSensorSlct Register Significance
Code Selected Temp Sensor
0 ("000") FPGA temperature sensor (default)
1 ("001") LCB_temperature0
2 ("010") LCB_temperature1
3 ("011") AFE1_temperature0
4 ("100") AFE1_temperature1
5 ("101") AFE2_temperature0
6 ("110") AFE2_temperature1
7 ("111") Load feedback from PAN attribute write (for testing purposes)

Return to top of Firmware Topics#top

Sequencer State Register Bit Assignments for Firmware Modules

Each firmware module that requires to know the sequencer state information provides a 32-bit register at address 0xFFF0. The sequencer uses this register to periodically write the sequencer state information to all modules that use this address. The lower 16-bits of the register are static values and may be used to indicate the current mode of the sequencer function (e.g. ROI Readout Mode, Digital Averaging Enabled, etc.). The top 16-bits (31:16) are strobe signals that indicate an event during the sequencer operation (Frame Start, Line Start, etc.) and these bits persist for, and are synchronous to one SysClk cycle before being cancelled. The table below indicates the significance of the Sequencer State Register.

Sequencer State Register Assignments
Bit Signal Type Used By Bit Signal Type Used By
31 FrameStartSync Strobe AFE 15 Spare Static n/a
30 LineStartSync Strobe AFE 14 Spare Static n/a
29 Spare Strobe n/a 13 Spare Static n/a
28 Spare Strobe n/a 12 Spare Static n/a
27 Spare Strobe n/a 11 Spare Static n/a
26 Spare Strobe n/a 10 Spare Static n/a
25 Spare Strobe n/a 9 Spare Static n/a
24 Spare Strobe n/a 8 Spare Static n/a
23 Spare Strobe n/a 7 Spare Static n/a
22 Spare Strobe n/a 6 Spare Static n/a
21 Spare Strobe n/a 5 Spare Static n/a
20 Spare Strobe n/a 4 Spare Static n/a
19 Spare Strobe n/a 3 Spare Static n/a
18 Spare Strobe n/a 2 Spare Static n/a
17 Spare Strobe n/a 1 Spare Static n/a
16 Spare Strobe n/a 0 Spare Static n/a

Return to top of Firmware Topics#top

Addresses for I2C Bus Devices / FPGA Boot Code Version Selection

There are five I2C buses associated with the Torrent DHE; one I2C bus for every physical board (LCB, PSM, TSM, AFE1, AFE2). There are four devices attached to each bus. This table lists their addresses and describes their use. During the DHE initialization (just after boot), the SDA signal line of each I2C bus is used to detect the presence of the physical board. The SCL signal for AFE1 (AFE_SCL_SRC0) is also used to direct the revision of the code that is booted at power up. This signal is pulled 'high' through a 50K Ohm pullup to 3.3v on the LCB. IR AFE boards should pull this signal low via a 3.3K Ohm resistor to the VPIFC GND return. This will select revision zero of the XF32P eeprom (LCB U43) boot code to load to the FPGA for IR operation. CCD AFE boards should leave this signal floating to select revision 1 of the boot code for VIS operation.

I2C Bus Module Addresses
Address Device Type Description
0x48 MCP9803 Temperature sensor used to control the DHE operating temperature and supply telemetry
0x49 MCP9803 Temperature sensor used to control the DHE operating temperature and supply telemetry
0x50 DS28CM00 48-bit silicon serial number as unique identity for each hardware board. Only the ls 32-bits are read.
0x54 24AA128 Calibration coefficient store space. Page written and read; 256 Pages each with 16 x 32-bit words.

For PAN control of these resources there are several registers that are used to read and write to the I2C devices. These are listed in the following table:

Control of I2C EEProm, Temperature sensors, and Silicon Serial Numbers
Attribute name Address Write Value Read Value Description
DetectI2CBus 0x0012 Anything Bit(4)=AFE2 Detected, Bit(3)=AFE1 Detected, Bit(2)=TSM Detected, Bit(1)=PSM Detected, Bits(0)=always '1' 5-bit read/write register. Write anything to initiate I2C bus detection, Read to see hardware devices available
ReadI2CBusTemps 0x0013 Bits(20:16)=I2C Channel Addr, Bit(0)=Temperature sensor 1 or 2. Not Accessible 32-bit write register. Write to initiate I2C temperature sensor read cycle and update read only registers.
ReadI2CBusSerialNumbers 0x0014 Bits(20:16)=I2C Channel Addr. Not Accessible 32-bit write register. Write to initiate I2C silicon serial number reads and update read only registers
eepRdCmdReg 0x0020 Bits(20:16)=I2C Channel Addr. Bits(7:0)=EEProm page address. Bit(31)=I2C manager busy, Bit(30)= Error occurred during read - bad I2C acknowledge. 32-bit read/write register. Command register to select and read an eeprom page
eepWrtCmdReg 0x0021 Bits(20:16)=I2C Channel Addr. Bits(7:0)=EEProm page address. Bit(31)=I2C manager busy, Bit(30)= Error occurred during write - bad I2C acknowledge. 32-bit read/write register. Command register to select and write an eeprom page

Channel Address values for the physical hardware boards are: LCB = 1, PSM = 2, TSM = 4, AFE1 = 8, AFE2 = 16.

For the ReadI2CBusTemps, ReadI2CBusSerialNumbers, and eepWrtCmdReg commands, multiple channel addresses are allowed (i.e. you can read multiple temperature sensors or write the same data to multiple EEproms using just one command transaction).

For the eepRdCmdReg command, only one unique channel address is allowed.

Return to top of Firmware Topics#top

Bit significance for the LED_1_Slct and LED_2_Slct indicator attributes

There are two 8-bit registers assigned to provide visual indication of the internal signals of the FPGA. These registers are read / write. By setting a bit true the indicator (LED1 or LED2) will flash briefly (25ms) every time the selected signal becomes active true. LED1 is currently mounted on the Sync In port connector and LED2 is mounted on the Sync Out Port connector. The tables below indicate the significance of each attribute bit.

LED1 Signal Select Bits
bit signal
7 BusReset
6 SlaveErrOut(4)
5 SlaveErrOut(3)
4 SlaveErrOut(2)
3 SlaveErrOut(1)
2 SlaveErrOut(0)
1 CfgCycleRequest
0 LcbCycRequest
LED2 Signal Select Bits
bit signal
7 SRC_SYNC_OUT
6 SNK_SYNC_IN
5 V33_SYNC_OUT
4 V300_POLARITY
3 V180_PWR_EN_N
2 V80_PWR_EN_N
1 VFAN_PWR_EN_N
0 MCLK_SEL_N

Return to top of Firmware Topics#top

DbgSigSlct attribute values

This attribute controls the selection of a group of eight signals that are presented on the CFGDATA(7:0) signals (connector J4) on the LCB. By setting the attribute to different values, the hardware debug signals are available for diagnostic use. The attribute accepts values from zero to ten. The list below shows the significance.

DbgSigSlct Attribute values
Value Signal Group
0 Signals off
1 LCB Control Signal group
2 PSM Services Signal group
3 CFG Services Signal group
4 PIX Services Signal group
5 AFE Control Signal group
6 Signals off - Future AFE2 Signal group
7 Signals off - Spare
8 CLK Services Signal group
9 System Bus Signal group
10 Auxiliary Signal group

These tables list the individual signals for each group.

DbgSigSlct = 1 - LCB Control signal assignments
bit signal
7 GIGe_PIXEL_CLK
6 GIGe_FVAL
5 GIGe_LVAL
4 GIGe_DVAL
3 PixDataRdy
2 GIGe_BULK0_CLK
1 GIGe_BULK0_RXD
0 LinkUp
DbgSigSlct = 2 - PSM Services signal assignments
bit signal
7 AfePwrIsOn
6 TEMP_2_SNS
5 TEMP_1_SNS
4 LOGIC_SYNC
3 V300_SYNC
2 V180_SYNC
1 V80_SYNC
0 V33_SYNC
DbgSigSlct = 3 - CFG Services signal assignments
bit signal
7 MstrScl
6 MstrSdain
5 MstrSdaOut(2)
4 MstrWrtEn
3 SYNC_DHE
2 SE_OUT
1 SE_READY
0 SYNC_POWER
DbgSigSlct = 4 - PIX Services signal assignments
bit signal
7 MemInitDone
6 DlyClkLocked
5 app_af_wren
4 app_af_cmd(0)
3 app_af_cmd(1)
2 rd_data_valid
1 app_wdf_wre
0 MemoryDataClk
DbgSigSlct = 5 - AFE Control signal assignments
bit signal
7 DacDevData(17)
6 DacDevData(16)
5 AFE_CLKBIAS(77)
4 AFE_CLKBIAS(48)
3 SerialSync(0)
2 SerialData(0)
1 SerialClk(0)
0 DacCtrlDataRdy
DbgSigSlct = 8 - CLK Services signal assignments
bit signal
7 DCLK_FEED
6 BCLK_FEED
5 CLK_CTRL_CS_N
4 CLK_CTRL_GOE
3 CLK_CTRL_LOCK
2 CLK_CTRL_SYNC
1 CLK_CTRL_DATA
0 CLK_CTRL_CLK
DbgSigSlct = 9 - System signal assignments
bit signal
7 Mstr1Grnt
6 Mstr0Grnt
5 SlaveCycle
4 SlaveWrite
3 SlaveError
2 StatusEnable
1 SlaveAck1
0 SlaveAck0

Return to top of Firmware Topics#top

Wishbone system status signal assignments for Firmware Modules

Each firmware module can supply eight bits of 'out of band' status information which is used to transport slow signals (such as static configuration values) to other modules. The routing is controlled by the System Intercon module which employs static assignment to route input status bits to the global 32-bit output status sent to the other modules slave interface. The table below shows the routing information for the system at FPGA version level 210.

Global Status Assignments
Bit Signal Origin Used By Bit Signal Origin Used By
31 ShutDownQuick PSM AFE 15 n/a n/a Spare
30 AsyncFlag LCB CFG 14 n/a n/a Spare
29 ReadoutInProgress CFG AFE 13 n/a n/a Spare
28 FrameStart CFG AFE 12 n/a n/a Spare
27 LineStart CFG AFE 11 n/a n/a Spare
26 MemPwrEnbld PSM PIX 10 n/a n/a Spare
25 ClocksAreLocked CLK PIX 9 n/a n/a Spare
24 AFEPowerOn PSM AFE 8 StreamMode PIX AFE
23 VHVPolarity PSM AFE 7 DheIsSlave CFG LCB, CLK
22 n/a n/a Spare 6 Pixels16 PIX LCB
21 n/a n/a Spare 5 PackedPixels PIX LCB
20 n/a n/a Spare 4 AFE2_Detected CFG PSM, AFE
19 n/a n/a Spare 3 AFE1_Detected CFG PSM, AFE
18 n/a n/a Spare 2 TempChanSlct(2) PSM CFG
17 n/a n/a Spare 1 TempChanSlct(1) PSM CFG
16 n/a n/a Spare 0 TempChanSlct(0) PSM CFG

These next tables show the module status output assignments:

Local Control Board Module Status Output Assignments

Local Control Board Module (LCB) System Status Output Assignments
Bit Signal Description Bit Signal Description
7 n/a Spare 3 n/a Spare
6 n/a Spare 2 n/a Spare
5 n/a Spare 1 n/a Spare
4 n/a Spare 0 AsyncFlag True after reboot while waiting for a comm port async command
Local Status significance
Bit Signal Description Bit Signal Description
0 AsyncFlag_i Awaiting communication sync command from PAN 7:1 n/a Spares
8 CommDeviceBusy_i The science data comms channel is blocked up 9 SfpdpLossOfSig_i Systran link down. No carrier present signal
10 SfpdpTxFault_i There is a hardware fault in the Systran optical transmitter part 11:12 n/a Spares
28:13 WbErrorStats_i(15:0) Wishbone bus error statistics

Return to top of Firmware Topics#top

Power Supply Services Module Status Output Assignments

Power Supply Services Module (PSM) System Status Output (0xFFFD) Assignments
Bit Signal Description Bit Signal Description
7 n/a Spare 3 ShutDownQuick Emergency shutdown signal
6 VHVPolarity True indicates N-Channel mode (positive VHV) 2 TempChanSlct(2) 1 of 8 slct of DHE temperature control sensor
5 AFEPowerOn The AFE boards have VANA+/- powered up 1 TempChanSlct(1) 1 of 8 slct of DHE temperature control sensor
4 MemPwrEnbld 1.8v Memory power is available. 0 TempChanSlct(0) 1 of 8 slct of DHE temperature control sensor
PSM Local Status register (0xFFFC) significance
Bit Signal Description Bit Signal Description
0 VFanTempSensorSlct_reg(0) Same signal as system status 1 VFanTempSensorSlct_reg(1) Same signal as system status
2 VFanTempSensorSlct_reg(2) Same signal as system status 3 ShutDownQuick Panic !!
4 TsmPresent_i Indicates that the TSM is present. 5 n/a Spare
6 n/a Spare 7 n/a Spare
PSM Power Status Register (0x020F) significance
Bit Signal Description Bit Signal Description
0 PrimaryPwrStat Primary power is available 1 AfePwrStat AFE power is available
2 VbbEnableFlag Vbb supply is enabled (after safety conditioning) 3 AfeV300Fail Mezzanine Fail indicator for VHV
4 Afe2V180Fail Mezzanine Fail indicator for VCB on AFE2 5 Afe2V80Fail Mezzanine Fail indicator for VANA on AFE2
6 Afe1V180Fail Mezzanine Fail indicator for VCB on AFE1 7 Afe1V80Fail Mezzanine Fail indicator for VANA on AFE1
PSM Mezzanine Override Register (0x0202) significance
Bit Signal Description Bit Signal Description
7:0 MezOverRide_reg As written by PAN 8 Afe1V80Fail Mezzanine Fail indicator for VANA on AFE1
9 Afe1V180Fail Mezzanine Fail indicator for VCB on AFE1 10 AfeV300Fail Mezzanine Fail indicator for VHV
11 n/a Not used 12 Afe2V80Fail Mezzanine Fail indicator for VANA on AFE2
13 Afe2V180Fail Mezzanine Fail indicator for VCB on AFE2 14 AfeV300Fail Repeat of Mezzanine Fail indicator for VHV

Return to top of [[Firmware Topics#top]

Configuration Services Module Status Output Assignments

Configuration Services Module (CFG) System Status Output Assignments
Bit Signal Description Bit Signal Description
7 n/a Spare 3 DheIsSlave The DHE is configured as a slave device in a multi-DHE system
6 n/a Spare 2 AFE2_Detected The AFE2 board is physically present
5 LineStart Indicates a new row beginning 1 AFE1_Detected The AFE1 board is physically present
4 FrameStart Indicates a new frame beginning 0 ReadoutInProgress Sequencer is actively reading detector
Local Status significance
Bit Signal Description Bit Signal Description
0 ReadoutActive Sequencer EFR bit to indicate that ... 1 AFE0_ModuleDetect AFE1 has been detected during the I2C bus search
2 AFE1_ModuleDetect AFE2 has been detected during the I2C bus search 3 DheIsSlave DHE is operating as a slave DHE
4 FrameStart A frame start flag has been issued in the pixel stream 5 LineStart A line start flag has been issued in the pixel stream
15:6 not used Spare 19:16 BusTimeoutReg Sequencer Wishbone master Bus Timeout Register
23:20 BusGrantReg Sequencer Wishbone master Bus Grant error register 27:24 BusErrorReg Sequencer Wishbone master Bus slave Error register
31:28 BusEventStatusReg Sequencer Wishbone master Bus status register

Return to top of Firmware Topics#top

Pixel Services Module Status Output Assignments

Pixel Services Module (PIX) System Status Output Assignments
Bit Signal Description Bit Signal Description
7 n/a Spare 3 n/a Spare
6 n/a Spare 2 StreamMode Pixel data path configured for Stream Data acquisition mode i.e. no memory buffering
5 n/a Spare 1 Pixels16 Pixel data has been scaled to 16-bits by the PIX module.
4 n/a Spare 0 PackedPixels Each 32-bit pixel data word contains 2 x 16-bit pixels.
Local Status significance
Bit Signal Description Bit Signal Description
0 MemCntrInitDone_i Memory system calibrated and ready for use 31:1 n/a Spares

Return to top of Firmware Topics#top

Analog Front End Control Module Status Output Assignments

System Status Output Assignments
Bit Signal Description Bit Signal Description
7 n/a Spare 3 n/a Spare
6 n/a Spare 2 n/a Spare
5 n/a Spare 1 dac_fifo_empty_flag When true, AFE is busy updating DAC values
4 n/a Spare 0 n/a Spare
Local Status significance
Bit Signal Description Bit Signal Description
0 RfshTpActFlag Test points are being refreshed 1 RfshActiveFlag DAC and Test Points are being refreshed
4 tp_fifo_empty The Test point write FIFO is empty 5 dac_fifo_empty The DAC write FIFO is empty
8 TelScanGo Telemetry scan is active 9 RfshTpWrtFifo transfer test point index to tp write fifo

Return to top of Firmware Topics#top

Clock Services Module Status Output Assignments

Clock Services Module (CLK) System Status Output Assignments
Bit Signal Description Bit Signal Description
7 n/a Spare 3 n/a Spare
6 n/a Spare 2 n/a Spare
5 n/a Spare 1 n/a Spare
4 n/a Spare 0 ClocksAreLocked Clock Synthesizer has lock and clocks are good
Local Status significance
Bit Signal Description Bit Signal Description
0 LockDetect_i The clock generator is running locked to the reference frequency 31:1 n/a Spares

Return to top of Firmware Topics#top

Power Supply Services Module

On Fri, 10 Apr 2009 18:13:13 Peter Moore <pmoore@noao.edu> wrote:

Hi Guys,

I've added a couple of sections to the Torrent Wiki firmware page ... FYI ..

I've just thought .. we should have got Bob @ Fishcamp to use teh Wiki for the testing feedback !!

Nick, If I specify two things at the same address in the .vhdl files, one write and the other read ... what happens ??


e.g. -- ATTRIBUTE DESCRIPTION:

-- #MD:LCB:0x01: --This is the Wishbone module select address of the LCB Control Module.

--##AD: EEPadr: AttrName: #InArr: #Values: TypCde: RegAddr: AdrIncr: Size: SetMthd: RdMthd: Comment:

-- #AD: UNDCD: CodeId: 1: 1: A: 0xFFFF: 0: 16: NONE: SMPL: Firmware module revision code as MM.mm

-- #AD: UNDCD: RebootCmd: 1: 1: A: 0xFFFF: 0: 0: SMPL: NONE: Causes Firmware Reboot

-- #AD: UNDCD: ModuleId: 1: 1: A: 0xFFFE: 0: 32: NONE: SMPL: Firmware module identification code as an integer

-- #AD: UNDCD: ResetCmd: 1: 1: A: 0xFFFE: 0: 0: SMPL: NONE: Causes module reset

Ooops .. hope you can decipher that !!

Cheers, Peter.

On Mon, 30 Mar 2009 10:47:59 -0700 David Sawyer <dsawyer@noao.edu> wrote:

Hi Peter, I looked up the logic supply sync requirements and the parts are rated for 750 - 2250 KHz. So, can we use the same sync generator for these as the V80A supplies (750-1000 KHz)? That would reduce the number of sync generators to three.

Also, did you put the code for the Orange sync generators on Big-boy yet?

--Dave

On Mon, 30 Mar 2009 14:11:31 -0400 Peter Moore <pmoore@noao.edu> wrote:

Hi Dave,

Yes by all means use the V80A supply sync generator for the LCB logic supplies.

Oooops no .. I haven't put the sync code there yet .. I've copied the code below. This module accepts a strobe signal in (SYNC_IN) that is generated by the sequencer writing a command code to the register. This is done when the sequencer is about to trigger the CDS micro-sequencer code on the CCD Acquisition board that results in a pixel acquisition sequence. Therefore the sync generator tracks the sequencer process.

You can find this same code in any McbSeqFpga code version after 4.64 (i.e. decapod//MNSN/MonsoonAdmin/Production/TST_Repository/TestProcedures/Firmware/McbSeqFpgaV467 )

Good luck !! Peter.


On Mon, 30 Mar 2009 14:12:53 -0400 Peter Moore <pmoore@noao.edu> wrote:

Dave ...

P.S This code is rudimentary .. It was produced to test the small orange power supply design. It could be improved upon !!


On Mon, 30 Mar 2009 16:20:46 -0700 David Sawyer <sawyer@noao.edu> wrote:

Hi Peter,

I am thinking about the sync generator logic and I have a question for you. For the VN80A supply the allowable sync freq range is 750-1000 KHz. So, what happens if the pixel rate is say 600 KHz? The fundamental pixel frequency is too low and the 2nd harmonic (1200 Khz) is too high. How do I generate a sync clock under this type of condition?

--Dave

On Tue, 31 Mar 2009 09:52:43 -0400 Peter Moore <pmoore@noao.edu> wrote:

Good morning Dave,

Maximum specified rate for the CCD acquisition is 500KPix/chan/sec.

This means that above 333KPix/sec (or below 250Kpix) you cannot use the 3rd harmonic, you will need to use the second (or fourth).

Cheers, Peter.

On Tue, 31 Mar 2009 08:13:42 -0700 David Sawyer <sawyer@noao.edu> wrote:

Hi Peter, Okay, fair enough. That was a bad example. What about pixel rates between 333 and 375 KHz? Say 350 KHz, the 2nd harmonic would be 700 KHz (too low) and the third would be 1050 KHz (too high). Also, what is the minimum pixel rate? If we go down to 100 KHz we'll need to go out to the 8th harmonic. --Dave

On Tue, 31 Mar 2009 11:21:25 -0400 Peter Moore <pmoore@noao.edu> wrote:

JaJaJa .. pushy Dave pushy .. Okay .. Let me do an analysis on the video processor bandpass characteristics so that we can tie down the best approach (i.e. even harmonics, odd harmonics, odd then even, etc.) to place teh switching frequency into the zeros of the system response.

It will take me a couple of days so I suggest you talk with Bob at Fishcamp and ask him to stretch the tested sync frequencies to determine the point that the supplies become dangerously in-efficient (i.e. start to smell) ... Then we can devise a strategy on both data sets.

Cheers, Peter.

On Tue, 31 Mar 2009 08:56:45 -0700 "David Sawyer" <sawyer@noao.edu> wrote:

Okay guys, humor me... What if we added an attribute called "pixel rate" that sets a master clock for the sequencer. This clock is used to generate CTCs and is divided by, say 128, to produce a reference clock for the serial state transitions. This master clock would also serve as the reference sync clock for the PSM. By having the attribute we would be able to set pixel rate limits. Also, with the sequencer states referenced to this attribute it would be easy to change the pixel rate without having to modify the sequencer. This would also eliminate the algorithm in the PSM sync generators needed to determine the pixel rate. Comments? --Dave

On Tue, 31 Mar 2009 16:14:29 -0400 "Peter Moore" <pmoore@noao.edu> wrote:

HiYa Dave,

Okay .. First, here's a ramble about what we are trying to do with the power supply synchronization, then I'll go on to discuss your idea.

The fundamental concept to making the power supply noise disappear is to make any periodic interference generated by the power supply appear as a DC offset to the cds circuit. This mainly applies to ripple but also to any spurious currents (causing voltage spikes) that occur due to parasitics etc. To achieve this we ideally need to make the switching frequency of the power supply synchronous to the pixel cds circuit timing - at the fundamental or at any harmonic of the cds processor frequency. The idea of using the third harmonic is to put the power of the switcher into a harmonic that is already present at a relatively low energy (instead of adding power to an already energetic harmonic) but this choice ignors the fact that it is the third of the CDS which is not acquiring a square wave (where the third would be a natural choice), rather an arbitrary signal waveform .. so the third harmonic of the pixel rate is not necessarily the best. In fact the best will always be the fundamental since the cds does a difference on signals acquired during the pixel time so we could position the switcher sync pulse inside the ccd reset pulse and remove it (in time) from the sensitive period during acquisition of the signal!

Now we have to consider what the best thing is to do with the spurious stuff (ringing, spikes) that occur and that we have no control over with regards to their timing or amplitude. I've generated some (pretty basic) plots based on a modified (for signal) transfer function algorithm of the cds circuit (see JJ's bible section 6.4.4). It shows that the sensitivity of the cds is mainly governed by the time set between the dwell periods (i.e. between ending the reset sample and starting the video sample). This causes a comb filter to be formed that has a first pole generally above the 500KHz area (don't confuse pixel rate with this value !) when this delay is less than 0.5us - which is usually the case. So this _would_ allow any spurious interference from the switcher at or around this value to be seen. We can of course get around this by modifying the cds timing (i.e. the 'inter dwell delay' time) so as to put a zero on anything that is present nad that we cannot control. Coupled to this is the ability to enhance the attenuation of these signals by increasing the dwell time itself since the first order transfer function is the convolution of the dwell time (integrator low pass) with the time between samples. Increasing the dwell time reduces the cds frequency response at higher frequencies where spurious interference is going to be (10's to 100's of MHz).

So, lets spec out some areas of operation ... based on what we are likely to require (all assume a 1us reset pulse and 500ns of total delay / settling time) and using 2^n harmonics because it is so much easier (see the attached Excell chart for better understanding).

Low end of Torrent pixel acquisition Slow / low output CCDs - Pixel rates of between 20KPix and 100KPix with long dwell times of order 8us. Sync frequencies: VP33D_SYNC - 3rd, 7th, 15th V80A_SYNC - 7th, 15th V30A_SYNC - 1st, 3rd, 7th

Sweet spot operation of Torrent pixel acquisition Most common operation - Pixel rates between 125KPix and 300KPix with dwell times of order 2us VP33D_SYNC - 1st - with gaps V80A_SYNC - 3rd, 7th - with gaps V30A_SYNC - fundamental, f/2

High end of of Torrent pixel acquisition Special case & Infrared - Pixel rates between 300KPix and 500KPix with dwell times of order 1us. VP33D_SYNC - fundamental - with gaps V80A_SYNC - 1st - with gaps V30A_SYNC - f/2

Looking at this it is obvious that we indeed need to stretch the acceptable sync frequencies for the supplies that are synced to the V80A_SYNC and VP33D_SYNC signals to be able to cover the operational range of Torrent using this simple scheme ... However, if we cannot get the supplies to work well at the extended sync frequencies we can resort to using other harmonics of the pixel rate.

Now .. onto your idea ...

Yes it is a novel idea .. And I appreciate the elegance of it .. I assume you would create 'timeslots' in the sequencer that would be called for each clock division ? .. Just running the sequencer clock at 128 x the pixel rate wouldn't actually buy you anything except a loss of timing resolution. How would you reconcile the start and stopping of the sequencer with this scheme. I would have to be convinced a lot further by the argument (i.e. a better defined design) to accept it since it radically changes the paradigm of MONSOON in Torrent and, without offering any other benefits, only overcomes, to some extent, the problem of generating a power supply sync plan. Are you going to pursue it ? If so then lets talk so I can better understand the implications of the idea.

Cheers, Peter.

On Tue, 31 Mar 2009 16:16:01 -0400 "Peter Moore" <pmoore@noao.edu> wrote:

Sorry .. Here's the Excell spread sheet ... It's a bit rough though :-)

On Tue, 31 Mar 2009 14:45:46 -0700 David Sawyer <sawyer@noao.edu> wrote:

Hi Peter,

Comments below...

On Tue, 31 Mar 2009 16:14:29 -0400 "Peter Moore" <pmoore@noao.edu> wrote:

HiYa Dave,

So, lets spec out some areas of operation ... based on what we are likely to require (all assume a 1us reset pulse and 500ns of total delay / settling time) and using 2^n harmonics because it is so much easier (see the attached Excell chart for better understanding).


Good. Your spreadsheet looks just like mine so I must be doing something right.

Looking at this it is obvious that we indeed need to stretch the acceptable sync frequencies for the supplies that are synced to the V80A_SYNC and VP33D_SYNC signals to be able to cover the operational range of Torrent using this simple scheme ... However, if we cannot get the supplies to work well at the extended sync frequencies we can resort to using other harmonics of the pixel rate.


Okay, let's wait and see what Bob learns.

Now .. onto your idea ...

Yes it is a novel idea .. And I appreciate the elegance of it .. I assume you would create 'timeslots' in the sequencer that would be called for each clock division ? .. Just running the sequencer clock at 128 x the pixel rate wouldn't actually buy you anything except a loss of timing resolution. How would you reconcile the start and stopping of the sequencer with this scheme. I would have to be convinced a lot further by the argument (i.e. a better defined design) to accept it since it radically changes the paradigm of MONSOON in Torrent and, without offering any other benefits, only overcomes, to some extent, the problem of generating a power supply sync plan. Are you going to pursue it ? If so then lets talk so I can better understand the implications of the idea.


No, I'm not interested in changing the paradigm of MONSOON, or creating more work. It was just a spontaneous idea that I didn't really think through...

--Dave


On Wed, 01 Apr 2009 09:22:31 -0400 "Peter Moore" <pmoore@noao.edu> wrote:

Good Morning Dave,

+ Good. Your spreadsheet looks just like mine so I must be doing something right.

Excellent !! It is great to have a colleague who is thinking in engineering terms and calculating things out !!

BTW .. I was joking (JaJaJa) when I called you pushy ... Without doubt, I'm the pushy one around here JaJaJa :-)

Cheers, Peter.

On Thu, 02 Apr 2009 08:30:43 -0700 David Sawyer <sawyer@noao.edu> wrote:

Hi Peter,

Here's a couple of quick questions for your clarification:

What should the units be for the SyncDivider attribute value? Number of SysClk cycles?

What about the SyncMinFreq and SyncMaxFreq attributes? Currently I'm assuming they are in units of KHz and so I am dividing this value into the SysClk frequency (a constant) to convert to SysClk cycles for generation of the SyncClks.

Thanks, Dave

On Thu, 02 Apr 2009 12:24:25 -0400 "Peter Moore" <pmoore@noao.edu> wrote:

G'Day Dave, How's spring looking like in Tucson ??

+ What should the units be for the SyncDivider attribute value? Number of SysClk cycles?

In units of PsmSyncClk .. whatever that may be .. It could be the SysClk if the power supply control requires it, however, in an effort to reduce power consumption, the lower the frequency of this clock the better. Remember, the SyncDivider attribute is read only (since it should be calculated by the logic) and it is only available to monitor the operation of the ps control logic. As such it is an engineering unit that doesn't mean anything to anybody unless they understand what is going on in the ps control module.

+ What about the SyncMinFreq and SyncMaxFreq attributes? Currently I'm assuming they are in units of KHz and so I + am dividing this value into the SysClk frequency (a constant) to convert to SysClk cycles for generation of the +SyncClks.

Again, these are limits imposed at the engineering level. Be (very) careful about doing math (such as division that is not a power of two) in the logic. You will find that doing so will invoke resources on the FPGA fabric (e.g. DSP blocks) that could otherwise be used elsewhere for better results. In addition this will add (considerably) to the hardship of timing closure.

So, what units ... Well, since these limits should be used to constrain the logic involved in calculating the optimum divider value (i.e. SyncDivider attribute) then probably use just max and minimum divider values. I think you will find that is what is done in the sample logic I sent to you :-)

Remember one of the principle concepts of MONSOON .. If it needs intelligence; Let the PAN do it !

This means (among other things) that we work on the firmware in whatever units that we chose (i.e. raw binary values) - and we let the PAN do a conversion to something that is intelligible for use poor engineers to understand.

Let me know if this doesn't answer your questions ...

Cheers, Peter.

On Thu, 02 Apr 2009 09:47:43 -0700 David Sawyer <sawyer@noao.edu> wrote:

Okay, so I think I get it. So I'm guessing then that you have the Max and Min Freqs set as attributes instead of constants because these will be dependent on the value of PsmSysClk. I.e. if we change the PsmSysClk the we will have to change the min/max freq values (dividers) to keep the sync clks at required frequencies...?

--Dave

On Thu, 02 Apr 2009 12:53:08 -0400 "Peter Moore" <pmoore@noao.edu> wrote:

HiYa Dave,

Yup .. and more .. I drew them in as changeable attributes to remind me that the limits of the power supply needed to be established before I closed the door on the limits :-)

In the 'distributable' code release (to use Nicks terminology), I want these limits (and many others) to be constants so as to restrict the number of permutations in the system. That way we may have a manageable test method to be able to sleep at nights !

Cheers, Peter.

On Fri, 03 Apr 2009 13:14:10 -0700 

"David Sawyer" <sawyer@noao.edu> wrote:

Hi Peter, Are there any critical timing requirements between the sync pulses and the sync clocks? E.g. does the rising edge of the sync pulse have to coincide with the rising edge of the sync clock? Thanks, Dave

HiYa Dave,

I would expect it would since this should be built using synchronous logic :-)

However, no .. there is no requirement to make the sync pulses coincide with the sync clock, likewise, you do not need to make the sync pulses coincident with the SeqEnblReg_PsmSyncPulseBit (although the code I sent to you does !) as long as the delay is deterministic i.e. stable ... BUT ... since all sync pulses are derived from a common clock source, the four sync pulses themselves (V33D_SYNC, V80A_SYNC, V30A_SYNC, LOGIC_SYNC) must be in a constant phase relationship. If we make these pulses coincident then we face a (massive ?) current spike at that exact instant when all the switch mode supplies turn on together.

The best practice (I'm guessing here) would be to have the four sync pulses spaced out such that they fall into a 90 Deg. phase shift at the highest sync frequency (i.e. the V80A_SYNC). This would spread the switching current out over one period of this supply.

My suggestion is to make, for the time being, all sync pulses coincident (easiest to implement). That leaves us some slack up our sleeves to use sync pulse phasing to achieve lower noise by reducing the energy of the simultaneous switching.

Hope this helps ... Peter.

Return to top of Firmware Topics#top

Retrieved from "http://www.noao.edu/wiki/index.php/Firmware_Topics"
Personal tools