![](media/image1.wmf){width="5.607638888888889in" height="0.85in"}

**SVX II Silicon Strip Detector Upgrade Project**

###### SVX Module Production Testing Software

**\--PRELIMINARY\--**

**21 Sept. 1998**

**Vince Pavlicek**

**Document \# ESE-SVX-980916**

# **1** Introduction to SVX Module Production Testing Software 

This document describes the software diagnostic tests that will be
applied to the production versions of seven VME modules that are being
designed for the SVX II detector system for the CDF Upgrade. The modules
to be tested are

A.  The three members of the VRB (VME Readout Buffer) family

-   The VRB

-   The VFO (VRB Fan-out)

-   The VTM (VRB Transition Module)

B.  The three members of the FIB (Fiber Interface Board) family

-   The FIB

-   The FFO (FIB Fan-out)

-   The FTM (FIB Transition Module)

C.  In addition, two modules that are used to test the above boards:

-   The GSTM that emulates the boards that connect to the board under
    test.

-   The DEM that generates simulated front-end data and can insert it at
    several places.

Most of the basis for this test list came from the draft document, [SVX
Data Acquisition System Test Flow](../Test_flow.doc) by J. Anderson and
K. Woodbury, 2/19/97. Many of the details needed to implement these
tests are included in that document so it is recommended reading. This
document uses many acronyms that are in common use with =in the SVX
project. If you find an unfamiliar acronym, refer to
http://www-ese.fnal.gov/eseproj/svx/svx_acronyms.htm.

# **2** Simple Tests applied to all Modules

## 2.1 Power Test. No Software. ESE/ESD Technician or assembly house.

Apply 5 volts with a current-limited power supply and measure current.
This test is done at a workbench and probably as part of the quality
control after the assembly process. Some boards also have on-board
oscillators that can be checked for activity.

## 2.2 VRB simple tests

A VRB power-up self-test requires VRB, subrack, RS232 terminal. It tests
on-board processor function, shared memory, and FPGA download. When the
test is complete, the Processor LED will be ON and the VME access and
SRC access LEDs will flash. The terminal may be used to display specific
errors. The terminal will display digitized light levels from the VTM.
Other power-up self-tests will be added such as a simple program to
blink the from panel processor LED.

# GSTM Test Stand -- Board Level Tests

## 2.3 Testing untested or failing GSTM boards.

### **2.3.1** Loop-back test. Java software. ESE/ESD tester.

There are three general tests. 1) Test transfers through 27 bit ports.
This will be one direction and should exercise different data patterns.
There should be no errors. 2) Test bi-directional transfers through nine
bit ports again with different data patterns. 3) Test control and status
bits. These tests should be able to run in two modes. One is a quick
tester that runs many data quickly and stops on errors. The second needs
to continue running when there are errors to allow hardware diagnostics
to locate the error.

The following diagnostic descriptions are from the Loopback adapter
specifications, ESE-SVX-960422. They often refer to GSTM Motherboard
logic that will be tested. That reference is the GSTM Motherboard
Specification, document number ESE-SVX-960126. References made here to
GSTM hardware can be seen in the GSTM Motherboard Specification, Figure
2: "Functional Blocks for the GSTM Motherboard".

Insert Loop-back adapter on two ports. Program the GSTM board for
loop-back adapter.

A test program will be needed which generally adheres to the content and
sequence detailed here.

-   Issue a /Master-Reset and check for an ID value of 0x01 in both
    T-Port and R-Port fields of the GSTM Test Register. This test
    verifies the receipt of /Master-Reset at each port.

-   Test that all six ID bits of both ports are functional. Generate a
    global GSTM CR-Cbit0 signal after putting bit-toggle test patterns
    in the T-FIFO. The low-order six bits of T-FIFO data should appear
    on the ID bits. A multiplexer failure might indicate a problem with
    the CR-Cbit0 signal at the erring port connector.

-   Write test pattern data into the T-Port FIFO until full. Clock the
    T-Port T11 (or T21) FIFO data into the R-Port R11 (or R21) FIFO.
    Read the R-Port FIFO and compare for errors.

