There are two distinct data paths through the iTOP system: the trigger path and the event path. Each system consists of both a sending and receiving channel. Data flow is primarily from the front-end to the back-end. Although much rarer, commands sometimes need to be sent from the back-end to the front-end. These do not use much link bandwidth, but should be treated with higher priority than sending data from the front-end to the back-end. Specifics on each of the data paths and formats for specific data are given below.
The trigger path connects the front-end readout (via SCROD) to the TRG_FIN. The data flow is primarily from the SCROD to the TRG_FIN, and consists of channel and channel-level trigger timing information for all hits that the front-end observes. For the trigger path, the primary data entity is a 32-bit word. This proposal is a minor adaptation of Xin Gao's data format proposal, which can be found here.
Bit | 31 | 30:28 | 27:24 | 23:0 | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Value | 1 | PMT[2:0] | CHANNEL[3:0] | TIME[23:0] |
Bit 31 high indicates this is a data word.
PMT[2:0] - The PMT on the SCROD corresponding to the hit. A SCROD services 8 SL10 MCP-PMTs.
CHANNEL[3:0] - The channel is the channel number within the PMT.
TIME[23:0] - Timing information (24 bits).
To-Do:
The general control word structure is:
Bit | 31 | 30:28 | 27:0 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Value | 0 | WORD_TYPE[2:0] | type-dependent |
Bit 31 low indicates this is a control word.
WORD_TYPE[2:0] - Identification of which control word this is. Current assigned words:
This word is sent from the SCROD to the TRG_FIN to inform the downstream TRG_FIN which front-end it's talking to. It is anticipated that this will be sent once upon the link coming up.
Bit | 31 | 30:28 | 27:24 | 23:22 | 21:0 | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Value | 0 | 0 | 0 | 0 | MODULE[3:0] | FIBER[1:0] | unused/reserved |
Bit 31 low indicates this is a control word.
Bits 30:28 are the WORD_TYPE, which is “000”
MODULE[3:0] - The iTOP module within the Belle II detector. There are 16 total modules, so 4-bits are reserved.
FIBER[1:0] - The fiberoptic link for this module (also a proxy for the electronics module number within the iTOP module). There are 4 front-end board stacks per iTOP module, and each has a separate trigger link, so 2-bits are reserved.
Bits 21:0 are unused, or can be reserved for other use if needed later.
This word is sent from the TRG_FIN to the SCROD to request a reprieve from receiving data. It is anticipated that this will be sent once upon the link coming up.
Bit | 31 | 30:28 | 27:24 | 23:0 | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Value | 0 | 0 | 0 | 1 | WAIT_CODE[3:0] | unused/reserved |
Bit 31 low indicates this is a control word.
Bits 30:28 are the WORD_TYPE, which is “001”
WAIT_CODE[3:0] - This is a requested delay, in units of 8-clock cycles, that the SCROD should wait until sending further trigger data. For example, “0001” would be a request of 8 clock cycles of delay, and “0010” would be a request of 16 clock cycles of delay.
Bits 23:0 are unused, or can be reserved for other use if needed later.
No other words are defined at the moment. However, bits 30:28 can be used to support up to six other control words. These can be added as needed.
The event path connects the front-end readout (via SCROD) to the back-end electronics. In standalone (non-Belle II infrastructure) situations, this is probably the DSP_cPCI. For the final Belle II data path, this is the DSP_FIN. The data is primarily from the SCROD to one of these back-ends, and consists primarily of waveforms from a triggered event, though other types of data may also flow along this link, such as auxiliary monitoring information (temperatures, feedback settings, etc.). The opposite direction (back-end to SCROD) is the primary mechanism to send slow-control commands to the front-end, including DAC settings, software triggers, and ASIC control bits. The primary data entity is a variable length packet composed of a number of 32-bit words.
As part of initial development, a fixed-length packet protocol was developed. Information on this protocol (which is now being phased out!) can be found here.
The general format for variable-size packets is the following, where N is the number of words in a given packet:
Word | Bits 31:16 | Bits 15:0 | Notes/description |
---|---|---|---|
0 | 0x00BE11E2 | header word | |
1 | packet size | number of words following this one (N-2) | |
2 | packet type | (specific identifiers enumerated below) | |
3:N-2 | … | packet data | |
N-1 | checksum | 32-bit checksum calculated over words 0:N-2 |
Specifics on words 2 through N-2 each packet type are given below.
Command packets are passed from the data acquisition system to the front-end modules. The data path for such packets should be somewhat flexible, as some commands may need to be sent to FPGAs or DSPs on the DSP_FIN or the DSP_cPCI, in addition to commands that are going to the front-end modules.
Multiple commands may be packed into a single packet, in which case each command will be executed as soon as the command checksum is validated. Each command should be acknowledged by a response packet, and the response packet should include an ID number associated with the command, so that the originator of the command can see which commands have been acknowledged.
Word | High bytes | Low bytes | Description | ||
---|---|---|---|---|---|
31:25 | 24:16 | 15:8 | 7:0 | ||
2 | 0x646f6974 | command packet designator: “doit” in ASCII | |||
3 | 0x00 (reserved) | destination SCROD rev(7:0) | destination SCROD ID(15:0) | SCROD rev and ID designate which SCROD this packet is directed at. (e.g., 0x00A2000E is SCROD Revision A2, ID 14 [ID is in hex]). Note that 0x00000000 is the broadcast address. | |
4 | verbosity(7:0) | command ID | verbosity(7) suppresses command responses from the SCROD for successfully received commands. Other verbosity bits are reserved. Command ID is a 24-bit identifier assigning a unique ID to this command. | ||
5 | command type | specific types are listed below | |||
6 | command data | variable number of command data words per command | |||
… | … | ||||
… | command checksum | 32-bit checksum of command type + data words | |||
… | verbosity(7:0) | command ID | further commands, if desired | ||
… | command type | ||||
… | command data | ||||
N-2 | command checksum |
A ping command simply generates a response packet from the SCROD. It can be used to check whether a link is alive and functioning or probe the SCROD ID on a given channel.
Word | Bits 31:16 | Bits 15:0 | Description |
---|---|---|---|
5 | 0x70696e67 | “ping” in ASCII | |
6 | command checksum | checksum for ping will be the command_ID + word 5 |
Word | Bits 31:16 | Bits 15:0 | Description |
---|---|---|---|
5 | 0x72656164 | “read” in ASCII | |
6 | reserved(0x0000) | register address | addresses may be firmware specific |
7 | command checksum |
Word | Bits 31:16 | Bits 15:0 | Description |
---|---|---|---|
5 | 0x72697465 | “rite” in ASCII | |
6 | register value | register address | addresses may be firmware specific |
7 | command checksum |
To-Do:
To-Do:
There are two types of packets that can come back from the SCROD, those that are responses to commands, and those from triggered events.
Each command received by SCROD should be followed by an acknowledgment packet of the following form. Although the SCROD may receive many commands in a single packet, it will respond with an individual packet for each command, immediately after the command is executed. If a command is successfully executed, the response will be:
Word | Bits 31:16 | Bits 15:0 | Description | |
---|---|---|---|---|
2 | 0x6F6B6179 | “okay” in ASCII | ||
3 | 0x00 & Source SCROD revision(7:0) | Source SCROD ID(15:0) | source designates which SCROD sent the packet | |
e.g., 0x00A2000E is SCROD Revision A2, ID 14 (ID is in hex) | ||||
4 | command ID | echoes the command that triggered this response | ||
5 | command type | echoes the command type that triggered this response |
Further words depend on the command sent. The following are currently planned:
The ping acknowledge does not include anything beyond the command ID. So word 6 would be the checksum, and the final word of the packet.
Both reads and writes to registers should respond with a response from the same register. In this way you can immediately see if the register was able to be set.
Word | Bits 31:16 | Bits 15:0 | Description |
---|---|---|---|
6 | register value | register address | value that SCROD has written or read back from address |
Open questions/options:
Word | Bits 31:16 | Bits 15:0 | Description |
---|---|---|---|
2 | 0x7768613f | “wha?” in ASCII | |
3 | 0x00 & Source SCROD revision(7:0) | Source SCROD ID(15:0) | source designates which SCROD sent the packet |
4 | command ID | command ID that triggered this response (or 0x0000 if no command ID could be determined) | |
5 | bad command flags | flags indicated why the command failed (misunderstood command type, bad checksum, bad SCROD ID, etc.) |
The bad command flags are:
Event data is output whenever a trigger is received, either hardware or software. It consists of a single header packet, waveform packets if any waveforms are available to be read, and auxiliary packets. A SCROD will always send a header packet upon receipt of a trigger, whether there were any waveforms to be read or not. Auxiliary packets are not yet defined, but are reserved in case we find need of them later.
Word | High bytes | Low bytes | Description | ||
---|---|---|---|---|---|
31:25 | 24:16 | 15:8 | 7:0 | ||
2 | 0x65766e74 | “evnt” in ASCII | |||
3 | 0x00 (reserved) | source SCROD revision(7:0) | source SCROD ID(15:0) | source designates which SCROD sent the packet (e.g., 0x00A2000E is SCROD Revision A2, ID 14 (ID is in hex)) | |
4 | protocol freeze date | YYYYMMDD (in BCD) of the date when this data format was frozen | |||
5 | event number | 32-bit event number | |||
6 | 0x000000 (reserved) | trigger_type(7:0)* | trigger_type(0) is 1 for hardware trigger | ||
trigger_type(1) is 1 for software trigger | |||||
trigger_type(2) is 1 for truncated events | |||||
trigger_type(15:3) are reserved (0 for now) | |||||
7 | 0x000000 (reserved) | event_flags(7:0) | event_flags(0) is 1 pedestal mode. event_flags(7:1) are reserved. | ||
8 | # of waveform packets this event | ||||
9 | # of auxiliary packets this event |
*Please note that the trigger_type bits 0 and 1 can BOTH be high. This indicates that a hardware or software trigger was received, and the other type of trigger was also received before the first could be fully processed. The second trigger is ignored, but this may indicate that the data may not be suitable for use, depending on the conditions.
Word | High bytes | Low bytes | Description | ||
---|---|---|---|---|---|
31:25 | 24:16 | 15:8 | 7:0 | ||
2 | 0x77617665 | “wave” in ASCII | |||
3 | 0x00 | source SCROD revision(7:0) | source SCROD ID(15:0) | source designates which SCROD sent the packet | |
4 | 0x0000 | 0000000 & reference ASIC window(8:0) | identifies analog storage window to be used as reference time for waveforms in this packet. This corresponds to the last window in analog memory sampled, so all timing is a “look-back” from this window. | ||
5 | event number | 32-bit event number | |||
6 | # waveform segments this packet | ||||
7 | 0x0000 | segment ASIC window(15:0) | identifies ASIC_COL(15:14), ASIC_ROW(13:12), ASIC_CH(11:9), analog storage WINDOW(8:0) of waveform segment | ||
8 | # of points this segment | ||||
9 | segment data 1 | segment data 0 | waveform ADC values | ||
10 | segment data 3 | segment data 2 | |||
… | … | … | … | ||
repeat for further segments |
To-Do: