1. FEI4B simulation model for IBL and DBM DAQ development CERN, 29. November 2013 Aleš Svetek J. Stefan Institute, CERN

2. Outline FEI4B simulation model: why do we need it? DBM DAQ Data Path IBL/DBM BOC & ROD photos IBL ROD & BOC Main Functionality How I got to FEI4B model and FEI4B IP? What features does our FEI4B model support? Conclusions

3. FEI4B simulation model: why do we need it? FEI4B chips are read out and processed using FPGA chips by the supporting FPGA firmware Complete DBM detector (and 1 IBL stave) is read out by 6 big and 1 small FPGA (see the next 2 slides) Corresonding FPGA firmware tends to be very complex Roughly 1 order of magnitude more complex than BCM FPGA firmware... We want to have a complete FPGA firmware simulation environment with realistic input test vector  the need for FEI4B sim. model

4. ROD & BOC photos 4 Read-Out-Driver (ROD): Back-of-Crate card (BOC): - FPGAs

5. IBL ROD & BOC Main Functionality Read-Out-Driver (ROD): It fully controls the configuration, triggering and readout of 32 FE-I4 (one stave). It performs on-board histogramming and sends the results to Fit Servers via Gb Ethernet. It receives FE-I4 data stream, builds events and formats the events for S-Link transmission. Back-of-Crate card (BOC): It receives the optical data packets from the FE-I4, converts them to electrical form, and passes them to the ROD. It takes the electrical control signals form the ROD, converts them to Bi-Phase Mark encoded optical signals, and dispatches these down the clock and control fibres to the detector modules. It takes formatted events from the ROD, and provides the S-Link path via the ROB (Read Out Buffer) to the DAQ ROD and BOC both utilize 3 large FPGAs per board ROD Master FPGA  1× Virtex5, XC5VFX70T Slave 0 & Slave1  2× Spartan6, S6LX150 (rea-time ROD data processing unit) BOC Boc Controller FPGA, BCF  1× Spartan6, S6LX75T Boc Master FPGA (North and South), BMF  2× Spartan6, S6LX150T (real-time BOC data processing unit)

6. DBM DAQ Data Path Now we have both the Hitbus chip and the FEI4B chip model available which Allows us to fully simulate and verify FPGA firmware design with realistic input data.

7. How I got to the FEI4B IP? Loooong discussion.... Email thread: Sharing of FE-I4 verilog code atlas-pixel-blr-electronics@cern.ch From Maurice (March 14th, 2013): Given that this is a use of FE-I4 within ATLAS and for ATLAS detector, and given that only RTL code will be shared (no ARM, analog blocks, or direct access to the design repository), I think you should simply go ahead and work with Tomasz to get this done without any further formalities. We trust Tomasz will let everyone know if the requirements change and a higher level of participation is needed. You should also remember to acknowledge the FE-I4 design team in any publications. After that, Tomasz Hemperek from Bonn provided me with behavioral model for the analog part and RTL code for the digital part of FEI4 chip.

8. FEI4B behavioral/RTL simulation model I took bits and pieces (CMD, DDC, DOB, EOCHLB, EODCL, PDR), developed top level configuration file, adapted parts of source code with missing IBM/proprietary libraries, and came up with a working FEI4B model. I employed encryption mechanisms to compile the FEI4 source code. Resulting compiled binary should fully protect FEI4 IP. I shared the FEI4B model and supporting infrastructure with IBL DAQ developers. I also plan to verify my analog/behavioral + RTL/digital FEI4B model. Already in discussion with one FEI4 designer present here at CERN.

9. Another screenshot of simulation waveforms

10. FEI4B behavioral/RTL simulation model Top level FEI4B sim. model interface: The model fully supports: FEI4B configuration several operating modes (L1A trigger via CMD, Ext L1A trigger, self-trigger, CAL injection,...) pixel array emulation HitOR output (which we do use in ATLAS DBM) I deliberately excluded FEI4B inputs/outputs not used in IBL or DBM (can be easily added back if needed).

11. Conclusions – how does FEI4B model help us with DBM DAQ development It allows us to understand how far can we push FEI4 chip. (IBL won't be pushing FEI4 to the maximum) It allows us to simulate and verify DBM luminosity algorithms within FPGA firmware Complete DAQ simulation framework allows us to simulate FPGA firmware under ideal situation. In addition to that, it also allows us to inject various faults and FEI4 chip misbehaviors check proper FPGA recovery mechanisms Verify proper resynchronization procedures