-   Repeat FIFO tests while controlling the T-Port's and R-Port's nine
    bits of bi-directional data (called **DATA-IO** on both ports) as
    well as the GSTM Mode Register's direction control bits. Perform
    this to test both the bi-directional capabilities of the GSTM
    buffers and the data integrity of the FIFOs. This FIFO test should
    be performed twice, once in each direction (T-Port to R-Port and
    vice versa). The P-Cntrl \<2\> bits from both ports define direction
    control for the GSTM Loop-Back Daughter Card.

    (Programmer's note: The upper four bits of the GSTM Mode Register
    should be set to insure that no signal driver collisions occur
    between the Loop-Back Daughter Card and the GSTM. The Loop-Back
    Daughter Card provides internal self-protection against on-board
    signal collision should both ports drive their DATA-IO lines. It is
    possible to create a situation where the Loop-Back Daughter Card
    could drive against a GSTM port that is also driving. Care must be
    exercised in the sequence used to enable signal drivers to prevent
    GSTM-to-daughter signal collisions when test software is
    constructed.)

-   Using the T-Port's and R-Port's P-Cntrl \<2\> bits to control data
    flow direction, write test pattern data into the T12 (or T22) FIFO-1
    and read the data out through the R12 (or R22) FIFO-2. Perform the
    same test using the T12 (or T22) FIFO-2 and the R12 (or (R22) FIFO-1

-   Test the functionality of the P-Control bits, the /CR-Control bits
    and the MR-Mode bits for both ports under test. Generate a global
    GSTM CR-Cbit1 signal and the ID bits will be multiplexed in such a
    way as to monitor the status of the bits. Test software must command
    the GSTM to generate these signals and use the ID bits to verify
    their operability at each port connector. The control bits monitored
    through any given port ID bit field are the control bits for that
    port. A multiplexer failure might indicate a problem with the
    CR-Cbit1 signal at the erring port connector.

-   Test the functionality of daughter card status return bits
    P-Status\<2:0\> and SR-Status\<1:0\> for both ports under test.
    Generate both the global GSTM CR-Cbit0 and CR-Cbit1 signals after
    loading test pattern data in the T-FIFO. The low-order five T-FIFO
    bits will be echoed across the port-specific status return bits.

(Programmer's note: Remember that the Loop-Back card tests are always
being implemented on both Transmit and Receive ports, hence the
diagnostic software must verify bit operations on both the T-Port and
the R-Port for a complete test.)

### **2.3.2** GLink adapter tests. Java software. ESE/ESD tester.

Insert GLink receiver adapter on receiver port. Insert GLink transmitter
adapter on transmitter port. Program board for GLink adapters. Test
transfers through 27 bit ports. This will be one direction and should
exercise different data patterns. There should be no errors. Monitor
status bits for correctness. This test expands the GSTM testing by
exercising a different set of firmware in the GSTM programmable logic.

## 2.4 Testing DEMs

Data Emulator Modules are transition modules that can emulate a port
card. They operate in response to commands from a FIB and produce data
in the format produced by SVX3 chips. A DEM can plug in behind a FIB in
a subrack and take commands through J3. Alternatively, it can be
connected to a FIB through the DEM "front panel" control port. A DEM
produces ten channels of data at the J3 connector or it can mount an
optional DOIM transmitter to produce one fiber optic channel of data for
a FTM. The data part of the data stream is either an incrementing or a
pseudo-random pattern.

Testing a DEM requires a FIB for creating control signals and accepting
data. The best procedure would be to have the DEM tests be the FIB tests
that use the DEM as a data source. The part-under-test would shift to
the DEM rather than the FIB. Two specific tests are numbers 2 and 3 in
below.

The DEM is programmed according to the Detector Emulator Module
Specifications on the ESE document page at
http://www-ese.fnal.gov/eseproj/index/svxii/svxii.htm. Note that the DEM
is set-up by sending "commands" out one of the port card ports and
clocked (operated) through the other port. For future reference, also
notice that the DEM can monitor the commands it receives on the
operating port and return, in the status words, what the state of the
DDR would be if there were a DDR connected. This might help debug
software if the diagnostics were aware of this feature.

## 2.5 Testing VRBs

### **2.5.1** Simple VME tests. Java software. ESE/ESD tester.

These tests do not require a GSTM. They check VRB internal operation and
the VME interface, but do not test the FIB or SRC input ports.

1)  A VRB basic access test will start with single word writes and reads
    to dual-port memory in the range 0-3FFF (plus the module base
    address). A simple memory test is adequate.

2)  The VRB emulation mode loop test requires a VME processor, VRB, and
    subrack. The VRB simulates the FIB and VTM by generating its own
    \"event\" data. Simulated SRC control messages are written by the
    processor over VME. Simulated events are read out through VME and
    checked.

3)  Write a "readout" message to VRB from VME (three single-word
    writes). The VRB should display the message "processing READOUT
    message".

