SLAC PEP-II
BABAR
SLAC<->RAL
Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Det. Search
Who's who?
Meetings
FAQ
Images
Archive
Systems
Performance
Intern. region
Vertex Tracker
Drift chamber
DIRC
Calorimeter
IFR
LST
Magnet
Electronics
Trigger
Operations
Run Coordination
Contact Experts
Shift Takers Info
Operations Manual
Electronic Logbook
Ops Hypernews
Shift Signup
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)
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

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:

Generating html documentation with doxygen:
The L1DctTeststand package contains a script to generate documentation, to do it:
  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
The DCT upgrade generic Fsm: (status=implemented)
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 are:
  • L1DctAbsMap and derivations
  • L1DctAbsConfigure and derivations
  • L1DctBaseMapFiller and derivations
  • L1DBoardDetector
The old TSF FEX using this new generic "Fsm" has been implemented and run in the DCH/DCT teststand. The relevant actions are:
  • L1DctOldTsfConfigureAction
  • L1DctOldTsfL1Accept
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 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.

A question remains: Can DCT wire settings be set during configuration transition rather than only at boot time?

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


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.


  Gérald Grenier Last modified: 8 January 2004