TSF Upgrade: Firmware Development and Testing Overview

1. Firmware and Testing on the TSF Upgrade Marc Kelly University of Bristol On behalf of the UK TSF Upgrade Team

2. Extensive re-coding of original Design. • Reused a slightly modified Fast Control. These changes are mainly in strobe generation. Read, Write and Address strobes have been brought forward slightly in the command decoding to allow us more time inside Op-Control. Original strobes still exist, ours are additional. • Op-Control is completely new, although pieces of it are based on existing VHDL modified to fit new purposes. It perfoms the task of communication controller. • DAQ-Formatter, Input Formatter are also almost completely new designs. • Engine’s contain some original code, modified to deal with the new design, mostly in the wire counters, BLT and Pivot group processing. The rest is new.

3. 3 Type of FPGA on the Board • Input Formatter. All drift chamber input is sorted, distributed, from here. Also handles input record/playback of input data. • Engine. Does the counting, lookups, processing and outputting of ZPD, BLT as well as storage of DAQ data. • FOD(Fast, Op, DAQ) Main Control FPGA, incorporates the Fast Control, Op-Control and DAQ Formatter. Output record/playback memory is controlled from here.

4. Board Internal IO (1) • All chips communicate with the FOD via a pair of LVDS links running at 60Mhz. These replace the old Bus and control lines. A simplified Clink/Dlink style command structure runs over this link. • Commands are 4 bits long, followed by 6 tag bits and then followed by blocks of 16bits of data (if needed) Commands are preceded by the Clink style 01 transition header. • Tests in ModelSim have shown our design is capable of keeping up with back to back Fast Control transitions.

5. Board Internal IO (2) • Drift Chamber data is shipped to each Engine FPGA over a 20bit direct link, with all 3 Engines receiving data simultaneously. Format is efficient, 16 bits for data, 4 for control. Rate is 30Mhz, with up to 4 pivot groups per clock cycle sent. • DAQ Data is returned to FOD via serial link to each Engine, 60Mhz rate, simultaneously. Data begins shipping back on L1 Accept. Can pipeline 4 L1 Accepts back to back.

6. Input Formatter (1) • Main sorting logic is built by a perl scrip that takes the GLink data format map as its input, this builds the vhdl to do the neighbor mapping, masking and also the mapping to each Engine. Deals with X and Y formats. • 3 Engine Sender units, clocked at 30Mhz, capable of sending up to 4 pivot groups per clock cycle. • Input Memory also stores incoming Neighbor Data with the GLink Data, allowing us to playback enough data to run a single board without external interfacing. Useful for diagnostic testing.

7. Input Formatter (2) • Large 256k*32bit external memory, allowing the storage of 16k frames of GLink data and Neighbour data. • Internal FIFO’s handle the synchronizing to the GLink frame words and clock4 edge. • Contains 2 Mask memories, one for “On” and one for “Off” allowing you to have more control over wires if needed in the future.

8. Engine • Duel Pipeline design, with 2 external LUT memories. The data received over the 20bit link is decoded into 2 internal streams at a rate of 2 pivots per Clock60, with the load spread between the two pipelines. • Superlayers reconstructed after LUT stage, to allow the ZPD segment selection to be performed. BLT Data extracted at this stage using original BLT vhdl followed by new processing code. • DAQ Data held in a duel port ram, designed to behave like a fifo. On L1 Accept read pointer is frozen and data shipped back to the FOD chip via a dedicated link.

9. FOD (1) • Contains 3 distinct blocks: Fast Control, Op-Control and DAQ Formatter. • DAQ Formatter is treated in the same way as an external FPGA’s and only communicates over an internal serial link. This is to keep things syncronised and modular. It does however have a direct connection to Fast Control bus for DAQ readout. • DAQ Buffers are a single Duel Port ram. Data is written into one Port on L1 Accept, and read out of the other on Read Event command. We can begin reading out DAQ data after 1st word has been stored in the Buffer.

10. FOD (2) • Op-Control handles the Serial Protocol, including the encoding and sending, together with presenting any returning data to the Fast Control bus. • Consists of 5 copies of a self contained unit, each deals with 1 FPGA (4 External and the DAQ) • Also contains counters that track the positions in the Playback Memory, so that correct status can be given to Fast Control module.

11. FOD (3) • Playback/Record Memory for the output is controlled from here by the DAQ formatter, again it can store 16k frames worth of data. Handles both ZPD and BLT data. • The reason for having it in the DAQ formatter, is that it allows better synchronization with the Input Formatter’s memory controller, and reuse of code. It also simplifies the Op-Control part of the design. • Frame bits and clock for the ZPD output are generated here as well.

12. FirmwareTesting & Debugging (1) • Initial communication tests. (Within FOD FPGA) • Can we talk to Fast Control module? • Is Op-Control seeing the Fast Control status, and encoding it correctly on the serial lines? • Can we talk to the DAQ Formatter Module, and through that access the Play/Record Memory? • Can we Playback patterns from this memory? Use Diagnostic Headers to see. • Board Communication Tests • Can we talk to Engine, Input Formatter, Access their Memories? • Playback Input Memory, flow it through Engines, record it in the Output Memory, exercises play-record control functions, memory load/read and overall sync of things.

13. FirmwareTesting & Debugging (2) • Off board comunication tests:- Output. • Playback pattern from Output Mem to TSFi. Do our output drivers work? Are we meeting the timing requirments? Data Errors? • Load output Memory with pattern, play it back and send it to TSFi->ZPDi->ZPD. Are there sync issues? Data errors? • Output of Neighbour data. Where can we record it? • Off board communications tests:- Input • Old and new TSF's recieving data from DCH teststand, Recording their inputs. Read it out, compare it. Are we recieving correctly from TSFi? Data errors? Quite a complex test, as needs DAQ system to drive it. • Neighbour Input test. How? Needs to be decided.

14. FirmwareTesting & Debugging (3) • Parasitic Testing – Before summer shutdown. • Fully functional & debugged firmware needed, has to be pretested with patterns and Monte Carlo Events to prove this. Jamie Boyd is working to produce a way to load the input memory with Glink data that would represent Monte Carlo, and on playing through allow us to compare the output memory to the C++ simulation's results.

15. Conclusions. • Fairly extensive and intensive testing needs to be done on the prototypes. Operational tests require a staggered approach, before we can do each step we need to debug the code required. As errors seen could be code related, or could be hardware related. • However we cannot just rely on Operational firmware. It will show when something is working, but cannot be used for proper stress testing. Custom board test firmware is needed as well. This needs to be simpler, and provide well defined functions.