itop Data Format Proposals Kurtis Nishimura University of Hawaii September 21, 2012 US Firmware Meeting

Transcription

1 itop Data Format Proposals Kurtis Nishimura University of Hawaii September 21, 2012 US Firmware Meeting 1

2 itop Data Formatting Two sources of data, divided by fiberoptic transceiver (or by USB endpoint pair for local test/use) [see here]: Event/waveform data. Fiberoptic transceiver 0. USB endpoints 2/6. Ultimately intended for DSP_cPCI or DSP_FIN (COPPER). Trigger data. Fiberoptic transceiver 1. USB endpoints 4/8. Ultimately intended for TRG_FIN (COPPER). *Data flow is asymmetric. Data coming from back- to front- is less common, but should be given priority so that commands are executed regardless of front- status. 2

3 TRIGGER LINK DATA FORMATS 3

4 Trigger Data Formatting Prototype TRG_FIN firmware is established. Written by Xin Gao. Trigger algorithm will need revisiting, but general data flow/combining can be used. Previous document on data format is available here: Needs to be modified since fibers now support 8 PMTs (not 4). Primary data structure is 32-bit word. Two types: data & control. Timing data format still to be decided. Other flow control words can be accommodated relatively easily. Trigger hit data word: P P P C C C C T T T T T T T T T T T T T T T T T T T T T T T T Control word: link initialization (SCROD TRG_FIN): M M M M F F R R R R R R R R R R R R R R R R R R R R R R Control word: wait to transmit (TRG_FIN SCROD): W W W W R R R R R R R R R R R R R R R R R R R R R R R R P PMT # C CH # T Timing data M itop Module # F Fiber # R Resereved W Wait code 4 R Resereved

5 EVENT/WAVEFORM LINK DATA FORMATS 5

6 Event/Waveform Data Types Back- to front-end data: Commands, for example: Resets. Set new DAC values. Turn feedback loops on/off. Set ASIC sampling mode and sampling properties. Front- to back-end data: Waveform data. Channel-level trigger data (e.g., scalers). Housekeeping (temperatures, current DAC settings). Primary data structure is a packet. 6

7 Commands (Back- to Front-end) Word Bits 31:16 Bits 15:0 Notes 0 Header word TBD (previously 0x00BE11E2) 1 Target SCROD ID Or generic ID to send to all SCRODs. 2 Command word 3 Associated data words e.g., register address 4 Associated data words e.g., register data to write/read 5 Most settings controlled through memory-mapped registers. Primary commands will be a load or a read of a specific memory address. No footer word, checksums. Each command from back-end will be acknowledged with packet by front-end, so verification can be done by software. Header word. Helpful for resynchronization if a misformatted packet arrives. Multiple commands can be accommodated in single packet. 7

8 Previous Event/Waveform Data Format (Front- to Back-end) See here for more details. Every trigger to front-end resulted in all possible data sent from front-end [132 packets]: Header packet Waveform packets [x128] Housekeeping packet [temperature & DAC information] Footer packet Straightforward to prepare an event, but a lot of wasted bandwidth. Most waveform packets were for channels without hits. This is an attempt to make a flexible framework that allows for varying event/waveform size. Still work in progress comments welcome. 8

9 Proposed Event/Waveform Data An event consists of: Event header packet. Waveform packets. Auxiliary packets. None of these planned to start with, but they can be added in case we find we need them. Other special packets will be sent on request as a response to specific commands. Back-end handling DSPs should handle event data. Other special packets should be passed through to back end. 9

10 Header packet: Event/Waveform Data Word Bits 31:16 Bits 15:0 Notes 0 Header word TBD (previously 0x00BE11E2) 1 Packet size in words (not including this word or header) 2 Protocol freeze data YYYYMMDD in BCD 3 Header packet ID word TBD (previously was 0x0000EADA) 4 SCROD ID As read from SCROD EEPROM 5 Event Number 6 Event Type E.g., Regular/software trigger 7 Event Flags E.g., Pedestal mode. 8 Number of waveform packets this event 9 Number of auxiliary packets this event 10 Checksum Payload only, header/footer not included. 11 Footer TBD (previously bpid in ASCII, 0x ) 10

11 Event/Waveform Data Waveform packet: Word Bits 31:16 Bits 15:0 Notes 0 Header word TBD (previously 0x00BE11E2) 1 Packet size in words (not including this word or header) 2 Waveform packet ID word TBD (previously was 0x00C0FFEE) 3 Waveform segments this packet 4 Waveform origin window Identifies ASIC, CH, ROW, COL, WINDOW, SAMPLE of starting point for following waveform 5 Number of waveform points 6 Waveform Data 0 Waveform Data 1 Repeat for another waveform N-2 Checksum Payload only, header/footer not included. N-1 Footer TBD (previously bpid in ASCII, 0x ) 11

12 Event/Waveform Data Waveform packet: Back-end prefers to get one full waveform per packet. From front-end perspective, it is not always convenient to send data in this format, Word due to the Bits order 31:16 in which data Bits is 15:0 fastest digitized. Notes I think this format will allow us to support either option. 0 Header word TBD (previously 0x00BE11E2) 1 Packet size in words (not including this word or header) 2 Waveform packet ID word TBD (previously was 0x00C0FFEE) 3 Waveform segments this packet 4 Waveform origin window Identifies ASIC, CH, ROW, COL, WINDOW, SAMPLE of starting point for following waveform 5 Number of waveform points 6 Waveform Data 0 Waveform Data 1 Repeat for another waveform N-2 Checksum Payload only, header/footer not included. N-1 Footer TBD (previously bpid in ASCII, 0x ) 12

13 Event/Waveform Data Still deciding: should we add information on ASIC feedback loops to the waveform packets? I think if we find it is necessary, we can add it as an auxiliary packet that Waveform packet: covers all ASICs. Word Bits 31:16 Bits 15:0 Notes 0 Header word TBD (previously 0x00BE11E2) 1 Packet size in words (not including this word or header) 2 Waveform packet ID word TBD (previously was 0x00C0FFEE) 3 Waveform segments this packet 4 Waveform origin window Identifies ASIC, CH, ROW, COL, WINDOW, SAMPLE of starting point for following waveform 5 Number of waveform points 6 Waveform Data 0 Waveform Data 1 Repeat for another waveform N-2 Checksum Payload only, header/footer not included. N-1 Footer TBD (previously bpid in ASCII, 0x ) 13

14 Summary Still a number of things to decide: Specific words for packet types, command types, etc. Packet format for special (upon request) packets. Housekeeping and scaler packets could be quite similar to previous document. Will post complete proposal sometime this weekend. Comments welcome both on overall structure and any specifics. 14