FcsData and FcsSim (Fred Kral) October 1996
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:
Data types 1 and 2 are available to subsystem electronics via the FCS.
- Fast Clocks (from PEP-II via FCS)
- Fast Commands (from TRIGGER or ONLINE via FCS)
- Fast Control Master Transaction Records (FCS master)
- DAQ Data (from 7 subsystems: SVT, DCH, DRC, EMC, IFR, TRG, 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
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
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,
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).
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.
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).
Dummy versions of FcsData and FcsSim are available in SRT release 1.2.2.