Software environment:
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:
 

L1DctOnline	DAQ and configuration TC : dual use
L1DctOdf	DAQ Fsm and all (old and new) Fast Control Interface, Odf-only
L1DctOep	DAQ TC to digi and related stuff, SRT-only
L1DctDiagOnline	Teststand's "Memory Buffer": classes representing a hardware memory, dual use
L1DctTeststand	Teststand's ROM software + the GUI, Odf-only
L1DctCalOnline	Diagnostic CalCycleTCs and result TCs+ scripts to run DCT calibration, dual use
L1DctCalOdf	The DCT "calibration-diagnostic" Fsm, Odf-only
L1DctCalOep	OepFramework Module and application for DCT diagnostic calibration, SRT-only
L1DctTools	Various off-line tools including the simulation to "Memory buffer" converter, SRT-only

The 2 Fast Control Interfaces :
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:

•  Inject commands
•  Read command
•  dataflow Write Word commands
•  dataflow Write Block commands

1. add all the packages you need in your release directory
2. cd L1DctTeststand
3. generateDoc.ksh
4. this creates documentations in the html subdirectory (the total documentation size is between 13 and 14 Mb)
5. netscape html/index.html to browse the documentation

• L1DctAbsMap and derivations
• L1DctAbsConfigure and derivations
• L1DctBaseMapFiller and derivations
• L1DBoardDetector

• L1DctOldTsfConfigureAction
• L1DctOldTsfL1Accept

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 flexibility.
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 in 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 following pattern:

• 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.

Other Items:

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 Control interface.

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:

• 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)

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)

Links:
Related documentation can be found in

• The  FDR  page.
• The  DCT upgrade design  page.
• Specific questions related to teststand but not related to DAQ can be found in the  teststand  web page.