Minutes 23/01/01 (RAL)

Present: A. Baird, Y. Fleming, P. Newman, D. Sankey, A. Schoening, M. Siyad, S. Taghavirad

The main decisions made at the meeting are listed below, along with notes on responsibilities and schedules.

Hardware Issues for Prototype Front End Modules

For the 6 prototype boards, we will buy APEX 20k400E for the front FPGAs. The earlier idea to buy some 20k600 for prototypes as well is now thought to be unnecessary, though the board design will still be able to house the 20k600. Adam agreed to order the FPGAs for the prototypes imminently through RAL. The list price is currently $941 per chip.

The logic to be housed in the back FPGA is minimal (2 ESBs for FIFOs?). The choice of chip is mainly determined by the pin count. A preliminary estimate is given below. Adam agreed to make a precise pin count (depends on exact board design, see below). Then the final choice will be made based on data sheet comparisons.

Preliminary estimated pin count for back FPGA:
40 L1 input (5*8)
80,100,200 L2 input depends on design (2xbus, pp mux, pp - see below)
120 2 channel links out
50 first ZBT RAM (validator)
60 second ZBT RAM (lookup)
40 VME
10 control/trigger

Conclusion: 500 does not fit into 20K400. 400 I/O pins would fit into an APEX20k300 (408 I/O pins).

Remark: If we take point to point connections for L2, the same lines could be used as for L1 (see below)! That saves about 40 I/O pins. Then everything would fit into the 20K300!

Connections between Front and Back FPGAs:
Logically (and possibly physically?) two different type of connections are needed between the front and back FPGAs:

(A) for 16 trigger elements during L1 active
Connection has to be point to point. Back FPGA serves as Merger and IO controler. Agreed on 5 times 8 bit@40(80)MHz

(B) 36 bit track segments during L2 active
The connection between the front and back FPGAs is not defined yet. Two different proposals were discussed:
1) 36 or 2*36 bit bus @ 80 MHz
Appealing since only a few lines are needed, but adds complexity to the design. Input bandwidth is 5.8Gbit/s.
2) Point to point connections from all front FPGAs to the validator at 80MHz.
Andre proposed a multiplexing in order to save pins e.g. 5 times 36/2bit@80MHz.
More lines / pins needed than in option 1, but the design is less comlex. Input bandwidth is 7.2Gbit/s

The question of location on the board of the back FPGAs was dicussed. Adam wants the same routing path lengths for all interconnections between the front and back FPGAs. This would imply locating the back FPGA near to the middle of the board. One drawback to this approach was identified, in that the channel link connectors are in the lower part of the card, which would require a long path length between the LVDS transceiver and connector, running at high frequency. Ideally, the LVDS tranceiver should be near to the back FPGA.

Speed of FPGA interconnects:
The question of 80MHz or 100MHz between front and back FPGA was discussed. The preference was for 80MHz because that speed nicely fits with the existing clock frequencies (20,40,80) as used in the front FPGA.
The wish was expressed to have a separate clock driver for the rear part of the board (FPGA interconnections, back FPGA, channel link), even though the same fequencies are used as for the front part.

Transmission times are a big issue for L1. High clock speeds (>=40MHz) are advantageous.
For L2, transmission times should not be longer than those for receiving track segments at level 2. It is planned to receive a maximum of 128 track segments within 1.28 mus per trigger layer. Per FEM not more than 50 validated track segments are expected (from simulation).
Channel link operated at 40Mhz gives 1.25 mus (ok!)
Validator input is twice as big (rejection rate=50%) -> ZBTRAM has to be operated at 80MHz minimum (ok!)
FPGA interconnections need a minimum unvalidated track segment transfer rate of 80MHz (ok for both proposals!)

The 20k30A will be used for the VME interface FPGA. It is loaded by its own EPC1.

Adam has chosen Micron ZBTRAM for the validator and refinement RAM connected to the back FPGAs. For safety, slightly larger sizes are chosen for this than previously estimated. The final decision is 1024 x 16 for the validator and 512 x 32 for the refinement.
The refinement lookup ZBTRAM is operated at channel link frequency. The validator ZBTRAM is operated at 80 MHz (or possibly 120?).

The analogue part of the design is already in the drawing office. Adam has already ordered 8 bit dual FADCs. We discussed changing from the present specification (8 bit FADCs) to 10 bit FADCs for series production. There is a preliminary data sheet on the web for 10 bit FADC (AD9218). Dave does not expect a significant improvement in performance and is worried about extra power consumption (0.5W per chip). This question will be answered after testing the prototypes

4 EPC2 EEPROMs are needed for loading all 5 front FPGAs (common). 2-4 EPC2s are needed for the back FPGAs.

Final count of components discussed per FEM:

5 APEX20K400 front FPGAs (segment finding)
1 APEX20K?00 back FPGA (validator / refiner)
1 20K30 VME interface FPGA
1 1024 x 16 ZBTRAM (validator)
1 512 x 32 ZBTRAM (refinement)
15 dual 8 bit FADC AD9288

Software Design

It was agreed to follow the same software design rules as used by SCS:
flowchart-> process definition -> signal definition -> VHDL programming (one process, one entity) -> testing of entities -> testing of global design.
The (graphical) software design tool RENOIR was considered to be useful for VHDL programming and design. Availability at DESY is beeing to be checked.
It was proposed to allow only functions supported by Quartus, to make testing / interfacing of the different components easier.

The data format of the refinement information, as carried in the cyclic RAM and passed to the readout, is kept to 8 bits in total for each 20 MHz time slice:
2 bits - Refined timing information with 80 MHz synchronisation.
6 bits - z coordinate information. A z coordinate of 111111 will be used to code a single ended hit (i.e. hit present but z coordinate unknown). A z code of 000000 impplies no hits.

In the present implementation, a 9th bit coding the presence or absence of a hit within the 20 MHz slice is included in the shift register (built from logic cells) before it is copied to the cyclic RAM. This extra bit is probably redundant.

Calibration constants:
We will need dead wire information. For the z calculation, 3 parameters may be needed per wire (z0, offset, length). We may also need the relative gain of each wire.

The full VHDL code will be collected at DESY by Yves (and Andre'). Responsibitilites are:
QT (Mohammed,Dave,RAL)
L1 Algorithm (Yves,Andre')
Internal bus (Yves,Andre') planned to basically copy SCS scheme
ZBT RAM Interface (RAL)
back FPGA design (Yves,Andre', help from RAL may be needed for ZBTRAM interface)
VME IF (Dave Mercer)

Schedules and Uncovered Tasks

Details of the problems with the FEM schedule can be found in the minutes from 15 November 2000 . Since then, RAL-PPD has pushed the possibility of bringing in external manpower for the FEM, which has been rejected. Consequently, the current schedules deliver the FEM in August 2001, with probable completion of the full system around January 2002. However, there is no contingency in this schedule. Ken Peach has stated that the present schedule is unacceptable. Dave S has agreed to talk more with Ken and Bill Haynes. The H1 FTT is currently being given joint top priority with the generic ADC / FPGA card.

In the event that the current schedule cannot be improved, the earliest that a prototype board could be sent to DESY is around 20 June. The board would have undergone JTAG tests only by that point. This would be just in time for the cosmic tests assuming the recently announced 2 week delay in the overall HERA schedule.

An experienced PhD student or postdoc is still needed to write the readout code. This should not be a huge task, as the existing code for the LAr trigger readout could be taken as a starting point.

Compiled by P. Newman and A Schoening, 31/1/01.