CDF/DOC/TRACKING/CDFR/6626August 7, 2003

The PCI Test Stand (PTS) for the Run 2b Silicon Upgrade

Catalin Ciobanu and Tom Junk

University of Illinois at Urbana-Champaign

Abstract

A system for testing chips, hybrids and staves for the Run 2b silicon upgrade is described. The test stand consists of a commodity computer, general-purpose test hardware, and specialized firmware, software, and cable adapters.

Section 1: Introduction

The upgrade of the silicon vertex detector for Run 2b operation requires the successful production, testing, and installation of 4464 SVX4 chips mounted on 1152 hybrids mounted on 192 staves. It is anticipated that the delivered instantaneous luminosity during Run 2b will be significantly higher than that delivered during the first two years of Run 2a. To maximize the success of the upgraded silicon detector, each component must work properly after installation, with a minimum of commissioning time. In order to ensure that the detector works reliably before the beam arrives, each component must be tested at each stage of assembly.

The production process for the DAQ components of the silicon detector upgrade involves manufacturing SVX4 chips by an outside contractor and mounting the SVX4 chips on BeO hybrid boards. These hybrids are tested at LBL and then sent to UC Davis for burning in. The burning-in process consists of running the hybrids for three days in order to screen for parts that fail early. The hybrids are then to be shipped to Fermilab, where they are tested again, mounted on modules with silicon sensors. The modules are then mounted on staves, which make up the detector. A mini-portcard is attached to the end, connecting to the six hybrids on a stave via two bus cables running the length of the

1

stave, one on each side. At each step, a number of possible failures may happen. Wirebonds may have shorts or opens, or parts may be damaged due to electrostatic discharge or may be damaged mechanically, or dust may settle on the components. The expected yields are high, and enough spares will be produced at each stage so that partially non-functional DAQ components need not be assembled into the final detector.

The upgraded detector is designed to be read out with many of the same DAQ components which already exist to read out the current SVX detector, from the FIB on upstream. The FTM has been redesigned for the Run 2b silicon upgrade to accommodate the copper signal transmission wires instead of the optical data fibers used for the Run 2a detector. A DAQ chain is available at FCC, made out of spare parts for the Run 2a silicon, which is used to verify that the new detector components work with the old DAQ hardware, and which is used to measure the performance of the prototype detector components. It is desired, however, to have several test stands available, at FCC, at SiDet, and at the institutions, for testing and characterization of the detector components, both to speed up the testing procedure and to enable more tests to be done on the components more often.

BTeV has designed two boards, the PCI Test Adapter (PTA) [1], and the Programmable Mezzanine Card (PMC) [3], which plug inside a PC with a PCI bus. These adapter boards can be configured to test many different kinds of hardware. The FPGA’s can be programmed to send any desired control signal patterns to the tested hardware and collect the data that return. The host computer then can easily analyze the data that return, to evaluate the functionality and performance of the hardware that is tested. This document describes a system made with these adapter boards to test SVX4 chips singly, mounted on hybrids, and entire staves.

2

Section 2: Hardware Configuration

The flexibility of the FPGA outputs on the PMC simplifies the hardware needed to perform the tests. Hardware external to the PTA/PMC boards needs only to supply power to the tested electronics, to supply a precisely controlled VCAL voltage, and to connect all of the control and signal lines. The target connectors are a 60-pin ribbon cable header on the chip test carrier board, and the 50-pin Samtec header on the hybrid test board (the “little green board”). The pinouts of these target boards are shown in Figure 2. The pinouts from the PMC are shown in Figure 3. An adapter board has been designed to route the signals and power, and provide VCAL via a DAC. Documentation for it is available at http://web.hep.uiuc.edu/Engin/CDF/PMC/index.htm.

The adapter board has two headers for connecting with 50-pin Samtec connectors which connect to Samtec headers A and B on the PMC. It is important to note that the convention used on the PMC of which pin on the Samtec header is pin 1 is opposite to Samtec’s convention. The Samtec headers and connectors are keyed, and so special reversing cables are needed to connect the PMC with hardware, such as the U of Illinois chip/hybrid adapter board, with the PMC. Adapter boards are supplied by us with a pair of cables appropriately made and labeled. Samtec headers C and D are used to connect directly to the JPC interface for testing electronics through the JPC + MPC DAQ chain. Details of the pin assignments on the PMC headers are given in the Section 3.

Power is provided by external supplies, and routed onto the board separately for two AVDD lines, two AGND lines, two DVDD lines, two DGND lines, a DAC supply line, its ground, and a reference voltage line for the DAC, and its ground. All supply voltages should be 2.5 Volts except for the DAC supply line, which is 5 Volts; the reference voltage for the DAC should be set so that the maximum voltage output by the DAC does not exceed 3.3 Volts. The DAC has 12-bit precision, but only the top 8 bits are used. The DAC has an interesting feature when its power supply is turned on: it outputs a voltage of about 50% of its reference voltage, regardless of the state of its input lines (often set to zero upon power-up of the rest of the system). The DAC has a double-buffered input, and will not change state until a different set of control bits is sent to it. Therefore, to fully reset the state of the DAC after power-up, the DAC control bits (see register 0x34’s description in Section 3.4).

The adapter board is designed to route signals either to a single-chip carrier board, using a 60-pin standard ribbon cable header, or to a hybrid, attached to a “little green board” with a Samtec header. The control signals are simply wired up to both of the headers on the adapter board, and the data readback lines from both headers are connected to each other and to the readback pins on the PMC. Therefore, it is possible to use only one of the two test headers on the adapter board at a time. When a hybrid is plugged into it, the chip test header should be left unplugged, and when a chip is being tested, the hybrid header should be left empty.

3

Figure 1: Hardware configuration for testing single chips on single chip test boards, and also hybrids.

4

PTA PMC

AdapterBoard

ReversingRibboncables withSamtecConnectors

PCI

Bus

Chip TestBoard

Hybrid testBoard

Connectors forGuilherme’s JPCadapter board

Power Supplies

A

B

C D

Figure 2: Pin assignments on the chip test board (left) and the hybrid test board (right). From http://www-cdf.lbl.gov/users/mweber/svx4/.

5

Section 3: PTA and PMC Firmware

Subsection 3.1: PTA Firmware

The PCI test adapter [1] has an Altera APEX EP20K FPGA which provides the interface to the PCI bus interface, the ZBT SRAM banks on the PTA, and the PMC daughter card. For the PTS test stand, firmware developed by the Milano BTeV group [2] is used for the PTA. This firmware provides many useful functions for the PTS test stand. It allows for the reading and writing of registers in the PMC, the reading and writing of the two memory banks on the PTA, and the collection of data sent from the PMC to the PTA. The PTS system currently runs on PTA firmware version B3.6.

Reading and writing registers on the PMC is used by the PTS system in order to load control pattern data into the PMC RAM, and also to tell the PMC to start sequencing the control bits to the I/O lines. It also allows for setting configurable options of the PMC firmware, such as clock selection and which I/O lines to use.

Reading the contents of the two ZBT SRAM banks is how data are transferred from the PTA to the data acquisition program running on the host computer. This memory may also be written to under control from the host computer, or alternatively from the PMC daughter card. The host computer may write and read words in the memory in order to test the integrity of the memory banks.

When a memory bank is configured to be written from the PMC, data arrive on a unidirectional 32-bit bus from the PMC, along with a separate clock signal and a signal which indicates that the data are valid. The 32 bits are latched in a FIFO on the rising edges of the clock line when the data valid line is asserted. The data are stored in the SRAM bank pointed to by the configuration register selecting which one, and the memory address pointer is automatically incremented. The host computer is not allowed to write to the SRAM bank chosen for PMC writing. The PTA firmware was written with the assumption that the data clock runs all the time, even when the signal indicating valid data is not asserted, which is not the case with the PTS system when used to test the SVX4 chips. Two words therefore do not make it all the way through the PTA’s FIFO into RAM until the next readout.

