# SVX Data Acquisition System Test Flow

J.Anderson, K.Woodbury, 2/19/97

\*\*\* DRAFT DOCUMENT - Last Revision: 2/19/97 \*\*\*

## Introduction

This document describes the tests that are performed on the various SVX
III data acquisition system modules. The focus of this document is to
differentiate between module-level (board checkout) tests and system- or
subsystem-level tests. The following definitions are assumed to apply
throughout this document:

-   A **module-level test** is one that exercises the internal features
    of a given PC board and does not require connection to any other
    board of the system to function. A module-level test may involve the
    use of external signal generators or other modules not part of the
    final system. Module-level tests usually require numerous cabling
    changes to perform and are not suitable for use in the field. A
    module-level test, upon receipt of error, attempts to isolate the
    error to a particular component or group of components.

-   A **subrack-level test** is one that exercises the interconnection
    between Modules that share the same backplane. A subrack-level test
    presumes that all Modules involved have passed their module-level
    test prior to the running of a subrack-level test. Upon receipt of
    an error, a subrack-level test attempts to isolate the error to a
    particular module, but no farther.

-   A **subsystem-level test** exercises the interconnection between
    subracks, or the interconnection between physically disparate
    modules. A subsystem test presumes that all modules and subracks
    involved have previously passed their respective lower-level tests
    prior to the subsystem test. Upon receipt of error, a subsystem test
    attempts to isolate the fault to the module level. Subsystem-level
    tests are used with a fixed cable plant and cannot require any
    cabling changes.

-   A **system-level test** exercises the entire system, including all
    subsystems. Upon receipt of error a system test attempts to isolate
    the problem to the subsystem or subrack level, but no farther.
    System-level tests are intended for the final cabling setup and
    cannot require cabling changes.

A test methodology must not only include the various printed circuit
boards within the system but also the interconnections between those
boards. A system constructed of perfectly functioning boards but bad
cables will fail just as thoroughly as one which has good cables but bad
boards. The subsystem and system tests should be designed such that
cabling errors may be differentiated from module or subrack errors. To
this end, Figure 1 shows the generic architecture of the SVX data
acquisition system and names the various devices and cables present.

Various types of software are written by different personnel. It is more
appropriate for the design engineer or the technician to code the
module-level tests as only they have the detailed knowledge at the bit
level required. Computer professionals are more suited to the subsystem
and system test programs that require a knowledge of how various modules
must work together. Figure 2 shows the assumed test flow from
module-level to system diagnostics and indicates which tests are likely
to be written by the different people.

This document describes the module-level and subrack-level tests being
developed in order to more fully define the requirements of the
subsystem and system test software. Note that obvious tests such as
"does the bus interface work" or "can the XX memory be written to and
read back" are omitted. Only tests that exercise specific architectural
features of modules are included.

# SRC Module-Level Tests

As of this writing, no information on SRC module level tests has been
received. It is assumed that Harvard takes the responsibility for
testing the SRC prior to integration into the SVX data acquisition
system.

# FIB Board Module-level Tests

FIB Module-level tests are all part of the diagnostic package being
written by Kerry. It is assumed that the I/O routines developed in the
course of writing the module-level diagnostics will be ported to the
subsystem and system-level tests. Obvious tests such as "does the VME
interface talk" or "memory read-write tests" are not included in this
document. Only those tests that exercise specific architectural features
of the module are described.

## Pipeline Test A - Data Pattern Check

This test puts test data patterns into the entry of the pipeline system
of the FIB, passes it through the pipelines, and checks that the data is
correctly passed. Grayed areas of Figure 3 are not exercised in this
test. Black areas of Figure 3 are exercised.

### Initialization Required Prior to Test

1.  Initialize Calculation Ram by loading in EOR section of memory. Load
    the Calculation Ram with a function where output = input.

2.  Load Pedestal RAM with all zeroes.

3.  Load test data pattern into SVX DATA FIFOs, including header.

### Test Procedure

1.  Force processor to run.

2.  Read output data from output FIFO and compare.

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

Figure 1

## Pipeline Test B - Pedestal Subtraction

This test repeats the sequence of Pipeline Test A, and in addition,
verifies that pedestal information is correctly subtracted from all data
that passes through the pipelines. Active sections of the FIB are
indicated in Figure 4.

### Initialization Prior to Test

1.  Initialize Calculation Ram by loading in EOR section of memory.
    Calculation Ram function is still output = input.

