CDF/DOC/TRACKING/CDFR/6626
August 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 doublebuffered 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
P
C
I
Reversing
Ribbon
cables with
Samtec
Connectors
PTA
Power
Supplies
PMC
A
B
u
s
Adapter
Board
Chip Test
Board
B
C
D
Hybrid test
Board
Connectors for
Guilherme’s JPC
adapter board
Figure 1: Hardware configuration for testing single chips on single chip test boards, and
also hybrids.
4
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/Write
Mezzanine Register.
BAR2, Offset 0x04 Read/Write
COMMAND
0
ENABLE
COMMAND
ENABLE
1
EN BAR3
DIRECTION
2
RESET BAR3
ADDRESS
3
EN RESET BAR3
ADDRESS
5
EN BAR4
DIRECTION
6
RESET BAR4
ADDRESS
7
EN RESET BAR4
ADDRESS
8
SET INTERRUPT
BAR3
9
EN SET
INTERRUPT BAR3
10
SET INTERRUPT
BAR4
11
EN SET
INTERRUPT BAR4
12
SOFTWARE
TOGGLE
13
EN SOFTWARE
TOGGLE
14
SELECT
FAKE/MEZZANINE
15
EN SELECT
FAKE/MEZZANINE
16
TOGGLE LIMIT
ENABLE
17
EN TOGGLE LIMIT
ENABLE
18
TOGGLE TIMER
ENABLE
19
EN TOGGLE
TIMER ENABLE
20
FAKE
CORE TALKING
21
EN FAKE
CORE TALKING
22
RESET
FAKE COUNTER
23
EN RESET
FAKE COUNTER
24
RESET DATA LOST
COUNTERS
25
EN DATA LOST
COUNTERS
26
RESET TIMER
COUNTER
27
EN RESET TIMER
COUNTER
28
RESET
DATA COUNTER
29
EN RESET
DATA COUNTER
30
31
RESET FIFO
EN RESET FIFO
BAR3 DIRECTION
4
BAR4 DIRECTION
7
Command Register
This 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.
Bit10 - (Enable Bit11) – SET INTERRUPT BAR4
This Bit is used to set or unset the interrupt generated when BAR3 reaches the limit.
8
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.
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.
9
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 Read
0
BAR3 DIRECTION
1
BAR4 DIRECTION
2
INTERRUPT BAR3
3
INTERRUPT BAR4
4
BAR3 EMPTY
5
BAR3 FULL
6
BAR3 HALF FULL
7
BAR3 LIMIT
8
BAR4 EMPTY
9
BAR4 FULL
10
BAR4 HALF FULL
11
BAR4 LIMIT
12
TOGGLE LIMIT
ENABLED
13
TOGGLE TIMER
ENABLED
14
SELECT
FAKE/MEZZANINE
15
FAKE CORE
TALKING
16
17
18:19
FIFO EMPTY
FIFO FULL
X
20:31
FIRMWARE
VERSION
Status Register
This 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
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.
10
Bit2 – INTERRUPT BAR3: BAR3 has data
After 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 data
After 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 Empty
This 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 Full
This Bit is set (one) when the BAR3 address pointer hits the last location in memory.
Bit6 – BAR3 HALF FULL: Memory BAR3 Half Full
This Bit is set (one) when the BAR3 address pointer crosses the half point in the memory.
Bit7 – BAR3 LIMIT: Memory BAR3 Limit
This bit is set (one) when the programmable threshold in the BAR3 limit register has
been reached.
Bit8 – BAR4 EMPTY: Memory BAR4 Empty
This 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 Full
This Bit is set (one) when the BAR4 address pointer hits the last location in memory.
Bit10 – BAR4 HALF FULL: Memory BAR4 Half Full
This Bit is set (one) when the BAR4 address pointer crosses the half point in the memory.
Bit11 – BAR4 LIMIT: Memory BAR4 Limit
This bit is set (one) when the programmable threshold in the BAR4 limit register has
been reached.
Bit12 – TOGGLE LIMIT ENABLED
This bit indicates if it’s possible to have a memory limit toggle.
Bit13 – TOGGLE TIMER ENABLED
This bit indicates if it’s possible to have a memory timer toggle.
Bit14 – SELECT FAKE/MEZZANINE
This bit indicates if the data flow comes from the fake counter (one) or from the
mezzanine (zero = default).
11
Bit15 – FAKE CORE TALKING
This bit indicates if the fake core talking is on.
Bit16 – FIFO EMPTY
This bit is set when the FIFO is empty.
Bit17 – FIFO FULL
This bit is set when the FIFO is full.
Bit18-19 – X
Undefined.
Bit20…31 – FIRMWARE VERSION
The first byte indicates if the firmware works with the old PTA releases (A) or with the
new ones (B).
BAR2, Offset 0x0C Read
31:0
BAR3 Address Pointer
BAR3 Address Pointer
This 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:0
BAR4 Address Pointer
BAR4 Address Pointer
This 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:0
BAR3 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:0
BAR4 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/Write
31: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 Read
31: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/Write
31: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 Read
31:0
Number of lost data by the
memories
Number of lost data by the memories
This 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 Read
31:0
Number of lost data by the
FIFO
Number of lost data by the FIFO
This 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 Read
31:0
Number of data in the FIFO
Number of data in the FIFO
This register shows the number of data present in the FIFO.
BAR2, Offset 0x34 Read
31:0
Data rate
Data rate
This register shows the number of Readout Clock cycles between two data coming from
the mezzanine.
14
BAR2, Offset 0x38 & 0x3C Read
31:0
Data counter
Data counter
This 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.
15
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
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
16
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.
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
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
signal
PRI_IN
PARST
PRD1
PRD2
L1A
CALSR
FEMODE
BEMODE
CHMODE
FECLK
BECLK
CMPRESET
RMPRESET
CNTRESET
REFSEL
SCOPETRIG
17
Register 0x04: Direct I/O readback
Read-Only
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 signal
0 OBDV
1
BUS0
2
BUS1
3
BUS2
4
BUS3
5
BUS4
6
BUS5
7
BUS6
8
BUS7
9
PRI_OUT
Bits 10—15 are unused.
Register 0x08: Direct Output Enables.
1: enable for output,
0: tri-state output
Read/Write
Register 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 signal
0
CMPRESET enable
1
RMPRESET enable
2
CNTRESET enable
3
REFSEL
enable
Bits 4—15 are unused.
(uses BUS0 line for output)
(uses BUS1 line for output)
(uses BUS2 line for output. Unused by SVX4)
(uses BUS3 line for output)
18
Register 0x0C: Pattern address for reading/writing
the pattern.
Read/Write
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
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
signal
PRI_IN
PARST
PRD1
PRD2
L1A
CALSR
FEMODE
BEMODE
CHMODE
FECLK
BECLK
CMPRESET
RMPRESET
CLK_SEL -- If set, run BECLK at full pattern speed.
REFSEL
ENABLE
19
Register 0x14: Pattern control word
Bit
Read/Write
Function
0
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/Write
Not yet implemented.
Register 1C Loop End Address
Read/Write
Not yet implemented
20
Register 0x20 Loop Count
Read/Write
Not 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
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
signal
PRI_IN
PARST
PRD1
PRD2
L1A
CALSR
FEMODE
BEMODE
CHMODE
FECLK
BECLK
CMPRESET
RMPRESET
CLK_SEL
REFSEL
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
0
Function
Scope trigger
-- bit to be stored in memory when bit 0 of Reg 0x14 is set.
Read/Write
1
Store enable -- bit to be stored in memory when bit 0 of Reg 0x14 is set.
Read/Write
2
Scope trigger -- read back from pattern memory Read-Only
3
Store enable -- read back from pattern memory Read-Only
4—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_THEWORKS
3. 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.
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.
26

