tsf prototype hardware design changes since cdr prototype tests in manchester towards production...

12
TSF Prototype Hardware Design Changes Since CDR Prototype tests in Manchester Towards Production Boards SDK 11th April 2003

Upload: barbara-berry

Post on 29-Jan-2016

220 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

TSFPrototypeHardware

Design Changes Since CDR

Prototype tests in

Manchester

Towards Production BoardsSDK 11th April 2003

Page 2: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

Slide 2CD

R

ZPD requires additional fine-output from stereo layers… this forces a rebuild of the TSF.

Much of the spec stays the same, and parts of the existing design can be carried over.

Take this opportunity to make some improvements Improve fine- output from 5 to 6 bits Increase number of segments output

(1 per supercell => 3 per supercell pair)

Specification of new TSF

Page 3: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

Slide 3

What we plan to do

CDR

Use latest generations of devices to :

Increase density - combine functions of several devices on the original board to a single device.This is essential in some cases, eg simplifies segment selection for the ZPD output.

Increase logic speed - original TSF ran much of the logic at 30Mhz, can increase this to 60Mhz.

Use quicker signaling standards to move data faster across the board, and increase data rate across output pins

Page 4: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

Slide 4

Design Changes Since CDR

Original time constraints led to design compromises at CDR

Delays in funding gave us about 9 months extra

Used this time to reconsider some of the compromises forced by our original aggressive timetable, namely

Use Virtex II rather than Virtex E chips

Drop daughtercards, opt for integrated board

Also, thoroughly re-examined parts of the original TSF design that didn’t have to change because of the new spec, to adapt them to make best use of latest technology and methodologies.

Overall dramatic reduction in cost !!!!

Page 5: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

Slide 5

Data inward (Formatter)

ECL Receiver logic remains unchanged (backwards compatible)

Synchronisation FIFOs absorbed into FPGA

Memory controlled by local FPGA => neighbour data can be stored or replayed (full data sets replayed on single board standalone).

Memory can also be used for other things, eg histogramming or other monitoring of data etc would be possible - the FPGA has plenty of spare capacity (serious overkill).

Multidrop busses to engines replaced with point to point links.

Formatter FPGA selects data specifically for each engine FPGA

I/O performed on serial links

Page 6: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

Slide 6

Engines

Engines are (conceptually) the least changed parts of the design !

New engine FPGA replaces 2 of the old engine blocks, ie 6 or 7 of the old engine FPGAs

Engine FPGAs handle up to 32(27) engine cores in two pipelined banks of 16, each with a 36 bit external LUT memory accessed at 60Mhz

Wider LUT supports increased resolution and segment selection tags

Dual ZPD output on LVDS links (on prototype)

1st stage of BLT formatter function absorbed

I/O performed on serial links

Page 7: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

Slide 7

Fast Control/Operation/DAQ

Most radical re-design of the new board

Fast Control/Operation/DAQ/ZPD&BLT Formatter merged into single chip

I/O to other chips by serial links

External memories accessed only by local FPGAs

Single external RAM used to record (or replay) ZPD&BLT output data

DAQ FIFO is implemented internally (kills 70usec problem?)

Page 8: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

Slide 8

General features

Mainly unchanged from CDR Virtex II FPGAs 3.3V I/O (only) 1.5V core. DC-DC converters BGA memories. Can support 2.5V I/O, but stick with 3.3V. Firmware loaded by Xilinx ACE from compact flash, select from 8

loads by rotary switch Dual JTAG chains for FPGAs and Memories Comprehensive boundary scan test of assembly possible with

external test board. ‘Standard’ technology 10 layer, 6thou track & gap 0.3mm drill,

100% hand routed. Diagnostic headers to logic analyzer, also allow independent

JTAG. 1/2 depth of original board (200mm)

Page 9: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

Slide 9

TSF Testing at ManchesterThe tests so far

Late Dec 1st “1 Chip” prototype. This board was tested for JTAG chains. Just before Xmas (20th) this board was accidentally destroyed. 1st Week of Jan second “1 Chip” board assembled. Mid Jan 2 days of firmware tests.

FPGA loaded and talks to Mictor OK (pinout issues resolved) Error found on an enable line, patched Global Clock instantination problems fixed. LVDS instatination errors fixed – LVDS loopback tests to Fast Control OK Tests to external memory failed – suspected hardware problems

Early Feb “3 Chip” prototype assembled, and “1 chip” passes bscan. During Feb TSF test adaptor designed & produced Mid Feb test specification for “3 Chip and above” defined End of Feb memory problems understood on 1 chip – VHDL corrected Early March “3 Chip” prototype returns to assemblers for corrections Mid March “3 Chip” board passes boundary scan, inc. I/O

Page 10: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

Slide 10

TSF Testing at ManchesterBoundary Scan

BGA footprints as used on our FPGA and memory chips are not susceptible to easy optical inspection. Boundary scan is an ideal tool to verify correct assembly.

We have a JTAG Technologies system, comprising test developer software with a 4 port 3V3 boundary scan controller

We had planed to use this as a tool for testing the production boards – lwe were reluctant to use it for the partially populated prototypes because of the extensive low level editing of the netlist & configuration files this requires. However, prompted to use the system to investigate the suspected hardware faults on the “1chip” prototype.

TSF test adaptor developed which allows full testing of I/O path by boundary scan tools.

Boundary scan knows nothing about special I/O standards – this leads to problems with the LVDS signals – pairs driven by discrete drivers cannot be tested (boundary scan is NOT a substitute for firmware testing)

Page 11: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

Slide 11

TSF Testing at ManchesterProduction/Repair Test Plans

1st test of newly assembled production boards will be boundary scan. Tests ready (will have to be adapted to final netlist, few days work). The hardware required for external I/O tests is ready.

2nd test is a firmware based ‘internal test’. This tests internal connections at full speed and above. It will always be possible to run these tests on the board (will occupy one of the firmware ‘slots’). Firmware specified and being prepared.

3rd test will be firmware tests that require the test adaptor hardware, specifically to test the ZPD output and fast control I/O. Could also be used for pattern testing in experiment (eg TSFi/ZPDi/ZPD in corresponding test mode ??). Firmware specified and being prepared.

Page 12: TSF Prototype Hardware  Design Changes Since CDR  Prototype tests in Manchester  Towards Production Boards SDK 11th April 2003

Slide 12

Steps towards Production

So far we have only seen minor faults on the prototypes... An enable the wrong polarity Error in Mentor map file inverting an LVDS pair

Some small improvements in mind (tinkering) Some design issues (luxury items) need to be resolved

LVDS Muxes on ZPD output “Auxiliary” logic on some I/O (BLT, Dlink)

No known deficiencies in the hardware resources required by the Firmware... (ie design is “fit for purpose”)

Low level hardware testing by boundary scan in place. However, the next two months are critical…..