2.  Load Pedestal RAM with unique sequence of data for each channel such
    that expected output from each channel is unique.

3.  Load test data pattern into SVX DATA FIFOs, including header.

### Test Procedure

1.  Force processor to run.

2.  Read output data from output FIFO and compare.

![](media/image2.wmf){width="4.471527777777778in"
height="4.707638888888889in"}

Figure 2

## Pipeline Test C - Calculation RAM

This test repeats the sequence of Pipeline Test A, and in addition,
verifies that the Calculation Ram works. The active sections of the FIB
module are indicated in Figure 5.

### Initialization Prior to Test

1.  Initialize Calculation Ram by loading in EOR section of memory. Set
    Calculation Ram such that calculation function is output = 1's
    complement of input.

2.  Load Pedestal RAM with all zeroes.

3.  Load test data pattern into SVX DATA FIFOs, including header.

### Test Procedure

1.  Force processor to run.

2.  Read output data from output FIFO and compare.

![](media/image3.wmf){width="4.11875in" height="4.326388888888889in"}

Figure 3

##  Control Path Test A - Command FIFO

This test verifies that commands correctly load into the FIB command
FIFO.

### Initialization Prior to Test

1.  Enable command input from VME.

### Test Procedure

1.  Load single command into FIB command FIFO.

2.  Verify command loaded correctly.

![](media/image4.wmf){width="4.155555555555556in"
height="4.365972222222222in"}

Figure 4

## Control Path Test B - Log FIFO

This test verifies that commands correctly load into the FIB log FIFO.

### Initialization Prior to Test

1.  Enable command input from VME.

### Test Procedure

1.  Load single command into FIB command FIFO.

2.  Verify command is properly copied to log FIFO.

![](media/image5.wmf){width="4.1375in" height="4.365972222222222in"}

Figure 5

## Control Path Test C - Address Controller

This test verifies that commands loaded into the FIB command FIFO are
unloaded into the address controller.

### Initialization Prior to Test

1.  Enable command input from VME.

2.  Enable command processing.

### Test Procedure

1.  Load single command into FIB command FIFO.

2.  Verify command received by address controller.

![](media/image6.wmf){width="4.11875in" height="4.316666666666666in"}

Figure 6

## Control Path Test D - Command Output & Interrupt 

This test verifies that command output is properly presented to the FIB
Transition Module.

### Initialization Prior to Test

1.  Enable command input from VME.

2.  Enable command processing.

### Test Procedure

1.  Load single command into FIB command FIFO.

2.  Verify proper control signals presented to the FIB Transition Module
    using oscilloscope.

3.  Repeat procedure for all commands.

4.  Repeat again, placing interrupt commands in with normal. Insure that
    interrupts take priority over normal commands.

![](media/image7.wmf){width="3.988888888888889in"
height="4.209722222222222in"}

Figure 7

## Control Path Test E - SVX Initialization internal loopback

Verify that SVX initialization data is properly processed by using
internal loopback feature of FIB.

### Initialization Prior to Test

1.  Load initialization string into FIB Parallel/Serial FIFO.

2.  Set FIB to receive data into Serial/Parallel FIFO from internal
    loopback path.

### Test Procedure

1.  Transfer data from parallel/serial FIFO to serial/parallel FIFO.

2.  Pack the last partial data word from VME.

3.  Verify that data received by Serial/Parallel FIFO matches that
    loaded into Parallel/Serial FIFO.

4.  Verify that proper control signals are presented to FIB Transition
    Module using oscilloscope.

![](media/image8.wmf){width="4.053472222222222in"
height="4.268055555555556in"}

Figure 8

# FIB Fanout Module-Level Tests

The FIB Fanout Module-level tests are to be written by John Anderson. It
is presumed that the FIB Fanout tests will re-use all the I/O routines
developed by Kerry for the FIB tests, and that the FIB Fanout
module-level tests will be incorporated as part of the same software
package.

## Data Path A - Internal Loopback

This test uses the test FIFO of the Fanout to loop data back to the
error FIFO of the Fanout, verifying the internal data path.

### Initialization Prior to Test

1.  Load test data pattern into Test FIFO.

2.  Force error.

3.  Set Fanout to Run mode

### Test Procedure

1.  Verify that data stored in error FIFO matches that loaded into test
    FIFO.

![](media/image9.wmf){width="5.917361111111111in"
height="4.897222222222222in"}

Figure 9

## Data Path B - Error Detection

