DRAFT:

Overview

The Philips (now Xilinx) PZ3128S15BE programmable logic device (PLD) is programmed by download cable. The PLD retains its configuration until erased or reprogrammed. The PLD participates in downloading the configuration to the FPGA.  The PLD also provides some address decoding functionality allowing the host CPU to communicate with the FPGA through the standard PC/104 bus connector, a 64 pin stack-through connector along the long edge of the board.  This document describes the allocation of address space for the PLD and FPGA related functions.

The 50,000 gate field programmable gate array (Altera EPF10K50EQC-208), once configured, performs simple and complex logic functions necessary to facilitate communication between the host cpu and the digital optical module connected to the test board.  Simple logic and complex state machines are implemented in the FPGA design. This document describes the user interface.
 

Register space of the PLD and the FPGA

The Base address mentioned above must be added to the addresses in the table to read/write the data indicated in the right two columns of the table.

For example, we define board 3  to have n =  3.  To read the time-tick fifo for board 3, we calculate the actual data address as indicated:

The Test-Board PLD

FPGA Write Registers Definitions

DO_CLK_SYNC causes the addressed test board to impose a reset function on a stack of test boards connected together the rough the bus lines adjacent to the FPGA.  The operation causes all boards to enter a state where they 'listen' for the next one pulse per second clock tick, and on the subsequent rising clock cycle, all latch a preprogrammed number into the clock counters.  The  latency of the clock setting operation suggests loading the number 2 into all clocks, rather than zero. ( The choice is arbitrary.  The constant is a compile time setting which is easily changed.)

The external RS-232, the Maxim MAX3524, shuttles serial data between the RJ-45 connector on the test-board, and the RXD and TXD inputs to the FPGA design.  A terminal server connects to the RJ-45 connector to provide "IP socket" connectivity to an applications program.  The firmware UART is code inside the FPGA  serializes data written to FIFO from the PC-104 bus, for transmission over the cable to the DOM, and likewise, signaling from the DOM is deserialized and loaded into a FIFO for readout over the PC-104 bus.

The slow serial protocol, at least at this stage of testing (Fall/Winter 2000) uses 38 kbps ASCII serial signaling over the cable. A novel scheme is implemented to maintain line balance on the twisted pair. The scheme developed by Jozsef Ludvig, uses a simulated d' (delta prime) waveform. The waveform generator holds the output at mid scale except during 0-to-1 and 1-to-0 transitions of the serial signal. If serial the waveform goes from 0-to-1, the generator sends a positive rectangular waveform for a few cycles, followed by a negative rectangular waveform for a few cycles followed by a return to mid scale.  If the serial waveform transits from 1-to-0, the waveform generator simply inverts the previous waveform, simulating (-d').  The amplitudes and durations are tweaked in the firmware design to introduce the minimum disruption of balance in the lines.

Before the introduction of the PC-104 single board computer, a terminal server provided the needed connectivity to user programs on other nodes by means of TCP/IP socket interfaces.

The firmware UART built into the design emulates the terminal server functionality through FIFOs in the FPGA.  Characters written to the FIFO cause the transmitter to be activated.  Each character read as a parallel data byte is serialized by the FIFO, and applied to the waveform generator described above.  A register bit is asserted if the FIFO is full, in which case, the calling program will have to buffer additional data, or signal a hardware failure.  The FIFO has sufficient depth to accommodate several packets.  When the UART receives characters from the DOM, they are placed in a receive FIFO.  A register bit is set when the FIFO is not empty, and deasserted after the last word is read from the FIFO.

ControlReg1[7..0]
 

Configuration Register
Bit 0	TICK_WIDTH0	3 bit Binary field encoding the number of cycles of timing tick.  ^b000 means one tick. ^b001 means 2 ticks, and so forth,
Bit 1	TICK_WIDTH1
Bit 2	TICK_WIDTH2
Bit 3	START_TIME_TICK	Generate a time-tick cycle and store time of generation. (Executed on rising edge. Must be cleared after use.)
Bit 4	WAIT_FOR_TIME_TICK	Initiate time-tick capture cycle
Bit 5	TIME_TICK_SAMPLE_FLIP	Complement the bits of the sample corresponding to the time tick.
Bit 6	TIME_TICK_TRIG_INV	Invert the trigger sense with respect to the comm trigger.
Bit 7

Time-tick waveforms differ slightly from RS-232 waveforms.  Data  waveform rising edges begin with a high output from the DAC for a fixed number of cycles, followed by a low from the DAC for the same number of cycles, followed by a return a mid level. The data waveform falling edge begins with a low output from the DAC followed by a high from the DAC followed by a return to the mid level.  The time-tick waveform consists of repetitions of the high-low output. The number of repetitions is controlled by the lowest three bits of control register 0.  The range is from one to eight cycles, inclusive.

The DAC input data for the time tick appears at the DAC inputs several system clock cycles after the START_TIME_TICK bit goes high.  The system clock causes the value set by the data lines to appear on the DAC analog output a certain propagation delay after the next rising edge of the system clock.  The system time present at the latch at that same transition is saved for read-out later.

ControlReg2[7..0]

ControlReg3[7..0]

The DOM power is b

