|
DAQ for DCT upgrade
DAQ thoughts (minutes of the October 3rd L3 meeting) :
In the current old DCT, the DAQ data are organized with 3 moduleTC.
Each of these moduleTC correspond to a specific ROM as described in the
following table
| ROM id |
moduleTC |
associated trigger crate |
| 0 |
L1DTsfModuleTC |
TSF-X |
| 1 |
L1DTsfModuleTC |
TSF-Y |
| 2 |
L1DBltPtdModuleTC |
BLT-PTD |
Each moduleTC is made of sectionTC, one sectionTC per trigger board
read. The sectionTC contains the data of one board.
Each moduleTC can be defined even if some sectionTC are missing.
For the upgrade DCT, TSF data should remained identical, the BLT data
won't change and the PTD data will be replaced by ZPD data. We should end
with the following configuration :
| ROM id |
moduleTC |
associated trigger crate |
| 3 |
L1DTsfModuleTC |
new TSF-X |
| 4 |
L1DTsfModuleTC |
new TSF-Y |
| 5 |
L1DBltZpdModuleTC |
BLT-ZPD |
The ROM id for the upgrade DCT are not 0, 1 and 2 since we want to be
able to run the 2 triggers in parallel.
During the commissioning phase, we will run with 2 triggers in
parallel, hence producing 2 L1DTsfModuleTC. To avoid the confusion, all
the moduleTC will be doubled. The already existing ones will be called
production moduleTC. Their twins will be called test module TC.
The module TC production will be as follow :
When new trigger is ran as a parasite of the old trigger,
| ROM id |
moduleTC |
associated trigger crate |
| 0 |
L1DTsfModuleTC |
TSF-X |
| 1 |
L1DTsfModuleTC |
TSF-Y |
| 2 |
L1DBltPtdModuleTC |
BLT-PTD |
| 3 |
L1DTsfTestModuleTC |
new TSF-X parasite |
| 4 |
L1DTsfTestModuleTC |
new TSF-Y parasite |
| 5 |
L1DBltZpdTestModuleTC |
BLT-ZPD parasite |
When the old trigger is ran as a parasite of the new ,
| ROM id |
moduleTC |
associated trigger crate |
| 0 |
L1DTsfTestModuleTC |
TSF-X parasite |
| 1 |
L1DTsfTestModuleTC |
TSF-Y parasite |
| 2 |
L1DBltPtdTestModuleTC |
BLT-PTD parasite |
| 3 |
L1DTsfModuleTC |
new TSF-X |
| 4 |
L1DTsfModuleTC |
new TSF-Y |
| 5 |
L1DBltZpdModuleTC |
BLT-ZPD |
In the above tables, moduleTC with a different name have a different
type id (contains field). For the TSF moduleTC, the yet unused secondary
id will be used to flag which trigger (old or new) has taken the data in
the moduleTC.
Concerning BLT ZPD and BLT PTD moduleTC, Gregory mentioned that we could
use TC with inhomogeneous content.
With this scheme, the TSF to new TSF transition should be smooth for
L3 and OPR. However the PTD to ZPD will need the introduction of the L1DBltZpdModuleTC
at some point. Do we need to suppress the L1DBltPtdModuleTC at the same
time?
Update (minutes of october 18th meeting)
We want to do the same thing for the PTD to ZPD transition as for
the TSF to new TSF transition. A quick look at the source code of
the L1DBltPtdSectionTC shows that there is nothing board specific
(except the contains field) at this level. Providing that the classes
that will use the contents of the TC knows how to recognize and deal
correctly both PTD and ZPD, this approach is possible.
|