4)  Write a "scan" message to VRB from VME (two single word writes), VRB
    should display message "processing SCAN message", poll byte count
    register for non-zero value.

5)  Program Receive Logic to generate incremental data and write to data
    buffers on receipt of "readout" message (assumes VTM not yet
    available)

6)  VME block transfers from VRB data output FIFO (A24/D32, A32/D32 and
    A32/D64), check block transfer for incremental data.

7)  Check VRB/VME interrupt assertion. Requires only that the VME CPU be
    able to display some kind of message when it receives a VME
    interrupt (IRQ3).

### **2.5.2** GSTM based tests.

The GSTM loop test requires a VME processor, VRB, VFO, VTM, GSTM with
SRC emulator adapter, GSTM with G-Link Transmitter adapters, optical
splitters, and subrack.

The GSTM/SRC emulator sends SRC control messages through the VFO to the
VRB. The GSTM / G-Link Transmitter sends FIB data through splitters and
VTM to the VRB. The event data is read out through VME and checked by
the controlling processor.

This test exercises most of the VFO, VTM and VRB hardware. It will not
test the CDF Calorimeter application unless a TAXI data source is
available.

A first level test could repeat the above VME control logic tests, this
time using the GSTM/SRC to send "readout" and "scan" messages via VRB
Fanout and J3 backplane. GSTM monitors "readout busy" and "scan busy"
status signals from Fanout module.

Next, use the GSTM to drive VTM G-link input(s) and check Receive Logic
event recognition.

Example VRB test loop pseudo-code:

(GSTM setup)

copy \"expected VRB output pattern data\" file into memory

write to VRB channel enable register

write to VRB reset register

wait \~20 milliseconds

start loop

write to GSTM (SRC emulator) to send readout command

write to GSTM (FIB emulator) to send data

read VRB output data FIFO until non-zero value (N) is returned

read N bytes from VRB output data FIFO

compare to pattern data in memory

stop if error

end loop

## 2.6 Testing VFOs

The VFO can not be tested independently beyond the initial power test.
The VFO is a part of the VRB tests and VFO problems can be identified
best by replacing the suspect VFO with a "golden" VFO.

## 2.7 Testing VTMs

The VTM can not be tested independently beyond the initial power test.
The VTM is a part of the VRB tests and VTM problems can be identified
best by replacing the suspect VTM with a "golden" VTM. Simple testing of
the light monitoring circuitry on the VTM is included in the VRB power
up diagnostics. Extensive testing of this light monitoring circuitry
will require additions to the VRB tests.

## 2.8 Testing FIBs

### **2.8.1** Simple VME tests. 

VMEbus access and control simple tests that are basic read/write
activities. SVX hardware required: FIB and FFO.

-   Exercise secondary local bus access by writing and reading to
    ..........

-   Exercise primary local bus access by writing and reading to
    ..........

-   Exercise Pedestal and Calculation RAM accesses by writing and
    reading to ..........

-   Exercise NVRAM access, save and restore operations by writing and
    reading to ..........

-   Exercise Control Registers and Command and Status Registers over VME
    by writing and reading specific bits.

### **2.8.2** More complicated VME tests.

These tests only require the FIB and FFO with the subrack controller but
the tests are more complicated in that known data is moved through the
FIB and checked for correct processing.

1.  FIB/FFO - Pipeline / Data Processing Tests

-   Pipeline Test A - Data Pattern Check (see Test Flow Document, figure
    3)

-   Pipeline Test B - Pedestal Subtraction (see Test Flow Document,
    figure 4)

-   Pipeline Test C - Calculation RAM Test (see Test Flow Document,
    figure 5)

1.  FIB/FFO - Control Path

-   Control Path A - Command FIFO Test (see Test Flow Document, figure
    6)

-   Control Path B - Log FIFO Test (see Test Flow Document, figure 7)

-   Control Path C - Address Controller, Command Receipt Test (see Test
    Flow Document, figure 8)

-   Control Path D - Command Output Test (see Test Flow Document, figure
    9)

-   Control Path F (1) - Upload FIFO Test (refer to Test Flow Document,
    figure 10 - Data manually transferred into Upload FIFO from VME)

-   Control Path G (2) - Upload and Download FIFO Test (refer to Test
    Flow Document, figure 10 - Data manually transferred from Download
    to Upload FIFO).

-   Control Path E - SVX Initialization Internal Loop-back (see Test
    Flow Document, figure 10)

1.  FIB/FFO - J3 Command Transfers

