-
Notifications
You must be signed in to change notification settings - Fork 4
Link and Channel IDs
There are many different integers floating around trying to specify different "links" and different "channels" and this page is focused on writing down my vocabulary for them.
The HGCROC has 72 data-collection "channels" split into two "halves" of 36 channels each.
Each half outputs its own stream of data that needs to be received by downstream hardware or firmware.
Some of the HGCROC parameters are applied for an entire "half" and so we use the same naming convention as the parameters: the "lower" half with channels >= 0 and < 36 is half 0 and the "upper" half with channels >= 36 and < 72 is half 1.
This is helpful because we can then calculate the half a channel corresponds to with integer division: ch / 36 where 0 <= ch < 72 is any channel of an HGCROC.
When connected to an HGCROC Board directly from the ZCU (i.e. in the "Fiberless" setup), each of these halves of the HGCROC is mapped directly onto two "links" in the Firmware so - confusingly, especially in older pieces of code in pflib, the halves of the HGCROC are referred to as "link 0" or "link 1". As we progress forward, I am going to try to be specific as use the word "half" for variable names and documentation.
The ECON[^1] concentrates data by applying zero-suppression (removing channels that didn't see signal) and combines data from multiple (up to 6) different HGCROCs into a single output stream of data. Since each HGCROC outputs its two halves in two different electrical lines, each HGCROC is connected to two different input lines for an ECON (called "eRx" where the "R" stands for "Receiver" I believe). Confusingly, instead of saying "electrical lines" folks (me included) have often just said "link" for this situation as well. As we move forward, I am going to try to be specific as use the word "eRx" for variable names and documentation when talking about input lines to an ECON.
[^1]: Technically, these comments are about an ECON-D. ECON-Ts do a similar process but are focused on the Trigger path instead of the Data collection path. However, the ECON-D and ECON-T share the same "eRx" methodology so I believe these comments are the same for both.
Since the ECON-D outputs a single stream of data (one "eTx"), the firmware and software (on both the ZCU and Bittware) only needs to read out one "link" per ECON-D. Right now (April 2026), the software/firmware is at the stage of a single ECON-D in total but in the future we plan to expand this to combining multiple ECONs as well.
The output data format produced by the ECON-D does not store the eRx ID number, it just writes out the eRx that are enabled in ID-number order (as far as I'm aware) leaving it up to us with knowledge on which eRx were enabled (and how they were connected) to deduce the mapping back to which ROC-half that data corresponds to.
I think the best way to understand all of this "shuffling" is to look at an example. The HcalBackplane can hold up to 4 HGCROC Boards and one ECON-D can take in those 4*2 = 8 data streams from those HGCROC boards and concentrate them into one output data stream. The specific mapping of HGCROC-halfs into ECON-D eRx is decided by how the HcalBackplane is wired and we code this mapping into the HcalBackplane::getRocErxMapping().
Let's say that only HGCROC0 on the HcalBackplane is connected. This means we would enable eRx 3 (for HGCROC0 Half 0) and eRx 2 (for HGCROC0 Half 1). After collecting data, the first "link" that is decoded in the ECOND Event Packet is eRx 2 (since eRx 0 and eRx 1 are not enabled) and the second "link" is eRx 3. So, in this case, we would have the following table for interpreting the decoded data output by the ECON-D.
| ROC-Half | eRx |
ECONDEventPacket link index |
|---|---|---|
| 0 | 3 | 1 |
| 1 | 2 | 0 |