The trigger upgrade DAQ web page
This page contains everything related to the modifications to make to
the DCT DAQ due to the DCT upgrade
the following picture shows the dependencies between the various packages
involved in DCT DAQ and DCT Teststands.
Also available in eps and web-layout
(this latter is done with the Web
Layout program )
The packages involved in DAQ are L1DctOnline, L1DctOdf and L1DctOep.
When developping code for the DCT upgrade, the head of each
relevant packages should be checked out.
Quick summary of each package:
||DAQ and configuration TC : dual use
||DAQ Fsm and all (old and new) Fast Control Interface, Odf-only
||DAQ TC to digi and related stuff, SRT-only
||Teststand's "Memory Buffer": classes representing a hardware memory,
||Teststand's ROM software + the GUI, Odf-only
||Diagnostic CalCycleTCs and result TCs+ scripts to run DCT calibration,
||The DCT "calibration-diagnostic" Fsm, Odf-only
||OepFramework Module and application for DCT diagnostic calibration,
||Various off-line tools including the simulation to "Memory buffer"
The 2 Fast Control Interfaces :
Generating html documentation with doxygen:
For the teststand software needs, the Fast Control interface has been
rewritten. Both the old and new interface are in the L1DctOdf package.
As ooposed to the old interface, the new interface can use the "block read"
and "block write" Fast Control commands included in the new DCT boards
and can communicate on bith the A and B C-/D-links.
For details on the implementation of the new Fast Control see
BAD 588 and the following links:
The L1DctTeststand package contains a script to generate documentation,
to do it:
The DCT upgrade generic Fsm: (status=implemented)
add all the packages you need in your release directory
this creates documentations in the html subdirectory (the total documentation
size is between 13 and 14 Mb)
netscape html/index.html to browse the documentation
This "generic" Fsm is how we will deal with incomplete crates and configurable
DCH sector to DCT crate slot map.
The early thought about this problem are here
. The first UML diagrams for the implementations are here : [eps][pdf]
The implementation is done in L1DctOdf packages. The relevant classes
The old TSF FEX using this new generic "Fsm" has been implemented and run
in the DCH/DCT teststand. The relevant actions are:
L1DctAbsMap and derivations
L1DctAbsConfigure and derivations
L1DctBaseMapFiller and derivations
The configure action still uses the old Fast Control command. If one rewrites
it with use of the new Fast Control commands, the obtained Fsm would be
able to run the 2 TSF crates from one ROM.
The Fsm Builder: (status=implemented)
As the number of options on which actions should be attached to the
Fsm is increasing, the Fsm creation design has been improved to allow more
The L1DFsmBuilder is the base class that builds Fsm and attach actions
to it. The selection of which Fsm to build for which ROM is provided by
L1DFsmBuilderFactory and derived classes. See L1DctOdf/dctsegtest.cc
for examples of use.
The module TC issue: (status= implemented)
How to make the DCT upgrade compatible with OEP has been discussed
a L3 meeting The practical implementation
of that scheme is:
Each moduleTC has a base class TCBase which contains all the functionalities
but only protected constructors. Each BaseTC has 2 derived moduleTC, a
production one and a parasite one. Each derivedTC implements nothing but
a public constructor. The public constructor sets the BaseTC identity using
this latter's protected constructor.
For existing TC like for the TSF, the productionTC class should have
the same name as the current TC produced by the DCT DAQ.
The DCT wire settings update:(status= done)
The DCT ROM numbers (set by dip switches on the ROM) are set with the
- the first 4 bits are used by dataflow to describe the data volume at L1Accepts.
- 0 for TSFX crate
- 1 for TSFY crate
- 2 for BLT-PTD crate
- 3 for BLT-ZPD crate
- 4 for the 2 TSF X+Y crates driven by one ROM
- higher numbers are not used at this point
- the fifth bit is used by the DCT to distinguish between old (bit not set) and new (bit set) DCT.
A question remains:
Can DCT wire settings be set during configuration transition rather than
only at boot time?
The ZPD FEX:(status=done)
This includes definition of the FEXed data TC and implementation of
the L1Accept action
The ZPD Configuration:(status=almost done, configuration tree to be defined)
This includes defining the configuration TC and writing the corresponding
configure action deriving from L1DctAbsConfigure and using the new Fast
The new TSF FEX:(status=done)
The TC format will be identical to the current old TSF TC. The L1DctOldTsfL1Accept
action can become the L1DNewTsfL1Accept with probably only minor changes.
Changes are expected to arise only in engine number to DCH location map.
The new TSF Configuration:(status=done)
For the record, I left the questions raised on that subject in April 2003
Start of historical webmark
Besides writing the configure action deriving from the L1DctAbsConfigure
class, one has to solve configuration database issues:
The old TSF and the new TSF are both using the same kind of LUT table
but with a different meaning for the bits in the LUT words (These are known
as the 5-bit (old) and 6-bit (new) LUT by reference of the number of bits
needed to describe the phi value of a TSF segment). This is irrelevant
for transferring a LUT TC to the board but it is important for offline
data interpretation. The various issues are:
For the configuration action, the new TSF need extra values that can be
computed on the fly in the ROM or stored in a new LUT TC. What is the best
option and what is the best way to implement it?
Do we store 1 or 2 tsf LUT in the database?
If we store only one LUT in the database with a new to old conversion mechanism,
how do we calibrate the new LUT?
How do we flag the nature 5-bit(old)/6-bit(new) of the stored LUT?
Should we define a new TC for the new LUT or can we reuse the old one?
Offline processing and L3 trigger need the TSF LUT in the database. What
does it suggest as reasonable answers for the above questions? (For example,
how L3 will access the LUT value correctly)
end of historical web mark
The global trigger configuration(status=to be done, urgency depends
on what do we want offline)
A few configuration parameters are affecting more than one element
of the trigger. The trigger lines for example impacts GLT and L3. For the
parallel commissioning, a new global trigger configuration parameter is
needed : is it the old or the new dct which is triggering? This parameters
will affect DCT, GLT and L3. Should we put this parameter in the database
for june or can it be delayed? If it has to be put in the database for
june, where and how should it be introduced?
Related offline issues:(status=to be done)
This part includes TC to digi and ZPD monitoring using L1TNtuple
or having access to ZPD data and reconstructed DCH tracks at the same time.
The main question is: Do we have the manpower and the time to solve
that before June?
An offline application doesn't have usually access to the configuration
TC. To have an offline application, we need to put in the database every
configuration data we need.
The ZPD TC might be self contained and may not need introduction of database
objects for offline exploitation (might be doable for June)
The new TSF data need in the database the new TSF LUT and probably the
new parameter in the global trigger configuration to be able to decode
correctly TSF TC (unlikely to be ready for June)
Related documentation can be found in
Grenier Last modified: 8 January 2004