The PTA firmware also offers several interesting features which are not yet used by the PTS test stand but which may be very useful in the future. When one memory bank fills, it is possible to configure the PTA firmware to switch over automatically to start filling the other bank. It is also possible to read one bank with the computer while writing to the other one with the PMC. In the very controlled setting of the tests done by the PTS, neither of these features is used. But with an extension to use an external trigger, these may become very valuable.

6

Subsection 3.2 PTA Configuration Registers

This configuration register data has been made available from Lorenzo Uplegger, author of the BTeV PTA firmware, and is included here for completeness [2].

BAR2, Offset 0x00 Read/WriteMezzanine Register.

BAR2, Offset 0x04 Read/WriteCOMMAND ENABLE COMMAND ENABLE

0 1 2 3

BAR3 DIRECTION EN BAR3 DIRECTION

RESET BAR3 ADDRESS

EN RESET BAR3 ADDRESS

4 5 6 7

BAR4 DIRECTION EN BAR4 DIRECTION

RESET BAR4 ADDRESS

EN RESET BAR4 ADDRESS

8 9 10 11SET INTERRUPT

BAR3EN SET

INTERRUPT BAR3SET INTERRUPT

BAR4EN SET

INTERRUPT BAR4

12 13 14 15SOFTWARE

TOGGLEEN SOFTWARE

TOGGLESELECT

FAKE/MEZZANINEEN SELECT

FAKE/MEZZANINE

16 17 18 19TOGGLE LIMIT

ENABLEEN TOGGLE LIMIT

ENABLETOGGLE TIMER

ENABLEEN TOGGLE

TIMER ENABLE

20 21 22 23FAKE

CORE TALKINGEN FAKE

CORE TALKINGRESET

FAKE COUNTEREN RESET

FAKE COUNTER

24 25 26 27RESET DATA LOST

COUNTERSEN DATA LOST

COUNTERSRESET TIMER

COUNTEREN RESET TIMER

COUNTER

7

28 29 30 31RESET

DATA COUNTEREN RESET

DATA COUNTER RESET FIFO EN RESET FIFO

Command RegisterThis register is used to send commands to the FPGA. Every command is independent from the others and must be enabled using the correspondent Enable Bit.Example:If we want to reset the BAR3 address counter the command is Bit 2. To enable this command we must also set to 1 Bit 3 (write bar2 offset 4 0xc).Multiple command can be sent enabling the correspondent Bits.Example:If we want to reset the BAR3 address counter and set BAR3 Direction to 1 the commands are Bit 2 and Bit 0. To enable those commands we must also set to 1 Bit 3 and Bit 1 (write bar2 offset 4 0xf).

Bit0 - (Enable Bit1) – BAR3 DIRECTION: Memory BAR3 Direction

This Bit is used to select who has control of memory BAR3. If set (one). The mezzanine card has control of BAR3 and it’s inaccessible by software. If cleared (zero) the PTA has control of BAR3 and the memory can be accessed from software.

Bit2 - (Enable Bit3) – BAR3 COUNTER CLEAR: BAR3 Address Counter Reset

This bit resets the address pointer register for BAR3. If set (one), the address counter is reset. Once the counter is reset the Bit is cleared automatically, and the counter will operate normally.

Bit4 - (Enable Bit5) – BAR4 DIRECTION: Memory BAR4 Direction

This Bit is used to select who has control of memory BAR4. If set (one). The mezzanine card has control of BAR4 and it’s inaccessible by software. If cleared (zero) the PTA has control of BAR4 and the memory can be accessed from software.

Bit6 - (Enable Bit7) – BAR4 COUNTER CLEAR: BAR4 Address Counter Reset

This bit resets the address pointer register for BAR4. If set (one), the address counter is reset. Once the counter is reset the Bit is cleared automatically, and the counter will operate normally.

Bit8 - (Enable Bit9) – SET INTERRUPT BAR3

This Bit is used to set or unset the interrupt generated when BAR3 reaches the limit.

8

Bit10 - (Enable Bit11) – SET INTERRUPT BAR4

This Bit is used to set or unset the interrupt generated when BAR3 reaches the limit.

Bit12 - (Enable Bit13) – SOFTWARE TOGGLE

This Bit is used to force a memory toggle even if the limit is not already reached. This memory swap occurs (as the automatic memory swap) only if the other Memory counter is cleared.

Bit14 - (Enable Bit15) – SELECT FAKE/MEZZANINE: Enable Test Mode

If set (one), data are generated from the fake data counter and Bit 20 is used to enable the fake Core Talking. If cleared (zero) data are sent to the memory through the JN1/2 connectors.

Bit16 - (Enable Bit17) – TOGGLE LIMIT ENABLE

This bit must be set to one to allow the automatic switch from one memory bank to the other when the limit is reached.

Bit18 - (Enable Bit19) – TOGGLE TIMER ENABLE

This bit must be set to one to allow the automatic switch from one memory bank to the other when the timer reaches the timer limit set.

Bit20 - (Enable Bit21) – FAKE CORE TALKING

If set (one) the fake chip is sending data, i.e. the fake data counter starts and if the mezzanine has control of one memory bank, BAR3DIR=1 or BAR4DIR=1, data flow in that memory bank. If cleared (zero) fake chip doesn’t send any data, i.e. the fake data counter is stopped.

Bit22 - (Enable Bit23) – RESET FAKE COUNTER: FAKE Counter Reset

This bit resets the fake data counter. If set (one), the counter is reset. Once the counter is reset the Bit is cleared automatically, and the counter will operate normally.

Bit24 - (Enable Bit25) – RESET DATA LOST COUNTER: Data Lost Counter Reset

This bit resets the data lost counters (the FIFO data lost and the memory data lost counters). If set (one), the counters are reset. Once the counters are reset the Bit is cleared automatically, and the counters will operate normally.

9

Bit26 - (Enable Bit27) – RESET TIMER COUNTER: Timer Counter Reset

This bit resets the timer counter. If set (one), the timer counter is reset. Once the counter is reset the Bit is cleared automatically, and the counter will operate normally.

Bit28 - (Enable Bit29) – RESET DATA COUNTER: Data Counter Reset

This bit resets the data counter. If set (one), the counter is reset. Once the counter is reset the Bit is cleared automatically, and the counter will operate normally.

Bit30 - (Enable Bit31) – RESET FIFO: FIFO Reset

This bit resets the FIFO. If set (one), the FIFO is reset.

BAR2, Offset 0x08 Read0 1 2 3

BAR3 DIRECTION BAR4 DIRECTION INTERRUPT BAR3 INTERRUPT BAR4

4 5 6 7BAR3 EMPTY BAR3 FULL BAR3 HALF FULL BAR3 LIMIT

8 9 10 11BAR4 EMPTY BAR4 FULL BAR4 HALF FULL BAR4 LIMIT

12 13 14 15TOGGLE LIMIT

ENABLEDTOGGLE TIMER

ENABLEDSELECT

FAKE/MEZZANINEFAKE CORE

TALKING

16 17 18:19 20:31

FIFO EMPTY FIFO FULL X FIRMWARE VERSION

Status RegisterThis register is used to control the status of the FPGA.

Bit0 – BAR3 DIRECTION: Memory BAR3 Direction

If set (one). The mezzanine card has control of BAR3 and it’s inaccessible by software. If cleared (zero) the PTA has control of BAR3 and the memory can be accessed from software.

Bit1 – BAR4 DIRECTION: Memory BAR4 Direction

10

If set (one). The mezzanine card has control of BAR4 and it’s inaccessible by software. If cleared (zero) the PTA has control of BAR4 and the memory can be accessed from software.

Bit2 – INTERRUPT BAR3: BAR3 has dataAfter a BAR3 toggle event an interrupt is sent and this bit is set (one) to indicate that BAR3 has data and can be read.

Bit3 – INTERRUPT BAR4: BAR4 has dataAfter a BAR4 toggle event an interrupt is sent and this bit is set (one) to indicate that BAR4 has data and can be read.

