![](media/image1.png){width="0.7916666666666666in"
height="0.8958333333333334in"}

> Fermilab/AD/TEV
>
> Beams-doc-1499-V0

December 10, 2004

Tevatron Beam Position Monitor (BPM) Upgrade

Timing Generator Fanout Module, Filter Card and Integrated Crate Test
Plan

**Dehong Zhang, Luciano Piccoli, Bill Haynes, Ken Treptow, Jim Steimel,
Vince Pavlicek, Tim Kasza**

# Introduction

This document specifies the test plan for the standalone quality control
(QC) tests performed by the CD prep group for the Timing Generator
Fanout (TFG) modules and Filter Cards (FC) as well as the integration
tests performed on the fully assembled and cabled crates before they are
taken to the Tevatron service buildings. It is often logical to modify
the original qualification criteria. However, justifications of such
changes and modified test results should be included in this document.

# Timing Fanout Generator Stand-alone QC Test plan 

**Introduction**

The Timing Generator Fanout is a Double Width VME card's main function
is to provide a precision phase locked clock and Sync pulse (or Gate) to
each of the EchoTek digitizers of the Beam Position Monitor (BPM)
system. Also, the TGF provides a high resolution time stamp and can
generate VME interrupts based on 16 different TCLK events. The Clock
fanout section of the TGF requires only power from VME to operate and
can by tested independent of the operation of the FPGA controlled timing
section. After the usual verification that power/ground plane shorts do
not exists, proceed as follows:

**Equipment and setup needed for the stand alone quality control test:**
![](media/image2.jpeg){width="0.7888888888888889in"
height="5.538194444444445in"}

1.  VME64X crate.

2.  Motorola MVME2400 processor board.

3.  VME Console Terminal.

4.  Frequency Counter, Spectrum Analyzer or Oscilloscope.

5.  Various cables.

**Test procedure**

**Step 1: Clock fanout section**

1)  Insert the module into an un-powered VME Crate. Turn on the crate
    power and the 5.0v & 3.3v LEDs should turn on.

2)  Connect an RFCLK (53Mhz clock) source to the RFCLK input and note
    the LED labeled RFCLK should turn on. The LED turns on when the
    internal PLL locks to the RFCLK and produces an output clock
    multiplied by a 7/5 ratio.Since the RFCLK is generally 53.10468MHz
    then the output clock is 74.34655MHz.

3)  Connect a frequency counter, spectrum analyzer or oscilloscope to
    the

> CLK0 output connector. In general an oscilloscope is adequate to test
> the clock fanout circuit for functionality but a frequency counter or
> spectrum analyzer should used occasionally to measure that the locked
> output frequency is precisely 74.34655MHz (unless there is beam being
> accelerated in the main ring). If a spectrum analyzer is being used,
> any side band noise should be attenuated by least 50dbm.

4)  Compare the remaining CLK1 - CLK7 to CLK0.

**Step 2: FPGA Controlled Section**

The FPGA section consist of the VME interface, the BSync decoder and
TClk Decoder to control Sync pulses the the EchoTek digitizers and
interrupts to the VME CPU.

1)  First the FPGA firmware must be downloaded to the TGF via the Front
    JTAG port using the Quartus programmer software. The firmware file
    name is "bpmfanout.pof" and takes about 5 minutes to download.

2)  Set the pc board eight position dip switch to all "on" except for
    switch position 2 being set to "off". This gives a VME base address
    of 0x2000.

3)  Check to see if the VME select LED flashes during a read to VME
    address 0x2000 using the TGF diagnostic software.

4)  Run the TGF diagnostic software "runTimingTest" for the remaining
    tests.

5)  Select menu item \# 0 to verify all the TGF registers are readable
    and writeable from VME.

6)  Connect BSync to its front panel input and note that the BSync LED
    turns on.

7)  Connect TClk to its front panel input and note that the TClk LED
    turns on.

8)  Select the BSync Test menu item \# 1 of TGF diagnostic software.
    This checks the BSync event interrupts to the VME CPU with all the
    events required in the full BPM System.

