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)
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
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
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
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
6-8 EPC2 EEPROMs
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
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').
L1 Algorithm (Yves,Andre')
Internal bus (Yves,Andre') planned to basically copy
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
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.