This test uses the test FIFO of the Fanout to loop data back to the
error FIFO of the Fanout. Different data patterns are used

### Initialization Prior to Test

1.  Load test data pattern into Test FIFO, consisting of both correct
    and incorrect SRC data patterns.

2.  Set Fanout to Run mode

### Test Procedure

1.  Verify that data stored in error FIFO starts with first intentional
    error placed in data stream.

2.  Repeat sequence for different error types, insuring that error
    decoder works for all fatal and non-fatal error conditions.

![](media/image10.wmf){width="5.917361111111111in"
height="4.897222222222222in"}

Figure 10

# FIB Subrack-Level Tests

These tests verify that the FIB and the FIB Fanout correctly work
together.

## Control Path Test A - Fanout to FIB Command FIFO

Test that commands generated by FIB Fanout are correctly received by
FIB.

### Initialization Prior to Test

1.  Load commands into Fanout test FIFO.

2.  Set Fanout into test mode.

### Test Procedure

1.  Verify proper commands received by interrogating FIB Command FIFO.

![](media/image11.wmf){width="2.348611111111111in" height="1.94375in"}

Figure 11

## Pipeline Test A - Output of Pipeline through the GLink

This test repeats the sequence of Pipeline Test A, but now checks that
the output data is emitted from the GLink optical drivers. Note that
this test requires an external device to receive the GLink data, like
the GSTM, the FIB Fanout or the VRB. The active sections of the FIB are
indicated in Figure 12.

### Initialization Prior to Test

1.  Initialize Calculation Ram by loading in EOR section of memory. Set
    Calculation Ram such that calculation function is output = input.

2.  Load Pedestal RAM with all zeroes.

3.  Load test data pattern into SVX DATA FIFOs, including header.

### Test Procedure

1.  Force processor to run.

2.  Read output data from receiving device.

3.  Compare data received to test pattern.

![](media/image13.wmf){width="3.654861111111111in"
height="3.8381944444444445in"}![](media/image14.wmf){width="2.0458333333333334in"
height="1.4541666666666666in"}

Figure 12

## Control Path Test B - Static Connection to FIB Transition Module

Static test of the connection to the FIB Transition Module and the
manual control path.

### Initialization Prior to Test

1.  Set output controller to accept VME data as opposed to normal
    command path.

### Test Procedure

1.  Verify that data written to Transition Module from VME is presented
    by using scope/analyzer.

![](media/image15.wmf){width="4.127777777777778in"
height="4.345833333333333in"}

Figure 13

# FIB Subsystem Tests

These tests verify the operation of the FIB & Fanout with the Port Card
and the SVX III chip.

## Control Path Test A - Port Card Control Cable Tests

Verify that port card control cables are controlling the DDR chips. Note
that the control bits are not directly read back but are indirectly
tested by observing the change in Output State of the DDR. If the DDR
Output State can be driven through a prescribed sequence of states, all
control lines are assumed to have proper connection.

### Initialization Prior to Test

1.  Enable VME control of the port card control cable.

2.  Enable VME read-back of SVX data.

### Test Procedure

1.  Step DDR through prescribed control sequence and read back DDR state
    through VME.

2.  Verify that data received by FIB correctly indicates control of DDR.

3.  Repeat steps 1 & 2 for second port card.

.

![](media/image16.wmf){width="4.6402777777777775in"
height="4.395138888888889in"}

Figure 14

##  Control Path Test B - External Initialization Data Loopback

Verify that SVX initialization data is properly processed by using
normal loopback provided by external system hardware.

### Initialization Prior to Test

1.  Load initialization string into FIB Parallel/Serial FIFO.

2.  Set FIB to receive data into Serial/Parallel FIFO from normal data
    input path.

### Test Procedure

1.  Verify that data received by Serial/Parallel FIFO matches that
    loaded into Parallel/Serial FIFO.

![](media/image17.wmf){width="4.116666666666666in"
height="4.070833333333334in"}

Figure 15

# VRB Module-Level Tests (2/5/97) (From Mark Bowden)

## Basic processor/logic tests (don't require VME or GSTM)

\- Simple program to blink front panel processor LED (test of compiler,
assembler, Flash memory programmer, Altera 7064 programming, processor
and parallel port logic) **DONE**

\- Output RS232 serial messages (used for diagnostics) **DONE**

\- Read and write dual-port memory from processor **DONE**

\- Program to download Control Logic FPGA (verified by blinking VME
access LED) **DONE**