9)  Select the TClk Test menu item \# 2 of the "TGF diagnostic
    software". This checks TClk event interrupts to the VME CPU based on
    the decoding of specific TClk events and requires TClk to be
    connected to the TGF card. This test will try several combinations
    of TClk events interrupts and report success or failure.

10) Select the BSync Test menu item \# 3 of TGF diagnostic software.
    This test uses the BSync revolution marker (0xAA) for generating the
    trigger and Sync output pulses. Connect the front panel TRIG1 (TEST
    on prototype card) to an oscilloscope trigger input and verify that
    each of the Sync(0-7) outputs generate one pulse per trigger. The
    output pulse of Sync0 will be generated first, followed by output
    Sync1, then Sync2, thru to Sync7. Each of the pulses is evenly
    spaced through one revolution of the beam (\~21us).

11) Select the Wait TClk menu item \# 4. User inputs a particular TClk
    event (decimal) to be decoded. If the TClk event is not decoded in
    30 seconds an error is reported.

12) Run the "TGF diagnostic software" TimeStamp test. This test will
    measure the time interval from a BSync Clear event to the first
    TurnMarker after a Start event. This time interval is based on a
    106Mhz counter and should be the same for each TGF card.

13) Run the "TGF diagnostic software" FilterCard test. This test will
    permit individual relays within the Filter card to be set or cleared
    via the VME backplane. Writing a "01" to channel0 should be an
    adequate enough test to show that the TGF can communicate with the
    Filter Card. This command would close the contacts of the relay
    connecting the diagnostic signal (53Mhz) to the BPM Channel0 output
    of the Filter Card. If Channel0 is connected to an oscilloscope,
    then the 53Mhz signal would appear after the value is written.

14) To write to a particular TGF register outside the diagnostic
    software: setTSGRegister offset, value\
    Note: offset and value are in standard hex format, for example
    0x102, 0x0203.

15) To read to a particular TGF register outside the diagnostic
    software: getTSGRegister offset\
    Note: offset is in standard hex format, for example 0x102.

16) This concludes the incoming production tests and qualifies the card
    for system level tests.

# 

# Filter Card Stand-alone QC Test plan 

**Introduction**

The Filter Card is a single width VME64X card. The Filter Card obtains
5V, 12V, -12V power, SYSCLK, and interfaces to the Timing Generator
Fanout (TGF) via reserved bussed pins from the VME crate. The Filter
Cards main function is to filter and attenuate the signal from the TeV
BPM sensors going to the Echotek digitizers. It also allows via relays
for a diagnostic signal to be sent to the Echotek, the BPM sensor, or
both. The TGF card controls this through its VME interface.

**Equipment and setup needed for the stand alone quality control test:**

6.  VME64X crate.

7.  Motorola MVME2400 processor board.

8.  Two Echotek ECDR-GC814-FV-A modules.

9.  Timing Generator Fanout card.

10. VME Console Terminal.

11. Agilent 4395A Network Analyzer and 87511A S-Parameter Test Set.

12. Various cables.

It requires two external inputs: Ethernet access to the 253 subnet of
FCC for the PPC processor and the 53.1 MHz Tevatron RF clock for the
TGF.

Here the TGF serves 3 purposes:

1.  Interface to the filter board to control the relays;

2.  Generate the 53.1 MHz diagnostic signal on the VME back plane;

3.  Generate the 74.3466 MHz clock signal for the Echotek boards.

One of the Echotek boards serves as the down-stream digitizer, while the
other as fake pick-ups up-stream to monitor the signals sent back to the
BPM pick-ups.

The PPC processor boots from "fndaut", and can save test results to
"/usr/devel/area2/vxworks/filter_board_test" on "fndaut". The loadable
modules, Echotek setup files and the startup script can be found in:
"/usr/products/devel/vxworks/tbpm_filter_board_test" on "fndaut".

Here is a picture of the setup, except for the VME console terminal.

![](media/image3.png){width="4.749305555555556in"
height="4.749305555555556in"}

**Test procedure:**