Bit4 – BAR3 EMPTY: Memory BAR3 EmptyThis bit is set (one) when the BAR3 address pointer is at location 0x0. Offset0x04 Bit2 is used to reset the BAR3 address pointer.

Bit5 – BAR3 FULL: Memory BAR3 FullThis Bit is set (one) when the BAR3 address pointer hits the last location in memory.

Bit6 – BAR3 HALF FULL: Memory BAR3 Half FullThis Bit is set (one) when the BAR3 address pointer crosses the half point in the memory.

Bit7 – BAR3 LIMIT: Memory BAR3 LimitThis bit is set (one) when the programmable threshold in the BAR3 limit register has been reached.

Bit8 – BAR4 EMPTY: Memory BAR4 EmptyThis bit is set (one) when the BAR4 address pointer is at location 0x0. Offset0x04 Bit6 is used to reset the BAR4 address pointer.

Bit9 – BAR4 FULL: Memory BAR4 FullThis Bit is set (one) when the BAR4 address pointer hits the last location in memory.

Bit10 – BAR4 HALF FULL: Memory BAR4 Half FullThis Bit is set (one) when the BAR4 address pointer crosses the half point in the memory.

Bit11 – BAR4 LIMIT: Memory BAR4 LimitThis bit is set (one) when the programmable threshold in the BAR4 limit register has been reached.

Bit12 – TOGGLE LIMIT ENABLEDThis bit indicates if it’s possible to have a memory limit toggle.

Bit13 – TOGGLE TIMER ENABLEDThis bit indicates if it’s possible to have a memory timer toggle.

11

Bit14 – SELECT FAKE/MEZZANINEThis bit indicates if the data flow comes from the fake counter (one) or from the mezzanine (zero = default).

Bit15 – FAKE CORE TALKINGThis bit indicates if the fake core talking is on.

Bit16 – FIFO EMPTYThis bit is set when the FIFO is empty.

Bit17 – FIFO FULLThis bit is set when the FIFO is full.

Bit18-19 – XUndefined.

Bit20…31 – FIRMWARE VERSIONThe first byte indicates if the firmware works with the old PTA releases (A) or with the new ones (B).

BAR2, Offset 0x0C Read

31:0BAR3 Address Pointer

BAR3 Address PointerThis register is an address pointer to BAR3 of the ZBT SRAM. The mezzanine card will use this pointer for its reads and writes from BAR3. The address points the first free location of the memory.

BAR2, Offset 0x10 Read

31:0BAR4 Address Pointer

BAR4 Address PointerThis register is an address pointer to BAR4 of the ZBT SRAM. The mezzanine card will use this pointer for its reads and writes from BAR4. The address points the first free location of the memory.

12

BAR2, Offset 0x14 Read/Write

31:0BAR3 Limit

BAR3 Limit Register

This Register is used as a programmable threshold that when crossed will set the BAR3 LIMIT bit in the ZBT SSRAM Status register. If a threshold higher than the memory physical limit is set this register is set to the memory physical limit. Only multiple numbers of 4 can be set because the first 2 bits are never considered. The maximum limit is 0xFF800, because the last 512 address are left for the initialisation pattern to be stored.

BAR2, Offset 0x18 Read/Write

31:0BAR4 Limit

BAR4 Limit Register

This Register is used as a programmable threshold that when crossed will set the BAR4 LIMIT bit in the ZBT SSRAM Status register. If a threshold higher than the memory physical limit is set this register is set to the memory physical limit. Only multiple numbers of 4 can be set because the first 2 bits are never considered. The maximum limit is 0xFF800, because the last 512 address are left for the read back pattern to be stored.

BAR2, Offset 0x1C Read/Write31:0

Timer Set

Timer Set Register (1-1,000,000)This register is used to set the time in millisecond after which a memory bank, having at least 1 data, switches automatically without waiting to fill the memory bank to the limit.

BAR2, Offset 0x20 Read31:0

Timer Counter

Timer Counter Register This register counts the milliseconds passed after the last memory switch. It can be reset with the command bit 26.

13

BAR2, Offset 0x24 Read/Write31:0

Fake data rate division factor

Fake data rate division factor Register (1-2^32-1)This register is used to divide the maximum fake data rate. The default rate (division = 1) is 132 Mbyte/sec (33 Mhz) .

BAR2, Offset 0x28 Read31:0

Number of lost data by the memories

Number of lost data by the memoriesThis register count the data lost by the two banks of memory. If this counter starts, it means that the data rate is too high to be read from the PCI. If the PTA cannot switch on the other memory bank and the bank in which the data are being stored is full it starts counting.

BAR2, Offset 0x2C Read31:0

Number of lost data by the FIFO

Number of lost data by the FIFOThis register count the data lost by the FIFO. If this counter starts, it means that the data rate from the mezzanine is greater than 33MHz for more than the 2048 data that can be stored in the FIFO.

BAR2, Offset 0x30 Read31:0

Number of data in the FIFO

Number of data in the FIFOThis register shows the number of data present in the FIFO.

BAR2, Offset 0x34 Read31:0

Data rate

Data rateThis register shows the number of Readout Clock cycles between two data coming from the mezzanine.

BAR2, Offset 0x38 & 0x3C Read

14

31:0Data counter

Data counterThis register counts the number of data coming from the mezzanine. It’s a 64 bits counter. Offset 0x38 shows the first 32 bits and Offset 0x3C shows the last 32 bits.

Subsection 3.3: PMC Firmware

While the PTA firmware provides a generic interface to the PCI bus and the RAM banks, and therefore can be used for many applications of the PTA/PMC hardware without modification, the PMC firmware must be specifically written for the application. The PMC has a Xilinx Virtex II 1000 FG456 FPGA [3]. The PMC firmware is designed to be used to test SVX4 chips singly, on hybrids, or on staves. The firmware is designed to make the PTA/PMC hardware combination function similarly to the Berkeley pattern board system [4]. This design choice was made in order to speed the development and debugging of valid readout control signal sequences, as experience is gained with the SVX4 chip. Additional features, such as a larger pattern memory, larger data readback buffer, OBDV data synchronization, and single-word control-line access allow greater flexibility in the PTS system. The firmware must also configure the Xilinx SelectIO ports for use with the SVX4 chips directly, as well as through the Junction Port Card Interface [5].

The PMC firmware used for the PTS test stand is version 14. This version can be identified with the programmable green LED’s on the PMC card. Three will be on, three will be off, and two on one end will blink. One of the blinking LED’s blinks at the 50 MHz PMC clock, divided by 224. The other blinking LED blinks at the selected clock rate divided by 224.

The PMC firmware allows connection with either a chip/hybrid adapter board [6], or the Junction Port Card prototype [5]. PMC Samtec headers A and B are used for the chip/hybrid adapter board, while PMC Samtec headers C and D are used for the Junction Port Card interface. Samtecs A and D are used to send control signals, while Samtecs B and C have the bus lines and PRI_OUT on them. The reason for this assignment is that the PMC by default has 100 termination resistors soldered between paired input lines on the B and C Samtecs, and these termination resistors are needed to prevent reflections on the receiving end of the signals. Most of the control signals for the chip and hybrid are single-ended 2.5 V signals, while the return data are differential 2.5 V signals (LVDS). Some of the lines are bidirectional, sending control signals during acquire and digitize, and reading data during readout. The Xilinx Virtex II SelectIO resources are capable of handling these signals with no further adapter electronics.

Control signals can be sent to the tested hardware in one of two ways. They can be loaded into PMC pattern RAM and then sequenced out, or they can be sent out one word at a time, via writing to Registers 0x00 and 0x08, whose bits are connected to the

15

