iTOP Data Format Proposals Kurtis Nishimura University of Hawaii - - PowerPoint PPT Presentation

▶
itop data format proposals
SMART_READER_LITE
LIVE PREVIEW

iTOP Data Format Proposals Kurtis Nishimura University of Hawaii - - PowerPoint PPT Presentation

May 24, 2023 114 likes •264 views

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]:

slide-1
SLIDE 1

iTOP Data Format Proposals

Kurtis Nishimura University of Hawaii September 21, 2012 US Firmware Meeting

1

slide-2
SLIDE 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).

2

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

slide-3
SLIDE 3

TRIGGER LINK DATA FORMATS

3

slide-4
SLIDE 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.

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

Trigger hit data word: 31 0 P – PMT # C – CH # T – Timing data

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

Control word: link initialization (SCROD  TRG_FIN): 31 0 M – iTOP Module # F – Fiber # R – Resereved

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

Control word: wait to transmit (TRG_FIN  SCROD): 31 W – Wait code R – Resereved

4

slide-5
SLIDE 5

EVENT/WAVEFORM LINK DATA FORMATS

5

slide-6
SLIDE 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

slide-7
SLIDE 7

Commands (Back- to Front-end)

Word Bits 31:16 Bits 15:0 Notes 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 …

7

  • 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.
slide-8
SLIDE 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

slide-9
SLIDE 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

slide-10
SLIDE 10

Event/Waveform Data

  • Header packet:

10

Word Bits 31:16 Bits 15:0 Notes 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)

slide-11
SLIDE 11

Event/Waveform Data

  • Waveform packet:

11

Word Bits 31:16 Bits 15:0 Notes 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)

slide-12
SLIDE 12

Event/Waveform Data

  • Waveform packet:

12

Word Bits 31:16 Bits 15:0 Notes 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)

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

  • I think this format will allow us to support either option.
slide-13
SLIDE 13

Event/Waveform Data

  • Waveform packet:

13

Word Bits 31:16 Bits 15:0 Notes 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)

  • 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 covers all ASICs.

slide-14
SLIDE 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