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

FcsData and FcsSim (Fred Kral) October 1996

Overview

FcsData is to contain the digi data from the Fast Control System. FcsSim will take over the Fast Control simulation functionality of trgFrame/FC* Fortran77 and C++ code.
Last tested with SRT release 1.2.2.

Fast Control System data

This is a mixture of a proposal and an explanation of the Fast Control System (acronyms: FCS or FC for short).

There are four types of relevant data in BaBar:

  1. Fast Clocks (from PEP-II via FCS)
  2. Fast Commands (from TRIGGER or ONLINE via FCS)
  3. Fast Control Master Transaction Records (FCS master)
  4. DAQ Data (from 7 subsystems: SVT, DCH, DRC, EMC, IFR, TRG, FCS)
Data types 1 and 2 are available to subsystem electronics via the FCS.
Data type 3 is read into DAQ Data stream from the FCS master only.
Data type 4 represents the Digi data that people think of as an event.

In the real detector, data types 1 and 2 are delivered via hardware. Clocks are always operating during data taking and Fast Commands are delivered over dedicated links. Information about the clocks enter the DAQ Data stream through the Fast Control Master Transaction Records and information about the Fast Commands enter the data stream through the DAQ data through each of the data-taking detector subsystems (redundantly in case more than one of SVT, DCH, DRC, EMC, IFR and TRG are enabled in addition to FCS).

In the simulation, to do a fully functional detailed simulation of the electronics that produces the Digi data, we need (1) access to synchronized clocks and (2) information on one pertinent Fast Command, namely the Level 1 Accept command (L1A) and associated data.

For now, only the absolutely minimal FCS services required for the BaBar detector system digitizattion code will be provided.

FCS Fast Clocks

In the real detector, all clocks are derived from the RF frequency of 476 MHz.

This signal gets divided down into things BaBar cares about:

 Speed  Period      Nickname    Name
 0   1 BX       238 MHz     Beam Crossing (BX)
 2   4 BX        60 MHz     Fast Control System Clock, Wall Clock
 4  16 BX        15 MHz     Global Trigger Clock, SVT/DCH/DRC Clock
 5  32 BX         8 MHz     DC Trigger Clock
 6  64 BX         4 MHz     EMC Clock, EM Trigger Clock

FCS Fast Command Data Record

A minimal version of the FCS Fast Command data record contains:
    Name                    Detector representation
    State of wall clock at L1A      <=56-bit unsigned integer
    State of 32 trigger lines at L1A      32-bit unsigned integer
These data will be stored in an FcsDigi as a Time object and a 32-bit unsigned integer, respectively. (Currently the Time is stored as an unsigned integer, pending agreement on the Time object.)

Note that L1A is the time the Level 1 Global Trigger thinks the event happened. The state of the wall clock at that time is "written into stone" for the event. Internally, all times in the real BaBar data will be relative to the time of the L1A. This discussion will ignore the up to 12.975 microseconds of time translaction (latency shifts) that can be present depending on when a piece of the detector learns about the L1A.

When reconstruction eventually finds the true e+e- beam crossing for the event, it too will be specified relative to L1A (e.g. event happened at beam crossing -57 relative to L1A where L1A had a wall clock reading of 8082345348, i.e. 2 hours and 15.8 minutes after the most recent wall clock reset).

The actual length of the wall clock unsigned integer will be settled at, or shortly after, the Fast Control meeting in U.C. Irvine, on Thursday September 12, 1996. Answer is likely to be either 52 or 56 bits, corresponding to 2.4 or 38 years, respectively.

The 32 trigger lines are: 24 from Global Trigger (e.g. 1 A Track, 2 EMC clusters or IFR COSMIC) and 8 Auxiliary inputs (e.g. RANDOM, EMC LASER PULSER or "My favorite cable that toggles bits like so"). These lines are captured after masking and prescaling in the FCS. (The trigger system will store the values before masking and prescaling.)

For the simulation, we already have a convenient master clock, namely the GEANT clock for the physics (or null) event at T=0.0. It is hereby proposed that we have access to quantities relative to GEANT physics time, GPT:

    Fast Data for Simulation            Sim representation

    BX at L1A time, relative to GPT=0.0 in BX units One 32-bit integer
Note that background hits provided by the trgFrame Mixer modules are shifted relative to GPT by a random number of beam crossings. Their GHits thus have the time TOFG+/-delta (where delta is the shift between GPT and the background beam crossing time), whereas the GHits from physics event have the unchanged times TOFG. See trgFrame mixer code by Ed Frank for details.

The logical switch can either be true or false in the simulation, but can only be true in real data (assuming proper operation of BaBar).

The TRIGGER group will provide different ways of filling the Fast Data, consuming different amount of CPU, to be selected depending on the application and the patience of the user.

These fast data would live in the FcsData package. They will be augmented with the other data types that FCS will eventually report to reconstruction.

FCS Clock Access in Simulation

All simulation digitization modules have to operate in the BaBar Framework (or its successor). This will *not* work in BBSIM since we have to mix the background before we digitize (see BaBar Note # 260).

Access to the clocks is provided via the FC package written by Ed Frank and others, including Paul Dauncey and Stefan Gehrig. The FC package currently lives in trgFrame/FC* but may migrate to a new FcsSim package.

Currently all clock and time information is set up via C++ in the framework (or via dbin in standalone trgDC) and all access is provided via Fortran77 access functions. Examples of access are in the trgDC and trgEM packages.

A C++ wrapper interface to the access functions is prepared by Ed Frank for those detector systems that use C++ in their simulated digitization code (systems can always start with the fortran access).

The FC package takes into account clock synchronization, random phases between the physics event and any clock that runs slower than the BX clock, location of empty PEP-II beam crossings and much more. It has been extensively tested in trgDC and trgEM simulation studies. Examples of currently available access functions (see trgFrame/FCclockUtil.inc and trgFrame/FCclock.F):

    ClkPeriod(Speed)    Returns period of clock running at 2**Speed BX
    TatTick(Speed, Tick)    Returns GPT at tick with given clock speed
    TickAtT(Speed, T)   Returns tick number for GPT of value T
    BXatTick(Speed, Tick)   Returns BX number for tick with given speed
The period of a given is 2**Speed in units of BX (period between 238 MHz beam crossings, or 2**Speed * 4.2ns).

Plans

FcsData: Both T0 (event time) and the pattern of trigger lines need to be filled by Level 1 trigger packages into the FcsDigi.hh data container that will also be used for real data.
FcsSim: Migration of trgFrame/FC* code to FcsSim.

Manpower

Fred Kral, package coordinator, developer and user

Needs from other parts of simulation

Need to agree on a BaBar time class for the T0 (prototype exists in BaBar package).

SRT integration

Dummy versions of FcsData and FcsSim are available in SRT release 1.2.2.