-   Subrack Control Path Test A - Command Transfer Test (see Test Flow
    Document, figure 13)

-   Subrack Control Path Test C - Command Output and Interrupt Test
    (refer to Test Flow Document, figure 13, FFO providing continuous
    commands)

1.  FIB/FFO/FTM - FTM Control Output

-   Subrack Control Path Test B - Control Output Test (see Test Flow
    Document, figure 15)

-   Subrack Control Path Test B.1 - Control Output Test (refer to Test
    Flow Document, figure 15, FFO providing SRC command input (labeled
    lookup))

### **2.8.3** Tests utilizing the GSTM adapters.

These tests require the FIB, FFO and GSTM with the subrack controller.
The tests are more complicated in that known data is moved through the
FIB input output connectors rather than accessed through the VME bus.
The Data Emulator Module is used to create data.

1.  G-Link Data Transfers

-   *\*Software Currently NOT Available\** Subrack Pipeline Path Test
    A - Data Transfer Test (see Test Flow Document, figure 14) (Note:
    this test is NOT at speed)

1.  FIB/FFO/DEM - Pipeline / Data Processing Tests using DEM (Hardware
    required: FIB/FFO/DEM)

-   Pipeline Test D(2) - Data Pattern Check (refer to Test Flow
    Document, figure 3 - DEM is providing SVX data)

1.  FIB/FFO/FTM/DEM - Pipeline / Data Processing Tests using DEM
    (Hardware required: FIBx2/FFO/FTM/DEM)

-   *\*Software Currently NOT Available\** Subrack Pipeline Path Test
    B - Data Transfer Test (refer to Test Flow Document, figure 3 - DEM
    providing SVX data, transferring to secondary FTM and corresponding
    FIB)

1.  FIB/FFO/DEM/GSTM - Pipeline / Data Processing Tests using DEM with
    G-Link Data Transfers (Hardware required: FIB/FFO/DEM/GSTMx2)

-   *\*Software Currently NOT Available\** Subrack Pipeline Path Test
    C - Data Transfer Test (refer to Test Flow Document, figure 14 - DEM
    providing SVX data) (Note: this test is NOT at speed)

-   *\*Software Currently NOT Available\** Subrack Pipeline Path Test
    D - Data Transfer Test with GSTM providing SRC commands (refer to
    Test Flow Document, figure 14 - DEM providing SVX data) (Note: this
    test is NOT at speed)

1.  Additional tests required for production FIB

-   *\*Software Currently NOT Available\** - FINISAR light output
    monitoring (if required)

-   *\*Software Currently NOT Available\** - FIB to FFO status

## 2.9 Testing FFOs

FIB Fan-Outs are an integral part of the FIB tests. Most of the FFO
functionality is tested with these tests. However, there are FFO
specific tests that can assist with debugging the FFO.

## 2.10 Testing FTMs

All FTM tests require the use of a FIB and DEM.

All tests require the use of a FIB because the FTM has no VME accessible
registers and is only a level translator for signals into and out of the
FIB. The only adjustable parts on board are the delay lines used to
extract the Odd-Byte-Data-Valid signal. The values of the delay lines
will be determined in the prototype testing and individual variations
from these values will be detected during data quality tests. The DEM
can generate Fiber Optic Port Card data to feed the FTM and FIB.

# **3** Integration Tests

## 3.1 Testing FIBs

1.  FIB/FFO/VRB - Pipeline / Data Processing Tests using DEM with G-Link
    Data Transfers. (Hardware required: FIB/FFO/VRB)

-   Subsystem Pipeline Path Test A - Data Transfer Test (refer to Test
    Flow Document, figure 14 - DEM providing SVX data, VRB in checksum
    mode) (Note: test A is at speed)

-   *\*Software Currently NOT Available\** Subsystem Pipeline Path Test
    B - Data Transfer Test (refer to Test Flow Document, figure 14 - DEM
    providing SVX data, VRB SVX mode) (Note: this test is NOT at speed)

1.  FIB/FFO/VTM/PORT-CARD - Port Card Testing. (Hardware required:
    FIB/FFO/VTM/PORT-CARD)

-   Subsystem Control Path Test A - Port Card Control Cable Tests (see
    Test Flow Document, figure 16)

-   Subsystem Control Path Test B - Initialization Loop-back (see Test
    Flow Document, figure 17)

-   Subsystem Control and Pipeline Path Test A - Calibration Inject and
    Readout (refer to Test Flow Document, figure 17, and run full DAQ
    cycle with Calibration Inject).