output ports. Register 0x14 contains a bit which selects between pattern output from memory and Registers 0x00 and 0x08 for control of the output ports. Register 0x04 always contains the state of the readable bus lines, PRI_OUT and OBDV from the tested hardware. During sequencing, the values change too fast to be read via reads of the register. Instead, during sequencing, data are sent to the PTA for storage in ZBT SRAM banks. The control signals are always sent on both sets of Samtec headers simultaneously. The data can be read back only from one of them – either the adapter board or the JPC interface, but not both simultaneously. A bit in register 0x14 selects which set of Samtecs from which to read the data.

The data are stored in flip-flops on each edge of OBDV using the Xilinx Virtex II’s Double Data Rate (DDR) feature. A delayed version of OBDV is first obtained by running the signal to a distant part of the FPGA, and then distributed on a low-skew clock network, so that each bus line’s DDR input gets the edges at the same time as all of the others. The delayed edges of OBDV then allow the setup times of the input flip-flops to be satisfied by data that have been stable for the time that OBDV has been delayed. It is important to use OBDV as the data synchronization clock instead of a clock generated within the testing hardware, as data words come back 20 ns apart, and cable lengths and electronic delays can easily de-synchronize the data acquisition. When testing a long stave, different cable delays exist for each hybrid, shrinking the size of the usable timing window unless OBDV is used to synchronize the data.

The pattern data is stored in the Xilinx FPGA’s SelectRAM blocks. 16,384 words, one word for each pattern clock cycle, are allocated for this purpose. More memory exists on the FPGA, but it is distributed around the edges of the chip (the memory that is used is near the center of the chip). Internal delays are blamed for glitches that are observed when memory on the periphery of the FPGA is used instead of the centrally-located memory. Future development may allow the use the additional memory at the speeds required, although the current memory size is adequate for a full stave to be read out twice, which is necessary for deadtimeless studies.

Each pattern clock cycle corresponds to a half of a BECLK cycle during readout (and an entire BECLK cycle during digitization). A full FECLK cycle takes 7 pattern cycles, which has a period of 140 ns using a 50 MHz clock (the clock is adjustable).

The pattern data are loaded into memory with the following procedure. The memory address in which the data are to be stored is loaded into PMC Register 0x0C. The data bits are loaded into PMC register 0x10 and bits 0 and 1 of Register 0x30. Then bit 0 in Register 0x14 is set to one. This last operation tells the PMC to store the data in pattern RAM. Bit 0 in register 0x14 is automatically cleared once the memory write is complete (the memory write takes less time than a read of this register across the PCI bus). The clock speed must be set to 50 MHz in order to store data properly in pattern RAM. The clock speed may be set with register 0x38. The pattern data may be verified by writing the memory address in register 0x0C and reading back the memory contents in register 0x28 and bits 2 and 3 of register 0x30.

16

To start the pattern going, the total pattern length (the address of the last word in pattern memory) should be loaded in register 0x24 and the memory location at which to start the pattern (usually location zero) should be loaded in register 0x0C. Then bits 1 and 2 should be set in register 0x14. These select the memory pattern as the source for the I/O pins, and start the pattern going. When the pattern is done being sequenced out (when the memory address reaches the last word stored in memory), the contents of registers 0x00 and 0x08 are again sent on the I/O pins, and the memory address is set to zero.

The current PMC firmware is available at

http://www.hep.uiuc.edu/home/trj/pts/index.html

Subsection 3.4: PMC Control and Configuration Registers

Register 0x00: Direct output control bits. Read/Write

The bits of register 0x00 are connected to the control line I/O buffers (with a switch in Register 0x14 to allow the memory sequencing to control the I/O buffers instead). The bus enables for bus0 (CMPRESET), bus1 (RMPRESET), bus2 (CNTRESET) and bus3 (REFSEL) are controled with the contents of Register 0x08. The CNTRESET signal is not used by the SVX4 chip.

bit signal0 PRI_IN1 PARST2 PRD13 PRD24 L1A5 CALSR6 FEMODE7 BEMODE8 CHMODE9 FECLK10 BECLK11 CMPRESET12 RMPRESET13 CNTRESET14 REFSEL15 SCOPETRIG

Register 0x04: Direct I/O readback Read-Only

17

The bits of register 0x04 are connected to the data inputs from the test hardware. Bit 4 of Register 0x14 selects whether these bits are read from the chip/hybrid adapter board interface or the JPC interface. Bit 5 of Register 0x14 selects which of the two possible PRI_OUT signals on the JPC interface is read into the PRI_OUT signal of this register. This register is read only. Writing to it has no effect.

bit signal0 OBDV1 BUS02 BUS13 BUS24 BUS35 BUS46 BUS57 BUS68 BUS79 PRI_OUTBits 10—15 are unused.

Register 0x08: Direct Output Enables. Read/Write 1: enable for output, 0: tri-state outputRegister 0x08 controls the tri-state enables on the I/O drivers for bus lines 0 through 3, when Register 0x00 is being used for the control signals. This register has no effect when the pattern memory is used for controlling the output signals. When the pattern memory is used, the four enables are not separately controllable, but are ganged together with one enable bit.

bit signal0 CMPRESET enable (uses BUS0 line for output)1 RMPRESET enable (uses BUS1 line for output)2 CNTRESET enable (uses BUS2 line for output. Unused by SVX4)3 REFSEL enable (uses BUS3 line for output)Bits 4—15 are unused.

Register 0x0C: Pattern address for reading/writing the pattern. Read/Write

18

Only the lowest 14 bits are used, allowing addresses up to 16384. Setting bit 0 of Register 0x14 copies the contents of Register 0x10 and bits 0 and 1 of Register 0x30 into pattern RAM. The contents of the memory pointed to by Register 0x0C are placed in Register 0x28 and bits 2 and 3 of Register 0x30.

Register 0x10: Pattern data input for writing to FPGA RAM Read/Write

All 16 bits are significant. The contents of this register are stored in pattern RAM when bit 0 of Register 0x14 is set to 1. The ENABLE bit in bit 15 controls the enables on bus lines 0 through 3. When set to 1, these lines are used for writing from the FPGA. When set to zero, these lines are not driven by the FPGA, allowing the SVX4/ MCP to set their states. When CLK_SEL is set to 1, BECLK is wired to the pattern clock (normally 50 MHz). When CLK_SEL is set to 0, BECLK is controlled by the BECLK bit in pattern memory. The CLK_SEL feature allows a double-rate BECLK to run during digitization.There is also no CNTRESET present in the pattern memory.

bit signal0 PRI_IN1 PARST2 PRD13 PRD24 L1A5 CALSR6 FEMODE7 BEMODE8 CHMODE9 FECLK10 BECLK11 CMPRESET12 RMPRESET13 CLK_SEL -- If set, run BECLK at full pattern speed.14 REFSEL15 ENABLE

19

Register 0x14: Pattern control word Read/Write

Bit Function0 Write a pattern word to FPGA RAM. Put the contents of Register 0x10 and bits 0 and 1 of Register 0x30 into the FPGA pattern RAM address pointed to by Register 0x0C. Set this bit to one to do the write. The FPGA will clear this bit when the write is complete.

1 Value=0: Use Registers 0x00 and 0x08 for setting output signals Value=1: Use pattern memory for setting output signals. Note – this bit only has effect when we are sequencing a pattern out. Otherwise, registers 0x00 and 0x08 are used for control signal outputs regardless of the state of this bit.

2 Pattern sequence switch. Set to 1 to start sequencing pattern. After one pattern execution, this bit will be cleared by the FPGA. Switch this off when reading/writing from FPGA RAM.

3 Unused (old feature deleted).

4 When set to 1, read the data back from the JPC adapter (SAMTECs C and D). When set to 0, read the data buses from the chip and hybrid ports, SAMTECs A and B.

5 Needs bit 4 to be set to 1 in order to have any effect When set to 1, read the Z side pri_out from the MPC as pri_out, and when set to 0, read the PHI side pri_out

Bits 6—15 are unused.

Register 0x18 Loop Begin Address Read/WriteNot yet implemented.

Register 1C Loop End Address Read/WriteNot yet implemented

20

Register 0x20 Loop Count Read/WriteNot yet implemented

