1. JET Algorithm Attila Hidvégi

2. Overview FIO scan in crate environment JET Algorithm –Hardware tests (on JEM 0.2) –Results and problems –Ongoing work on jet code Other work in Stockholm Summary

3. FIO scan in crate environment (one of two JEMs)

4. Delay scan for individual FPGAs

5. Delay scan for two JEMs (same deskew clock settings)

6. It is important to equalize timing between JEMs

7. Hardware tests of Jet algorithm Originally only jet multiplicities recorded; insufficient for diagnostics. New firmware was needed. All inputs and outputs needed to be recorded. Same spy memory and software as for FIO scan. JET Spy memory Data in Configurations

8. JET Algorithm – Results All input data is received properly (↕). Synthesis tool reports maximum delay of 11.2 ns and 26.4 ns, for 80 and 40 MHz clocks, respectively. This is the maximum achievable result for current VHDL code. Results from hardware tests show random errors!

9. Most likely cause of the problem Only adders still use 5-bit serial arithmetics –Virtex architecture more suited to parallel arithmetic with fast- carry chains. Adders are the slowest component of the algorithm. The errors are intermittent, suggesting timing problems –Sums occasionally wrong. –Sometimes cause incorrect threshold passes –More often give wrong ROI positions for random data The timing problem of the adders can not be resolved without a major rewriting. JET algorithm is being rewritten from scratch.

10. New design for the Jet code It will be flexible. Generic variables will decide the configuration. Try to minimize size and latency. The code has to be short, so that one can modify it easily. Use only parallel arithmetics, and take full advantage of the fast carry architecture available in Virtex FPGAs. Let the synthesis tool do the hard work. All the parts have to be tested VERY carefully so we really get what we expect. It needs to work…

11. Making it flexible means:

12. What could be done better ? Putting all summations and the local maximum finder in the first clock cycle allows us to remove the pipelines. 1 2*2, 4 3*3, 1 4*4 and 1 2-bit position Input 77 jet elements Latch 55 1* 3 60 2* 2 Comparator 1 60 2* 2 Latch 60 2* 2 Latch 32 2* 2 Latch 45 3* 3 Latch Mux(A) Latch AL<BLAL<BL 32 2* 2 32 4* 4 45 3* 3 Local maxima positions select Add(1) Add(2) Add(3)

13. What could be done better ? It is important to remember that multiplexers (2:1), adders and comparators have equal sizes, since they use the same logic resources. 1 of 8 Sub-region Components 1 2*2, 4 3*3, 1 4*4 and 1 2-bit position 1 of 8 threshold definitions Mux(B) 4 3*3 Ma x po siti on 1 3*3 1 2*2 and 1 4*4 Mux(C) Latch 2*2, 3*3 or 4*4 Comparator3 Programmable threshold 1 Programmable size for threshold 1 Local max 1passed definition 1 Demult (5 to 10 bit) Latch 1 2*2, 1 3*3 and 1 4*4 Comparator 2 select po sit io n 2- bi t Latch

14. What could be done better ? Add(4) Output: Jet count 3- bit vector Output: ROI 1 11-bit vector Connected to Threshold definition 1 in all of the sub-region components Latch Connected to Sub-region 1 component to all threshold definitions (8-bit) Connected to Sub- region 1 component position (2-bit) Connected to Sub-region 1 component Overflow-bit

15. Generating the adder trees for the Jet algorithm (new version)

17. Other work in Stockholm Work on the CMM code for Jet merging (Sam Silverstein). –Based on the CP merger design – simple modifications to accomodate 16 JEMs –Simple version – no special FCAL treatment –Have completed crate merger FPGA source for both crate and system mergers –Next steps: Compile and simulate crate merger designs System merging FPGA (not much to do)

18. Summary FIO scan look promising. Jet code didn’t work, is being rewritten from scratch. The new Jet code seems promising. Work on the CMM goes well.