FcsData and FcsSim (Fred Kral) October 1996

Overview

Fast Control System data

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)

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

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

    Name                    Detector representation
    State of wall clock at L1A      <=56-bit unsigned integer
    State of 32 trigger lines at L1A      32-bit unsigned integer

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

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

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

Plans

Manpower

Needs from other parts of simulation

SRT integration