Register 0x24 Address of Last Word in Pattern Memory (First one at 0) Read/Write

The lowest 14 bits are significant. When the memory address reaches the value indicated by the contents of Register 0x24, pattern sequencing stops, the memory pointer is reset to 0, and the control lines are set by the contents of Registers 0x00 and 0x04.

Register 0x28 Pattern Data Readback Read Only

The contents of the memory location pointed to by the contents of Register 0x0C are returned in this register. The bit associations are the same as for Register 0x10. Two additional bits are read back in Register 0x30.

bit signal0 PRI_IN1 PARST2 PRD13 PRD24 L1A5 CALSR6 FEMODE7 BEMODE8 CHMODE9 FECLK10 BECLK11 CMPRESET12 RMPRESET13 CLK_SEL14 REFSEL15 ENABLE

Register 0x2C Pattern Address Readback Read Only

The lowest 14 bits are significant. This register reads the instantaneous value of the pattern memory address during sequencing.

21

Register 0x30 Additional Bits for Pattern Memory Storage and Readback.

Some of this register is read/write and some is read-only. Writing to the entire register has no effect on the read-only bits. This register is an extension of Register 0x10, used to write an additional two bits to pattern RAM. It is also an extension of Register 0x28, allowing these two bits to be read back from pattern RAM. bit Function0 Scope trigger -- bit to be stored in memory when bit 0 of Reg 0x14 is set. Read/Write1 Store enable -- bit to be stored in memory when bit 0 of Reg 0x14 is set. Read/Write2 Scope trigger -- read back from pattern memory Read-Only3 Store enable -- read back from pattern memory Read-Only4—15 no action. Read/Write

Register 0x34 DAC output Read/write 8 bits are significant 0 -> zero volts 255 -> maximum DAC output (determined by the

DAC reference voltage on the adapter board). Note: The DAC, upon power-up, outputs a voltage that is a significant fraction of its range, even if these bits are initially zero. It is necessary to send a different bit pattern (such as 0x1) and then zero again in order to reset the DAC voltage upon power-up.

22

Register 0x38 Sequencing clock time base. Read/Write

Low three bits: (bits 0 through 2)

000 -- default – use the PMC on-board crystal (50 MHz) and ignore all divide bits below. 001 – use the PMC crystal (XTAL) with divide bits enabled 010 -- XTAL*2/3 -- 33.333 MHz 011 -- XTAL*17/16 -- 53.12 MHz . With 7 pattern cells per FECLK, this gives approximately a 132 ns cycle for FECLK. 100 -- XTAL*9/8 -- 56.25 MHz 101 -- XTAL*5/4 -- 62.5 MHz anything else: use XTAL directly (with no divides). (this seems to have a duty cycle closest to 50% of the undivided clocks).

Next three bits (bits 3, 4, 5): Each one controls a divide-by-two for the clock frequency, starting with the base frequency given by the first three bits. Setting one of them to '1' divides the clock frequency in half. Setting two to '1' divides the clock frequency by four. Setting all three to '1' divides the clock frequency by eight. Setting Register 38 to 0x12 divides the clock frequency by three.

all divide-by-two clocks should have 50% duty cycle.

Note: The clock should be set to 50 MHz when writing PMC pattern data to memory (otherwise bits get dropped).

Register 0x3C Read Only

This register contains the firmware revision number, currently 16 (0x10).

23

Subsection 3.5: PMC I/O Pin Assignments

Figure 3: I/O Pin assignments for the four PMC Samtec headers.

24

Section 4: Software

Overview

ROOTXTL is a software package for controlling SVX4 devices. It allows the user to run several tests of SVX4 chips, hybrids, or staves and make some representative plots as for example pedestal, noise, differential noise, etc. The first subsection gives a brief how-to-get-started recipe. The second subsection presents the interface in detail. The third subsection presents the code structure.

Subsection 4.1: Getting started

The following steps will get the user started with the ROOTXTL package.

1. Download the ROOTXTL package from:www.hep.uiuc.edu/home/catutza/rx_last.tar.gz

2. Extract the code:tar -xzvf rx_last.tar.gz

cd RX_THEWORKS3. Compile the code:

gmake 4. Start up the GUI:

./loopwrite &Assuming that no error occurred in executing steps 1-5, a GUI window (Fig. 4) will appear. The first thing to do is initialize the system as directed below:

5. Select the appropriate device: chip, hybrid, half-stave, full stave, and L0 module.

6. Uncheck the MiniPort Card (MPC) checkbox if using the adapter board, and not the MPC.

7. Select the chip version. The default selection is v2.

8. Make sure the “Init file” (and also “DAQ file”, “DTLS file”) exists in the RX_THEWORKS directory.

9. Check the “Initialize” checkbox.

10. Press the green “Go!” button.

25

11. Go to the “Output log” tab and make sure the initialization was completed successfully. If not, check the power on the chip, cabling, and maybe reboot the PTS computer, as the PTA might have experienced bus contention sometimes in the past. Note: From experience, it is a good idea to power off the SVX4 device, then shutdown the computer, wait 10 s, power back the computer, and after the boot is completed power back the device. This holds not only for initialization problems, but also for pedestal or deadtimeless test problems as well.

If the initialization worked, the user may check the “Pedestal test” checkbox and

press the “Go!” button. Again, the potential errors are displayed in the “Output log” panel, and some plots should appear in the “Plots1” and “Plots2” panels. This should be enough to get started. We will next describe the interface in more detail.

Subsection 4.2: Detailed look at the GUI

The graphical structure of the GUI is a single window with a number of panels: ”DAQ control”, “Plots 1”, “Plots 2”, “Output log”, etc. (Fig. 4). In the following subsections we describe each of these panels.

4.2.1: DAQ control Panel

The “Device” selection is straightforward:

Select which system you are testing: single chip, hybrid, half-stave, full-stave, or L0 module (5-choice radio button).

“SVX4 version”: check this box if testing SVX4 chips produced before May 2003. If testing preproduction chips, uncheck it.

“Use MPC”: check this box if testing the system through a MiniPort Card (MPC). Uncheck it if you are using the PTS adapter board instead.

The “Tests” selection implements the following tests:

“Initialize”. This initializes the SVX4 system from the file shown in the “Init file” textfield. Specifically, the parameters in this file are assumed for all chips with the following exceptions:

1. If not testing single chips, then the chip ID bits in the initialization file are ignored, and new chip ID’s are created (see 4.3.3). These chip ID’s are printed in the “Output log” textarea after each initialization attempt.

26

2. The First Chip bit and Last Chip bit listed in the initialization file are ignored, and new FC and LC bits are created for each chip, to avoid possible errors.

“Pedestal test”. It is assumed that the system has previously been initialized (see item a) above). This test uses the data contained in the file shown in the “DAQ file”textfield. It further uses the parameters listed in the “DAQ params” panel. The results are plot in the “Plots 1” and “Plots 2” panels. Further output can be printed on the screen, to a file, and in the “Output log” window, as it will be explained in 4.2.2.

“Deadtimeless” test. It is assumed that the system has previously been initialized. This test uses data contained in the file shown in the “DTLS file” textfield. It also uses the parameters listed in the “DAQ params” panel. The results are plot in the “Plots 1” and “Plots 2” panels. Further output can be printed on the screen and in the “Output log” as it will be explained in 4.2.2.

Finally, the six files listed in the lower part of the window are:

1) “Init file”: Generic initialization file setting the chip parameters. The user needs not set the First Chip and Last Chip bits, as well as the chip ID’s for multiple-chip systems.

2) “DAQ file”: This is a pattern file which contains the basic DAQ run data (Fig. 8): acquire + digitize + readout. A Level 1 accept (L1A) is issued somewhere in the acquisition stream, then the corresponding event is digitized and read-out.

3) “DTLS file”: This is a pattern file which contains a two-event sequence: acquire + digitize + readout + acquire + digitize + readout. One L1A is issued somewhere in the first acquire stream, and a second L1A is issued (in the code) in various positions preceding the second digitization stream (Fig. 9).