ControlReg5[7..0]  MAY BE USED BY KERNEL MODE

Control register 5 is reserved for access by system software or for debugging by experts.
If the receive FIFO fills completely, an over-run condition is signaled.  If an overrun occurs, the FIFO contents should be purged since they are unreliable. This bit is separated from the access control register to allow data path state recovery without disrupting driver control functionality.

ControlReg7[7..0]

Control Register 7 is reserved for access by system software or for debugging by experts familiar with the operation of the driver code.DATA_XCV_VIA_PC_BUS and
the INT_MASK_4 bit to gain transmit and receive access to the corresponding test board.  When the driver software breaks the connection it clears all bits in this register. As of September 26, only INT_MASK_4 is wired in the FPGA to an interrupt.  For the PC-104 CPU, the interrupt is IRQ3.  Some other CPUs may require a different IRQ.

The INT_MASK bits are over-all in their scope.  If the mask bit is clear, neither the transmit FIFO nor the receive FIFO  interrupt outputs will cause an interrupt to be generated. When enabled, the receive FIFO interrupt is always functional.  The transmit FIFO interrupt may be or'ed in with the receive FIFO interrupt only when the TX_FIFO_INTERRUPT_ENABLE bit is also set.  The depth of the transmit FIFO is 256 bytes.  Short transmissions will not require the use of the transmit interrupt.  Long transmissions, like file downloads, may require the use of the TX_FIFO_INTERRUPT_ENABLE to achieve unbroken data transmission.

FPGA Read Register Definitions

Bit 0 and Bit 1 interrupt bits are set the FIFO modules are generating requests to the interrupt controller module in the FPGA.  The interrupts have to be enabled at the control module level for the CPU to be alerted to the interrupt request.  Read from the set of registers containing the local time has an interaction with the capture of the local time from the 50 bit local clock counter.
The time (eight registers worth) is captured when a read is made from the lowest byte of the set of eight registers.

StatusReg1[7..0]

Status Register1
Bit 0	Reserved	Undefined
Bit 1	Reserved	Undefined
Bit 2	OVRERR_CTL	Data Overrun on control packet receive FIFO
Bit 3	OVRERR_TRG	Data Overrun on trigger packet receive FIFO
Bit 4	TIME_TICK_PRETRIG_FAULT	Pretrigger not full when time-tick received
Bit 5	TIME_TICK_FIFO_EMPTY
Bit 6	TIME_TICK_FIFO_FULL
Bit 7	SLOW_CONTROL_VIA_ISA	Internal UART Transmit enabled

The One Second Tick time is updated whenever a 1 pps pulse arrives from the GPS clock at the test-board. If the test-board clock is being reset the results are unpredictable.

The top level schematic on August 9 2001 looks like this.  The design is subject to change without notice as the experiment evolves.
 

Address Block Status Registers

Address Block StatusReg0[7..0]

Address Block Interupt Status Register
Bit 0	INT0_CLR	Board ID 0 Clear
Bit 1	INT1_CLR	Board ID 1 Clear
Bit 2	INT2_CLR	Board ID 2 Clear
Bit 3	INT3_CLR	Board ID 3 Clear
Bit 4	INT4_CLR	Board ID 4 Clear
Bit 5	INT5_CLR	Board ID 5 Clear
Bit 6	INT6_CLR	Board ID 6 Clear
Bit 7	INT7_CLR	Board ID 7 Clear

The bits in Block Interrupt Status Register constitute the set of interrupt status bits for eight boards in the memory block.  Each board in the system, 0 through 7, owns a bit position in the register based on its ID number.  e.g.. the status of the interrupt bit of board 4 appears in bit position 4. Furthermore, each board indicates the presence of an interrupt by pulling its bit low.  Thus, boards which are not present on the bus appear to be clear.  Boards must have the appropriate interrupt enable bit set (see also register 7) for the bit pull-down to occur.  On the surface this choice might seem odd, but there is a reason behind it.  The CPU board has pulls each data line high through a resistor.  Peripheral boards are expected to drive the line low or high when addressed.  If the sense of the datum were opposite, then boards which were not present might be mistaken for boards with data.

Address Block ID Register[7..0]

Address Block ID Register
Bit 0	EXIST0	Board 0 Absent
It may be the case that the design will no longer compile because all the routing resources are used up in a particular area.  Then it's time for forensics.  Examine the map that shows where all the resources are placed and routed. If a particularly dense place is identified, that is likely where the problem is.  Find out what is there, and comtemplate alternate ways of implementing the logic.  For instance, instead of one wide multiplexer, implement a two deep tree of multiplexers for data output.  Also, usage of carry and cascade chains can have an impact on the design. It could also be the case that software issues will force changes upon the API. If either of the above tacks are taken, care will have to be taken to make sure that the right versions of the DAQ software match up with the right versions of the the firmware.  Furthermore, modifications to the DAQ may break test programs. Notes on the evolution of the design may be important for sorting out conflicts that arise in the future. See API Change History Developers of this API and the associated firmware are encouraged to record changes and archive the ENTIRE package (surface DAQ firmware, DOM firmware and all associated libraries)  on a regular basis. Access to the API documents may be obtained from Gerald Przybylski, Lawrence Berkeley National Lab,