**Step 1: Visual Inspection and Initialization**

1.  Visually inspect the card for damage, solder shorts, or missing
    components.

2.  Verify with an ohmmeter that there are no power to ground shorts.

3.  Insert the card into an un-powered VME64X crate. Turn on the crate
    power and the 5V, 12V, and --12V LEDs should turn on.

4.  Download the FPGA firmware (bpmfc_control.pof) via the JTAG port
    using the Altera programmer software and an Altera ByteBlaster cable
    or equivalent.

**Step 2: Diagnostic Signal Test**

**Description of the tests**

Currently, we foresee to perform 3 tests on each production filter
board. First we set the TGF to generate the 53.1 MHz diagnostic signal,
then:

1.  Set the TGF to switch all the 8 relays on the filter board to "ADC",
    or

2.  Set the TGF to switch all the 8 relays on the filter board to "BPM",
    or

3.  Set the TGF to switch all the 8 relays on the filter board to "ADC
    and BPM"

Next we software trigger the Echotek boards to digitize and analyze the
signals they receive, then read out the Echotek boards to check the 53.1
MHz components against some predetermined range (minimum -- maximum)
criteria.

The software for these tests is actually a merge and adoption of the
multi-board test for the Echotek driver and the PREP filter test for
quality control of the production Echotek boards. The core part is the
setup file for the Echotek boards.

We took "DDC_board_test.ch" from the PREP filter test, modified the
following parameters:

1.  Clock rate from "80 MHz" to "74.3466 MHz";

2.  NCO frequency from "3 MHz" for an over-sampled 3 MHz input to
    "21.2418857 MHz" for an under-sampled 53.1047 MHz input;

3.  RCVR_DATA_SKIP from "0" to "18" to skip the transient effect;

4.  OUTPUT_WORD_SIZE from "6B" to "2B" to force one RCVR_DATA_SKIP to
    correspond to one BURST_COUNT.

With this setup, the Echotek boards would digitize the 53.1 MHz
diagnostic signals at 74.3466 MHz, down-convert their images at
21.2418857 MHz to DC, decimate and filter out frequency components
beyond +/- 0.26 MHz. The total decimation is 16. The overall frequency
response is shown in the following plot:

![](media/image4.png){width="5.834027777777778in"
height="4.375694444444444in"}

For each test, we take 64 samples from each channel and find the minimum
and maximum. The current cut-off range criteria are as follows:

  ------------------- -------- -------- -------- -------- -------- --------
  ECDR Channel        ADC               BPM               ADC &    
                                                          BPM      

                      min      max      min      max      min      max

  Proton ADC          1200     1600     0        50       700      1000

  Pbar ADC            4000     5000     0        50       2300     3000

  BPM Pick-up         0        50       14000    18000    9500     13000
  ------------------- -------- -------- -------- -------- -------- --------

The 2 Echotek boards are set to A16 addresses of "0xc000" \-- the one on
the left, the "ADC", and "0xd000" -- the one on the right, the fake
BPMs, while the filter board is set to index "0".

**Testing procedure**

1.  Set the filter board to index "0", insert into the crate, make sure
    it has seated properly;

2.  Connect the 8 output cables straight across horizontally to the
    corresponding input connectors on the Echotek board on the left --
    the ADC board;

3.  Connect the 8 input cables slightly slanted to the corresponding
    input connectors on the Echotek board on the right -- the fake BPM
    pick-ups;

4.  Power on the crate, watch for the boot process, in the end there
    will be 3 times rather loud "pop" sound, while the PPC prints to the
    console screen like the following:

Filter Board Test -\>RunTests

0x1da441c0 (tShell):

0x1da441c0 (tShell): Diagnostic 53.1 MHz ==\> ADC

0x1da441c0 (tShell): Channel 1: 35 34 35 \-- BAD !!!

0x1da441c0 (tShell): Channel 2: 35 34 35 \-- BAD !!!

0x1da441c0 (tShell): Channel 3: 34 33 34 \-- BAD !!!

0x1da441c0 (tShell): Channel 4: 32 32 33 \-- BAD !!!

