iTOP Data Format Proposals Kurtis Nishimura University of Hawaii September 21, 2012 US Firmware Meeting 1
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 2 that commands are executed regardless of front- status.
TRIGGER LINK DATA FORMATS 3
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: 0 P – PMT # 31 C – CH # 0 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 T – Timing data Control word: link initialization (SCROD TRG_FIN): 0 M – iTOP 31 Module # 1 0 0 0 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 F – Fiber # R – Resereved Control word: wait to transmit (TRG_FIN SCROD): 31 0 W – Wait code 1 0 0 1 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 4 R – Resereved
EVENT/WAVEFORM LINK DATA FORMATS 5
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
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
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
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
Event/Waveform Data • Header 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 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 , 0x62504944) 10
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 , 0x62504944) 11
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, due to the order in which data is fastest digitized. Word Bits 31:16 Bits 15:0 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 , 0x62504944) 12
Event/Waveform Data • Still deciding: should we add information on ASIC feedback loops to the waveform • Waveform packet: packets? I think if we find it is necessary, we can add it as an auxiliary packet that 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 , 0x62504944) 13
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
Recommend
More recommend
