sPHENIX is a new detector at RHIC.

["Jan C. Bernauer" <jan.bernauer AT stonybrook.edu>]

Hi Martin,

Thank you! That was a nice write up.

I have three questions though:

    1) Is the number of channels in a packet limited? If so, by size, or
count?

    2) From what I recon from your format description, the packet
payload format is actually not specified, but handled packet (id)
dependent by specialized routines, and the general DAQ transport has no
insight/doesn't need it. Is that correct?

    3) Can packets/event or channels/packet be missing/empty from event
to event?

(Also, is that 1000 in base 10 or 16?)

Best,

Jan


On 9/3/19 3:17 PM, Martin Purschke wrote:
> Dear all,
>
> as we started discussing cabling plans and channel mappings for
> detectors (we are about to put out an ICD for DAQ-OHCal), let me
> explain, especially to people new to sPHENIX, how that mapping works in
> general. This is largely how we did things in PHENIX, and it has served
> us very well over many years.
>
> Each detector adds a number of "packets" to the data stream. You can
> think of such a packet as covering a certain area of real estate on a
> given detector system, such as a part of a sector of the EmCal, or a
> certain group of tiles on the OHCal. Likewise, a piece of a phi-sector
> of the TPC, and so on. Like the pieces of a puzzle, the packets'
> individual coverage areas then make up the entire detector.
>
> Which channels feed their data into such a packet must never change, and
> each packet has a unique packet id, which also stays the same.
>
> In this way, channel x in packet y uniquely identifies a given channel
> in sPHENIX. By extension, a packet typically identifies a piece of
> readout hardware. In PHENIX we soon started to refer to FEMs by their
> packet id ("we had a problem with 4232 last night").
>
> The packet IDs are assigned by "detector number". Starting from what is
> now the MBD, we go from the inside out, for example
>
> 1 - MBD
> 2 - MVTX
> 3 - INTT
> 4 - TPC
> 5 - reserved
> 6 - Emcal
> 7 - IHCal
> 8 - OHCal
>
> 14 - trigger (that's what we are used to)
>
> Packet ID's for a given detector will then be assigned as
>
> 1000 * detector number + 1,2,3,4...
>
> so the OHCal would start with 8001, 8002, and use as many packets as
> needed in its range. Each detector is largely free to assign the IDs in
> that range, within reason. For example, the EmCal could go for
> contiguous numbers, or assign sub-ranges for north and south - we'll see
> what's best.
>
> The "even 1000" numbers (like 8000 for the OHCal) are reserved for a
> future meta-packet in case we have to change a subsystem's packet
> composition after all. Then we would add that packet to specify (or
> maybe just indicate) a new mapping. In PHENIX we never had to exercise
> that option.
>
> All that serves to decouple the reconstruction software from changes in
> the DAQ landscape. Once you have established a channel mapping for your
> detector in the reco software, this should be good through the lifetime
> of sPHENIX.
>
> The packets and their interfaces also shield the offline software from
> routine changes in the DAQ. The data encoding for virtually all
> detectors will change over time as we gain experience and confidence to
> more efficiently package the data. Still, you ask for the "value of
> channel x of packet y" and get the answer through a set of standard
> APIs, so the reco software will be oblivious to such changes.
>
> We will maintain the packet id ranges and the internal mappings in the
> ICD documents.
>
> Best,
>       Martin
>
-- 
Dr. Jan C. Bernauer
Assistant Professor
Department of Physics and Astronomy 
Stony Brook University
Stony Brook, NY 11794-3800