0x1da441c0 (tShell): Channel 5: 31 30 31 \-- BAD !!!

0x1da441c0 (tShell): Channel 6: 34 34 35 \-- BAD !!!

0x1da441c0 (tShell): Channel 7: 33 32 34 \-- BAD !!!

0x1da441c0 (tShell): Channel 8: 36 35 36 \-- BAD !!!

0x1da441c0 (tShell): Channel 9: 20 19 22

0x1da441c0 (tShell): Channel 10: 22 21 24

0x1da441c0 (tShell): Channel 11: 28 27 29

0x1da441c0 (tShell): Channel 12: 26 25 27

0x1da441c0 (tShell): Channel 13: 14 13 15

0x1da441c0 (tShell): Channel 14: 14 13 15

0x1da441c0 (tShell): Channel 15: 19 18 20

0x1da441c0 (tShell): Channel 16: 19 18 21

0x1da441c0 (tShell):

0x1da441c0 (tShell): Diagnostic 53.1 MHz ==\> BPM

0x1da441c0 (tShell): Channel 1: 34 33 35

0x1da441c0 (tShell): Channel 2: 35 34 35

0x1da441c0 (tShell): Channel 3: 34 32 34

0x1da441c0 (tShell): Channel 4: 32 30 33

0x1da441c0 (tShell): Channel 5: 30 29 32

0x1da441c0 (tShell): Channel 6: 34 34 35

0x1da441c0 (tShell): Channel 7: 33 32 34

0x1da441c0 (tShell): Channel 8: 36 36 37

0x1da441c0 (tShell): Channel 9: 20 18 23 \-- BAD !!!

0x1da441c0 (tShell): Channel 10: 21 20 23 \-- BAD !!!

0x1da441c0 (tShell): Channel 11: 28 27 29 \-- BAD !!!

0x1da441c0 (tShell): Channel 12: 26 25 27 \-- BAD !!!

0x1da441c0 (tShell): Channel 13: 14 13 15 \-- BAD !!!

0x1da441c0 (tShell): Channel 14: 14 12 15 \-- BAD !!!

0x1da441c0 (tShell): Channel 15: 19 18 21 \-- BAD !!!

0x1da441c0 (tShell): Channel 16: 19 17 22 \-- BAD !!!

0x1da441c0 (tShell):

0x1da441c0 (tShell): Diagnostic 53.1 MHz ==\> ADC and BPM

0x1da441c0 (tShell): Channel 1: 34 34 35 \-- BAD !!!

0x1da441c0 (tShell): Channel 2: 35 34 35 \-- BAD !!!

0x1da441c0 (tShell): Channel 3: 34 33 35 \-- BAD !!!

0x1da441c0 (tShell): Channel 4: 32 32 34 \-- BAD !!!

0x1da441c0 (tShell): Channel 5: 31 30 32 \-- BAD !!!

0x1da441c0 (tShell): Channel 6: 34 34 35 \-- BAD !!!

0x1da441c0 (tShell): Channel 7: 32 32 34 \-- BAD !!!

0x1da441c0 (tShell): Channel 8: 36 35 37 \-- BAD !!!

0x1da441c0 (tShell): Channel 9: 20 18 22 \-- BAD !!!

0x1da441c0 (tShell): Channel 10: 22 20 23 \-- BAD !!!

0x1da441c0 (tShell): Channel 11: 28 27 30 \-- BAD !!!

0x1da441c0 (tShell): Channel 12: 26 25 27 \-- BAD !!!

0x1da441c0 (tShell): Channel 13: 15 14 15 \-- BAD !!!

0x1da441c0 (tShell): Channel 14: 14 13 16 \-- BAD !!!

0x1da441c0 (tShell): Channel 15: 20 19 21 \-- BAD !!!

0x1da441c0 (tShell): Channel 16: 19 17 20 \-- BAD !!!

0x1da441c0 (tShell):

0x1da441c0 (tShell): This board FAILed the tests !!!

> Where the last printout should declare the board to have passed or
> failed the tests. If the board fails, please check the cable
> connections, and re-run the tests by typing "RunTests" on the console
> keyboard;

5.  Type 'save "Serial No"' on the console keyboard to save the test
    result in "/usr/products/devel/vxworks/tbpm_filter_board_test" on
    "fndaut". The file will have a name like 'Board\_"Serial No".txt',
    and read like the following (from a different test than the above):

FRI DEC 03 14:44:55 2004

\-\-\-\-\-\-\-\-- FAIL \-\-\-\-\-\-\-\--

======================================================

Diagnostic 53.1 MHz ==\> ADC

Check criteria:

Proton ADC 1200 \-- 1600

Pbar ADC 4000 \-- 5000

Pick-up 0 \-- 50

Proton & Pbar Pick-up

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

mean min max mean min max

Channel 1: 1424 1423 1426 27 25 29

Channel 2: 1393 1392 1394 26 25 28

Channel 3: 4287 4286 4288 30 29 31

Channel 4: 4119 4117 4120 29 27 29

Channel 5: 1330 1329 1332 16 14 18

Channel 6: 1363 1362 1364 19 18 21

Channel 7: 4503 4502 4505 24 23 26

Channel 8: 4535 4533 4536 22 20 24

======================================================

Diagnostic 53.1 MHz ==\> BPM

Check criteria:

Proton ADC 0 \-- 50

Pbar ADC 0 \-- 50

Pick-up 14000 \-- 18000

Proton & Pbar Pick-up

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

mean min max mean min max

Channel 1: 17 16 18 16239 16218 16257

Channel 2: 17 16 18 15972 15952 15991

Channel 3: 16 15 17 15650 15633 15666

Channel 4: 19 18 19 15021 15006 15036

Channel 5: 15 14 16 15057 15045 15073

Channel 6: 14 12 15 15652 15640 15672

Channel 7: 10 8 11 16091 16077 16112

Channel 8: 9 8 10 16308 16292 16331

======================================================

Diagnostic 53.1 MHz ==\> ADC and BPM

Check criteria:

Proton ADC 700 \-- 1000

Pbar ADC 2300 \-- 3000

Pick-up 9500 \-- 13000

Proton & Pbar Pick-up

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

mean min max mean min max

Channel 1: 859 858 861 11174 11159 11188

Channel 2: 830 829 831 11048 11033 11062

Channel 3: 2562 2560 2563 10859 10842 10872

Channel 4: 2457 2456 2459 10397 10383 10407

Channel 5: 794 793 795 10403 10392 10415

Channel 6: 813 811 814 10824 10814 10836

Channel 7: 2680 2679 2682 11150 11140 11164

Channel 8: 2707 2705 2708 11309 11299 11323

Step 3: **Through Response (S21) Test**

1.  Using the Agilent 4395A with the S-parameter test set, measure the
    magnitude and phase difference between channel pairs. Calibrate to
    one channel and measure and record the difference of the second.

2.  Repair out of spec channels.

# VME Crate Integration Test

Once the VME crate is stuffed with individual boards, loaded with
appropriate firmware, following test procedures are performed. The
objective of this test procedure is to fully qualify the crate before
taking it to the assigned service buildings.

**Equipment and setup needed for the stand alone quality control test:**

**Test procedure:**

**Step 1: Check ...**

***Goal:***

Goal of the testing ...

***Equipment and HW/SW setup needed for the stand alone quality control
test***

***Pass/fail Criteria:***

***Performer:***

**Step 2: Check ...**

(Repeat steps as necessary)

# 

***Test result documentation (spreadsheets, screen captures etc. and
their on-line locations)***

# Change Log 

  ------------- ------------ ------------------------------------------------
  **Version**   **Issue      **Description of Change**
                Date**       

  1.0                        Original

                             

                             
  ------------- ------------ ------------------------------------------------

# Concurrence

Following persons reviewed and concurred with the content of this
document.

Steve Wolbers, Project Manager (date)

Bob Webber, Deputy Project Manager (date)

Vince Pavlicek, Subsystem manager (date)