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

2. Outline DBM – just a quick glance Motivation for requesting FEI4B simulation model FEI4B behavioral/RTL simulation model Protecting the FEI4B intellectual property (IP) Questions 2

3. DBM – just a quick glance DBM - Diamond Beam Monitor – a new ATLAS detector, part of ATLAS IBL project – based on FEI4B readout chip, also adopting IBL off-detector electronics (opto/BOC/ROD) – primarily designed to measure luminosity – it complements our existing ATLAS BCM detector (default ATLAS luminosity monitor in Run 1) 8 telescopes (4 per side) around interaction point (~0.9m away) Each telecope consists of 3 modules. Each module consists of diamond sensor and FEI4B readout chip. More info: https://edms.cern.ch/file/1211792/2/ATL-IP-ES-0187-DBM-V2.pdf https://edms.cern.ch/file/1211792/2/ATL-IP-ES-0187-DBM-V2.pdf 3 Pixel Package DBM Telescope DBM Module

4. Motivation for requesting FEI4B model Firstly, in ATLAS DBM we are exploring DAQ beyond that of ATLAS IBL. – we are aiming for L1A trigger rate ~300-500 kHZ – having a complete off-detector FPGA simulation environment, including realistic FEI4B model, helps a lot during FPGA firmware development Then, we realized that IBL DAQ, especially ROD, designers would also greatly benefit by having such realistic FEI4B model available We aim to simulate complete off-detector electronics/FPGA design along with FEI4B model Fairly complex off-detector electronics – consists of 2 VME cards BOC (Back Of crate Card): 3 big Xilinx FPGAs ROD (Read-Out Driver): 3 big + 1 small Xilinx FPGAs Currently, not all IBL ROD designers even have available HW to test new firmware features For debugging, IBL ROD designers are currently using: – Integrated logic analyzers, embedded into FPGA firmware (Xilinx ChipScope probes) – very simplistic FEI4 model: Pseudo-random 8B/10B serial output upon receiving L1A request (it follows FEI4 data format) No way to control specific hit injection into pixel matrix Does not increment L1ID and BCID Does not send out any Service Records 4

5. IBL BOC & ROD VME cards Read-Out-Driver (ROD): Back-of-Crate (BOC): 5

6. IBL ROD/BOC FPGA Hardware Concept Both BOC and ROD use 3 FPGAs – 1× Configuration, Control – 2× Data Processing Unit BOC – Boc Controller FPGA (BCF) 1× Spartan6, S6LX75T – Boc Master FPGA (BMF) 2× Spartan6, S6LX150T (largest Spartan6) ROD – Master FPGA 1× Virtex5, XC5VFX70T – Slave FPGA 2× Spartan6, S6LX150 (largest Spartan6) 6

7. Motivation for requesting FEI4B model, cont. Our goal is to be able to simulate complete IBL ROD firmware (IBL BOC firmware is basically complete). Points of attention: – currently: FEI4 data collection event building histogramming – In the future: FEI4 readout fault injection simulate FEI4 desynchronization verify ROD/BOC recovery mechanism 7

8. Reminder: How I got to the FEI4B IP 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 provided me with behavioral model for the analog part and RTL code for the digital part of FEI4 chip. 8

9. Reminder: Modular view of the FE-I4 core blocks Figure taken from: FE-I4 Chip -- Instrumentation brown bag -- Garcia-Sciveres 9 Got Verilog or SystemVerilog code for this highlighted parts

10. 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 would like to verify my analog/behavioral + RTL/digital FEI4B model. *Along the way, I also upgraded simulation environment from OVM to UVM (1.1d). 10

11. 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

12. Protecting the FEI4B intellectual property (IP) For compilation and simulation I am using Mentor Graphics QuestaSim 10.2b on SLC6 64bit workstation. How to protect IP: from the QuestaSim manual: – Mentor Graphics provides two proprietary methods for encrypting source code. The `protect / `endprotect compiler directives allow you to encrypt regions within Verilog and SystemVerilog files. The -nodebug argument for the vcom and vlog compile commands allows you to encrypt entire VHDL, Verilog, or SystemVerilog source files. 12

13. Protecting the FEI4B intellectual property (IP) From the QuestaSim manual: 13

14. Instead of conclusions: Questions! By compiling the FEI4B code with –nodebug option (encrypting the code) and distributing only the compiled binary model to our common IBL DAQ repository, are these measures sufficient to fully protect the FEI4 IP? What else needs to be taken care of before releasing the model to IBL DAQ repository? Would it be possible to get your gate-level FEI4B model and run it along with my model? – If not, can you think of other ways to sufficiently verify our model before we start relying on it? 14