-Program to download Receive Logic FPGAs **DONE**

## VME basic access tests

\- VME single word write and read to dual-port memory (A24/D16 and
A32/D16) in the range 0-3FFF (plus module base address), simple memory
test optional

\- Check that processor can transfer information to/from VME through
dual-port memory (and display on serial output), may require message
handshake mechanism.

## Control Logic application tests (VME)

\- Write "readout" message to VRB from VME (3 single word writes), VRB
should display message "processing READOUT message"

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

## VME scan tests

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

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

## VRB interrupts

\- 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)

# VRB Subsystem Tests

## Control Logic application tests (GSTM)

\- Repeat control logic tests using GSTM to send "readout" and "scan"
messages via VRB Fanout and J3 backplane. GSTM monitors "readout busy"
and "scan busy" status signals from Fanout module.

## VTM tests

\- Use the GSTM to drive VTM G-link input(s) and check Receive Logic
event recognition. For Version 0 VRB this will be a partial test with no
event format checking other than start and end of event. For Version 1
VRB event formatting is checked.

**VRB Control Registers**

The following VRB addresses are currently implemented. Others may be
added, depending on the application. These are offsets from the module
base address.

All registers are 16 bit, single word read/write and should be accessed
using either A32/D16 (AM = 09) or A24/D16 (AM = 39). The VRB address
space is 0-3FFF.

0-1F are control registers

0 module type code, read only (VRB = 3)

2 VRB control (no bits implemented yet)

4 global byte count for Scan, read only

6 global status, read only

20-3F are message registers

20 not used

22 Readout Buffer Number (value = 0-31)

24 Pipeline Capacitor Number (value = don't care)

26 Bunch Crossing Number (value = don't care)

28 Scan Buffer Number (value = 0-31)

2A Event Number (value = don't care)

2C-3E reserved

40-42 are for the monitor FIFO

40 monitor channel (value = 0-9)

42 byte count

1000-1FFF are for VME/processor communication. This is not yet
implemented but is intended to be a space where we can download (through
VME) a new program, or set of VRB default values. These would then be
written by the VRB on-board processor into its flash memory.

2000-2FFF are used internally by the VRB for control information. They
would only need to be read through VME for diagnostic purposes.

3000-3FFF are used internally by the VRB for processor local storage.
They would only need to be read through VME for diagnostic purposes.

**VRB Output Data Register**

There is only one register accessible for VRB data output. This should
be read in block transfer mode only, using A32/D32 (AM = 0B) or A32/D64
(AM = 08) or A24/D32 (AM = 3B) or A24/D64 (AM = 38).

0 VRB Output Data FIFO

Note: the address is not important. Any access to the VRB using the
above four AM codes, regardless of address, will access this register.

**VME Operation**

**Readout Loop**

1\) Poll the Status register (6) until "readout busy" (bit 0) is low

2\) Write the Buffer Number (0-1F) to the Readout Buffer Number register
(22)

3\) Write the PLC Number (xx) to the Pipeline Capacitor Number register
(24)

4\) Write the BC Number (xx) to the Bunch Crossing Number register (26)

**Scan Loop**

1\) Poll the Status register (6) until "scan busy" (bit 1) is low

2\) Write the Buffer Number (0-1F) to the Scan Buffer Number register
(28)

3\) Write the Event Number (xx) to the Event Number register (2A)

4\) Poll the byte count register (4) until the value is non-zero

5\) Use the byte count to block read the output data register (0)

**SRC (GSTM) Operation**

**Readout Loop**

1\) Wait for "readout busy" (bit 0 of the 10 bit status bus) low

2\) Write the Buffer Number (100 - 11F) to the command bus

3\) Write the PLC Number (2xx) to the command bus

4\) Write the BC Number (3xx) to the command bus

Optional (concurrent FIB/GSTM Loop)

1\) Write data to GLink receivers on VTM (this could be simulated by
VRB)

**Scan Loop**

1\) Wait for "scan busy" (bit 1 of the 10 bit status bus) low

2\) Write the Buffer Number (400 - 41F) to the command bus

3\) Write the Event Number (5xx) to the command bus

Optional (concurrent VME Scan Loop)

4\) Poll the byte count register (4) until the value is non-zero

5\) Use the byte count to block read the output data register (0)

Note: Readout and Scan loops are independent. Polling the status
register or waiting for status bus bits can be deleted from the test
loops (open loop testing) if enough time is allowed between cycles for
the operation to complete.