4) “ROOT file”: This is a ROOT file written out by executing the “Deadtimeless” test. It contains an array of Nchips * 128 histograms, where Nchips is the number of SVX4 chips in the system.

5) “FLAT file”: This is an ASCII file containing data readout from the system – formatted according to the Run2A testing environment. It is only produced if the checkbox ”Print SVX file” in the “DAQ params” panel is checked.

6) “PS file”: This is a PostScript file containing the histograms produced by the “Pedestal” test. In the near future it will also incorporate histograms produced by the “Deadtimeless” test.

Note: The files 1) –3) were created by the LBL group. For more details, please visit Marc Weber’s webpage at LBNL (http://www-cdf.lbl.gov/users/mweber). The files 4) – 6) are output files, and are produced by running the pedestal and deadtimeless tests.

27

4.2.2: DAQ params Panel

This panel (Fig. 5) allows the user to set certain parameters specific to the pedestal and deadtimeless tests. For pedestal, the user can set:

“Channel #”: this identifies the particular channel we are interested in plotting the ADC counts histogram for.

Number o’runs”: this specifies the number of 10 - DAQ sequence runs. A DAQ sequence (Fig. 8) consists of one acquire + digitize + readout data stream defined by the “DAQ file” textfield.

“Min ADC” and “Max ADC”: these numbers define the ADC counts (pedestal) range for all channels. A channel with a mean ADC outside this range will be flagged as bad.

“Min Noise” and “Max Noise”: these numbers define the allowed noise range (in ADC counts) for all channels.

“Min DNoise” and “Max DNoise” define the allowed dnoise range (in ADC counts) for all channels.

“Print SVX file” checkbox: if selected, an ASCII file (see “FLAT file” text field) will be printed out. This file contains all data readout from the SVX4 chips during the “Pedestal” run, in a format specific to the Run 2a testing environment.

“Print raw events” checkbox: if selected, the raw data readout from the

SVX4 chips are printed on the main (Linux) screen.

We illustrate the roles of these parameters through a simple example. Let us assume that the pedestal test is run for a hybrid, producing the results shown in Figures 6 and 7. Let us first consider the upper plot in Fig. 7. From the histogram’s label we infer that the “Channel #” parameter was 9. Because the number of entries in this histogram is 1000, the “Number o’runs” parameter must have been 100, as 10 DAQ sequences are executed for each run. The mean of this histogram is 141 and the RMS is 1.645 ADC counts. The value 141 represents the mean ADC count for channel 9, and corresponds to the entry in bin 9 of the ADC histogram of Fig. 6. Similarly, the value 1.645 represents the noise for Channel 9, and corresponds to the bin 9 of the noise histogram (blue line) of Fig. 7. Finally, the difference between channel 9 and channel 8 readouts (differential noise) for each sequence is histogrammed, and the RMS of this histogram divided by 2 corresponds to the bin 9 of the dnoise histogram (red line) of Fig. 7.

28

For the deadtimeless test, the user may set:

“Channel #”, “Print raw events” - as previously described.

“Bucket #”: this identifies the particular bucket for which we want to record the pedestal, noise, and dnoise.

“Runs per L1A”: this is the number of DTLS sequences executed for each position of the second L1A. A DTLS sequence consists of an acquire + digitize + readout + acquire + digitize + readout data stream as defined in the file specified by the “DTLS file” text field (Fig. 8).

“2nd L1A Range (%): this is the allowed range for the second L1A, expressed as a percentage of the total length of the stream contained in the “DTLS file”. A 0% would indicate that the two L1A’s coincide (apart from an offset of 1 FECLK), while 100% would march the second L1A through the entire DTLS stream. However, as shown in Fig. 9, this region should not extend beyond the second digitize, or else the second event will not be digitized. To figure out what the correct percentage, the user should run with 100% first, then analyze the plots obtained and re-enter the correct number (for single chip the range is ~ 65%).

“1st/2nd L1A”: this is a switch for looking at the first L1A event (if box is checked) or the second L1A event. The deadtimeless test is designed for analyzing the second event, but in some cases it is useful to look at the first event for various comparisons.

4.2.3: Plots 1 and Plots 2 Panels

These are the plotting areas, which accommodate four plots. In the case of the pedestal test these plots are (Fig. 6, 7):

Cell ID: this is a histogram of the pipeline cell ID’s readout from each chip. For example, the cellID histogram of Fig. 6 is relatively uniform, and has 4000 entries (4 chips in hybrid * 100 runs * 10 sequences per run). Alternately, one can run the “*fixed_cell.pat” files present in the RX_THEWORKS directory, which probe a fixed pipeline cell.

Average ADC count versus channel ID: in this histogram, the contents of bin j represent the average ADC count readout from channel j 1.

ADC count for a given channel. The particular channel is selected via the “Channel #” numberfield.

Noise and dnoise versus channel ID: self-explanatory (also see the example given in 4.2.2).

29

In the case of the “Deadtimeless” test, the following plots (Fig. 12) are produced:

Average ADC counts versus bucket number (for a given channel): the desired channel is selected via “Channel #” numberfield. In this histogram, each bin corresponds to a given bucket, i.e. to a certain position of the second L1A. For each of these positions a number of N (given by the “Runs per L1A” numberfield) sequences are run. We plot the mean ADC counts for this channel resulted from the N measurements. The error bars represent the standard deviation (RMS) from the N measurements.

Average ADC count versus channel ID (for a given bucket): the desired bucket is selected via the “Bucket #” numberfield.

Noise and dnoise versus channel ID (for a given bucket): self-explanatory.

4.2.4: Output log Panel

This panel (Fig. 10) features one text area where some important messages are printed. In the case of initialization, we print the chip ID’s for all chips to be initialized, and the total number of errors, and the errors if any. In the case of the pedestal test, we print out the total number of bad channels. If the “Show Errors” checkbox is selected, then we also print out the bad channels’ ID’s along with the failure type (outside the ADC range, outside the noise or dnoise ranges, etc). These ranges are specified in the “DAQ params” panel.

4.2.5: Header Panel

This panel (currently empty) will contain a number of textfields to identify the testing environment parameters as: Tester’s name, Device type, Part Number, Temperature, etc. This information will go into the header of the “FLAT file” produced during a pedestal run.

30

4.2.6: IniTab Panel

This panel (Fig. 11) allows to user to reset each initialization parameter by hand, for all the chips in the system. If this kind of modification is desired, the user should follow the following steps:

Initialize the system from file: this is achieved by checking the “Initialize from file” checkbox and pressing the “Go!” button.

Go to the “IniTab” panel and press the “Get Params” button. This will display the initialization parameters for the first chip (chip index 0).

Modify these parameters, and press the ”Set Params” button. This will modify the initialization string according to the new values, but will not yet send this string to the chip.

Press the “Next Chip” button and modify the parameters if desired.

When all the modifications are made, press the ”Initialize” button located to the right of the “Set Params” button. This sends the new initialization string to the chip. The errors are printed out to the “Output log” text area.

31

Subsection 4.3: Code structure

This section is intended for users who may want to add to the existing capabilities of the software. The following files are relevant to the SVX4 chip control:

loopwrite.cxx loopwrite.hframe_02.c frame_03.c frame_04.c Makefile

In addition to these, there are a number of files needed for the PTA access: pta.lib, pta.dll, pta_block.h, pta_lib.h, pta_jtag.h (in the distributableIncludes directory). However, the user should never have to deal with these files, and we will not describe the details of accessing the PTA.

4.3.1. loopwrite.cxx

This is perhaps the most important file in the package. The main function locates the PTA board and sets up a PTA_HANDLE (hPlx), then instantiates a GUI class object TestMainFrame. This in turn instantiates the test classes: Initialize, RunDAQ, RunDTLS. The TestMainFrame constructor builds up the GUI, positioning the buttons, labels, etc. The buttons’ functionality is specified in the TestMainFrame::ProcessMessage function. The global GUI variables (to be used outside of loopwrite.cxx) are declared at the top of loopwrite.cxx. In the other test classes, these global variables are declared as extern type variables. Global variables also include:

int device. 0=single chip, 1=hybrid, 2=half-stave, 3=full-stave, 4=L0 module.int chipID_array[24]. This is the chip ID array.

int Nchips. This represents the number of SVX4 chips in the system. int IniString[24][192]. This is the initialization string. Only the first Nchips are sent for initialization

4.3.2. loopwrite.h

This file contains the test classes’ declarations. In the current version of the software, there are three such classes: Initialize, RunDAQ, and RunDTLS.

4.3.3. frame_02.c

This file incorporates the Initialize class. The public functions are:

void Initialize_this() - invoked by pressing the “Initialize from file” button on the “DAQ control” panel. This function initializes the system according to the “Init file” shown in the “DAQ control” panel. The first and last chip bits in the file are discarded, and the code ensures that first chip bits are sent last and

32

vice-versa. For multiple-chip system (hybrid, stave etc) the chip ID info in the file is also discarded, and chip ID’s are created by the code as:

x03 (LC), x43, x23, x63, x13, x53, x33, x73, x0B, x4B, x2B, x6B, x1B, x5B, x3B, x7B, x07, x47, x27, x67, x17, x57, x37, x77.

Last Chip ID is always x03, while the First Chip ID varies with the number of chips (0x43 for a L0 module, 0x63 for hybrid, etc).

void Initialize_fromPanel() - invoked by pressing the “Initialize’ button on the “IniTab” panel. This function initializes the system based on the current values in IniString[24][192]. The name is somewhat misleading, in that no initialization bits are read out from the “IniTab” panel. To initialize from panel, the user has to first update the values in IniString[24][192] by calling SetParameters(int ichip) for all chips of interest (see below) and then call Initialize_fromPanel().

void GetParameters(int ichip) - invoked by pressing the “Get Params” button on the “IniTab” panel. This function fills the 28 numberfields with the current values of IniString[ichip][192]. If SVX4 v2 chips are tested, the “Dummy bit” and “Internal VCAL” numberfields are filled with 0’s.

void SetParameters(int ichip) - invoked by pressing the “Set Params” button on the “IniTab” panel. This function updates the values IniString[ichip][192] based on the 28 numbers in the “IniTab” panel numberfields.

We will not describe the private functions, as they will likely not need modifications.

4.3.4. frame_03.c

This file contains the RunDAQ class, which implements the Pedestal test. There is only one public function:

void Loop_Run() - invoked by checking the “Pedestal test” checkbox and then pressing the “Go!” button. This function first reads the “DAQ file” and fills up the PMC memory with this data. Then the sequence bit (see Section 3.4, Register 0x14) is toggled 10 times1 for each run. The total number of runs is specified via the “Number o’runs” numberfield. The data readback from the system is then processed according to the recipe below:

o Analyze the first 8-byte word and verify that it matches the first chip ID. If this is the case, convert the subsequent words into channel number and data.

1 The actual number is 12 times, but the first and last sequences are discarded, due to some PTA memory readback features.

33

o Fill two arrays of histograms: Harray1[Nchannels], Harray2[Nchannels] with the data for each channel, and the difference of data readback from adjacent channels respectively (the standard deviation of the latter defines dnoise*2).

o When channel 127 is reached, we go back to the first step, i.e. we verify that the next chip ID comes out properly, etc.

When the runs are finished, a plot of the average pedestal (the mean of Harray1[i] for i = 1, …, Nchannels) is produced, along with noise and dnoise histograms. Harray1[chan] is also plot, where chan is specified in the “Channel #” numberfield.

We point out that this recipe fails if the chip is readout in sparse mode, and channel number 127 is not readout. This should be fixed once a solid recipe for separating channel number (0-127) from the chip ID (0-127) is found. Finally, as described in 4.2.2, this function can also print out the events on the screen (Fig.14) if the “Print raw events” checkbox is selected, and to an ASCII file if the “Print SVX file” is selected.

4.3.5. frame_04.c

This file contains the RunDTLS class, which implements the deadtimeless test. There is only one public function:

void Run_DTLS() - invoked by checking the “Deadtimeless” checkbox and them pressing the “Go!” button. This function reads the “DTLS file” and checks if only one L1A is present in this file. If this is true, the code proceeds to identifying valid positions for the second L1A in the data stream. The valid positions are defined by the following criteria:

o The second L1A can not be located immediately after or immediately before edges of FECLK or PRD2.

o The second L1A can only be located two clocks after the falling edge of FECLK (see Fig. 15), and at least five (offset =5) clocks after the first L1A.

There is a loop over all possible positions for the second L1A. In this loop, we:

o Write out the PMC memory with the deadtimeless data (with the second L1A bit modified in the code).

o Sequence this deadtimeless stream N times, where N is specified through the “Runs per L1A” numberfield.

34

o Readout data from the system (N sequences * 2 events * Nchips * (128+1) eight-byte words).

o Fill out two arrays of histograms Histo_array1[Nchannels] and Histo_array2[Nchannels] with the data and dnoise for each channel or pair of channels respectively.

o For all channels i, store the means and standard deviations of these histograms in arrays:

bucket_chan_array[bucket][i]=Histo_array1[i]->GetMean();bucket_chan_noise_array[bucket][i]=Histo_array1[i]->GetRMS();bucket_chan_dnoise_array[bucket][i]=Histo_array2[i]->GetRMS()/sqrt(2.0);

o Reset the histogram arrays.

After the loop over L1A positions (buckets) is completed, we construct a new array of histograms Histo_array3[Nchannels] as:

if (j is a valid bucket):Histo_array3[i]->SetBinContent(j+1, bucket_chan_array[bucket][i]);Histo_array3[i]->SetBinError(j+1, bucket_chan_noise_array[bucket][i]);

Finally, we write this array of histograms to the ROOT file specified in the “ROOT file” textfield. On the “Plots1” and “Plots2” panels we plot Histo_array3[chan] and also pedestal, noise and dnoise for a given bucket.

35

FIG 4: The main PTS GUI window

FIG 5: The “DAQ params” panel.

36

FIG 6: The “Plots1” panel. The pedestal test was run for a hybrid.

FIG 7: The “Plots2” panel. The pedestal test was run for a hybrid.

37

FIG 8: Schematic representation of the DAQ sequence. A L1A is issued a certain number of FECLK’s after the Charge Injection is set. This delay should match the trigger latency value present in the initialization file.

38

acquire digitize readout

1st L1A 2nd L1A range

1 2 ……………..j………………….n

acquire digitize readout

acquire digitize readout

L1ACharge Inj.

Trigger latency

FIG 9: Graphical illustration of a DTLS sequence, where 2 L1A’s are issued. The first L1A is issued in a fixed position at the beginning of the first acquire, while the second L1A position spans the range shown above. For each position j = 1,.., n in this range, we run the DTLS sequence above N times, where N can be selected in the “Runs per L1A” numberfield. We refer to the position j as “bucket j”.

FIG 10: The “Output log” panel.

39

FIG 11: The

“Initialize” panel.

40

FIG 12: Plots produced by the “Deadtimeless” test

FIG 13: ROOTXTL code structure. The input and output files are also shown.

41

loopwrite.cxxloopwrite.h

frame_02.cInitialize class

frame_03.cRunDAQ class

frame_04.cRunDTLS class

Init file DAQ file DTLS file

Flat file PostScript file ROOT file

42

FIG 14: The raw data coming from the chip. First chip ID is 99 (x63).

bus2bar : ___________________________________________trig : ___________________________________________pri_in : ___________________________________________enable : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXchmod : ___________________________________________be_mode : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXclk_sel : ___________________________________________be_clk : ___________________________________________comp_rst : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXrref_sel : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXramp_rst : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXstore : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXfe_mode : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXfe_clk : ___XX_____XX_____XX_____XX_____XX_____XX___cal_inject : ___________________________________________l1a : XXXXXXXXXXXXXX_XXXXXXXXXXXXYXXXXXXYXXXXXXYXprd1 : ___________________________________________prd2 : ___________________________________________pa_reset : ___________________________________________

FIG 15: Positioning the second L1A in the deadtimeless code (frame_04.c). The red Y’s mark the allowed positions.

Section 5: Port of HTWISHBecause the hardware setup is logically similar to that of the Berkeley Pattern

Board system [4], it is natural to run software already written for the Berkeley Pattern Boards on the PTS. All that is needed is to re-code the hardware access routines, translate the control channel mapping, and store the data in the same arrays and in the same format as expected by the software which anticipates running on the Berkeley Pattern Boards.

One of the most complete hybrid test suites already written is HTWISH, maintained at LBL by John Freeman, although it was originally written by a large group of people over a long time. Porting this test suite has two advantages – these are the same tests that are applied to hybrids at Berkeley, and therefore the results can be compared after shipping hybrids to Fermilab, and the data produced are in the same format as that produced at LBL.

The original code may be found on Marc Weber’s home page, http://www-cdf.lbl.gov/users/mweber/svx4/, in three tarfiles, code.tar, patterns.tar, and dbsupport.tar. There is additional software which must be obtained in order to install this package on a computer. These packages are the CERN libraries, tcl, tk, BLT, tix, the Berkeley Database from Sleepycat Software, and histoscope. This code, including the additional packages, and modified to run on the PTS, is available at http://www.hep.uiuc.edu/home/trj/pts/htwish/pts_htwish_22july.tar.gz. John Freeman’s

43

draft manual, which describes the installation procedure and how to run the tests, is available at http://www.hep.uiuc.edu/home/trj/pts/htwish/Htwish_manual.txt.

Some differences in the hardware setup required changes to the HTWISH software. For example, PTS uses OBDV to clock in data. If OBDV is not present, then data are not stored in memory. The Berkeley pattern system stores data words in memory when the STORE signal instructs it to (when STORE=0. STORE=1 means “Don’t Store”). The Berkeley system therefore always has the same number of words filled in its FIFO, which depends on the number of pattern clocks have STORE=0. PTS on the other hand only fills its memory when OBDV makes a transition from low to high or from high to low. In sparse mode, this can change the total readback size relative to that in the Berkeley system. In all modes, it also affects the readback size because the standard patterns have STORE=0 after the data are finished from the chips. HTWISH correctly checks all features of the data to make sure they make sense before declaring a hybrid functional, including the readback size. For a Berkeley pattern system, the readback size check is only a check of the functionality of the pattern board. For PTS, the readback size also indicates if the chips are functioning properly. A chip with dead channels will have a shorter-than-expected readback size in sparse mode, for example. The code has been modified to calculate new readback sizes for PTS. If the PTS is to be used to test hybrids of different sizes, such as L0 hybrids, these readback sizes will need to be recomputed.

Another difference in the hardware configuration is reflected in the ported code. An inconvenient feature of the PTA firmware is the fact that the FIFO buffer doesn’t get flushed to the PTA memory unless more data arrive. Often the last two 32-bit words don’t make it to the PTA memory (although the memory size pointer does get updated – it points to uninitialized memory). The solution is to read out multiple times and to discard the first and last reads, in order to get a guaranteed complete readback of the hybrid. This strategy is encoded in the routine out_go in out.c in the iolibraries.

The problem with this is that the pipeline cell ID advances by the number of FECLKs (modulo 46) in the pattern string for each time the pattern string is executed. HTWISH checks to make sure the expected cell ID is returned by the hardware and indicates failure otherwise. New cell ID’s reflecting the extra pattern sequences have been calculated. HTWISH takes advantage in tests like GETMAP, of patterns which have a number of FECLKs which is relatively prime to 46, so that 46 steps through the pattern tests all of the pipeline cells. It is a good thing that 3 is relatively prime with respect to 46, so that three reads, discarding the first and the last, preserves this property.

The MULTIHIT test also had to be updated for this reason too – the pattern MULTIHIT needs is too long to fit in the Berkeley pattern system’s pattern FIFO, with one short acquire sequence (with four L1As), and four copies of the digitize and readout pattern for a hybrid. In the Berkeley version of HTWISH, the acquire portion of the pattern is loaded in the FIFO, executed, and then the digitize and readout pattern is loaded in the FIFO and executed four times. On PTS the triplication of the pattern executions would make this test malfunction. Instead, the entire pattern of one acquire

44

sequence and four digitize and readouts is constructed and loaded in the PTS and executed three times like all other patterns. The PTS allows this because it has a bigger pattern memory.

The serial line test also was rewritten, sending serial line data and FECLK’s in Register 0x0 of the PMC. This is done so that PRI_OUT can be read in Register 0x04 on each clock sequence. The PTS cannot read back PRI_OUT during sequencing unless OBDV is making transitions, which is not the case during initialization.

HTWISH has been ported to supply a separate test suite for hybrid diagnostics. It does not read out staves (needs new patterns and readout sizes and histograms to be redimensioned), and reading out single chips also requires the work of changing the expected readout sizes. The software described in Section 4 is designed to be a useful, flexible test suite for chips, hybrids, and staves.

Section 6: Summary

In this document, a system for testing chips, hybrids and staves for the Run 2b silicon upgrade is described. The test stand consists of a commodity computer, general-purpose test hardware, and specialized firmware, software, and cable adapters. At present, the system was successfully tested on SVX4 chips, hybrids and staves. It provides a flexible platform for testing a great variety of different hardware types. The control patterns and initialization strings are entirely controllable in software. Specialized software has been written for each test of chips, hybrids, and staves, and also porting of software originally designed to run on the Berkeley pattern systems has been shown to be not too difficult to port.

In the future, both the firmware and software can be modified to accommodate the upcoming needs of the Run 2b testing effort.

References

1. Ken Treptow and Greg Duerling, “BTeV/C0 PCI Test Adapter Card”, March 23, 2001. This document is electronically available at http://www-ese.fnal.gov/ESEPROJ/TestStands/PCI_Test_Adapter.doc

45

http://www-ese.fnal.gov/ESEPROJ/TestStands/PCI_Test_Adapter.pdf

2. Bradley Hall, Guilherme Cardoso, David Christian, Gabriele Chiodini, Lorenzo Uplegger, Sergio Zimmermann, “Test Beam 2002 Readout Electronics Plan”, ESE-PIX-20011203. This document is available electronically athttp://www-ese.fnal.gov/eseproj/BTeV/TestBeam02/TestBeamPlan2002_Rev1_5.dochttp://www-ese.fnal.gov/eseproj/BTeV/TestBeam02/TestBeamPlan2002_Rev1_5.pdf

3. Jeff Andresen, Guilherme Cardoso, Brad Hall, Sergio Zimmermann, “Programmable Mezzanine Card (PMC)”, ESE-PIX20001101, March 12, 2001. This document is electronically available athttp://www-ese.fnal.gov/eseproj/BTeV/TestStands/PMC/Prgm_MezzanineCard.dochttp://www-ese.fnal.gov/eseproj/BTeV/TestStands/PMC/Prgm_MezzanineCard.pdf

4. There is much documentation on the Berkeley Pattern Board system. See for example, Marc Weber’s page http://www-cdf.lbl.gov/users/mweber/svx4/, or Appendix B of Toni Munar’s thesis: FERMILAB-THESIS-2002-01, “Production and electrical characterization tests of the ISL detector and a trigger design for Higgs boson searches at CDF”.

5. JPC interface: http://wwwese.fnal.gov/RunIIb/CDF/DAQ/CDFIIb@ESE/jpc_interface.htm

6. Chip/Hybrid cable adapter board for connecting cables from the PMC to the test boards for the chips and hybrids: http://web.hep.uiuc.edu/Engin/CDF/PMC/index.htm

46