“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.h
frame_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:
1
The actual number is 12 times, but the first and last sequences are discarded, due to some PTA memory
readback features.
33
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.
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).
34
o Sequence this deadtimeless stream N times, where N is specified through
the “Runs per L1A” numberfield.
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
acquire
Charge Inj.
digitize
readout
L1A
Trigger latency
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.
acquire
digitize
readout
acquire
digitize
readout
1 2 ……………..j………………….n
1st L1A
2nd L1A range
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”.
38
FIG 10: The “Output log” panel.
FIG 11: The
“Initialize”
panel.
39
FIG 12: Plots
produced by the
“Deadtimeless”
test
loopwrite.cxx
loopwrite.h
frame_02.c
Initialize class
Init file
frame_03.c
RunDAQ class
frame_04.c
RunDTLS class
DAQ file
DTLS file
PostScript
file
Flat file
ROOT file
FIG 13: ROOTXTL code structure. The input and output files are also shown.
40
FIG 14: The raw data coming from the chip. First chip ID is 99 (x63).
bus2bar
trig
pri_in
enable
chmod
be_mode
clk_sel
be_clk
comp_rst
rref_sel
ramp_rst
store
fe_mode
fe_clk
cal_inject
l1a
prd1
prd2
pa_reset
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
___________________________________________
___________________________________________
___________________________________________
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
___________________________________________
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
___________________________________________
___________________________________________
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
___XX_____XX_____XX_____XX_____XX_____XX___
___________________________________________
XXXXXXXXXXXXXX_XXXXXXXXXXXXYXXXXXXYXXXXXXYX
___________________________________________
___________________________________________
___________________________________________
FIG 15: Positioning the second L1A in the deadtimeless code (frame_04.c). The red Y’s mark the
allowed positions.
41
Section 5: Port of HTWISH
Because 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
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.
42
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
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.
43
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, generalpurpose 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
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 at
http://www-ese.fnal.gov/eseproj/BTeV/TestBeam02/TestBeamPlan2002_Rev1_5.doc
http://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 at
http://www-ese.fnal.gov/eseproj/BTeV/TestStands/PMC/Prgm_MezzanineCard.doc
http://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
44
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
45