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

L1 Trigger Upgrade Software

This page is intended to be a working document listing information and outstanding issues related to the offline software side of the L1 trigger upgrade. Please feel free to contribute information to this page!


[Documentation] [Tasks for June] [TSF] [ZPD] [GLT] [BLT/PTD]
[Framework] [Convertor]


L1 Upgrade Software miniWorkshop


Documentation

Deployment Matrix

Infrastructure Modules Validation Notes
Stage I

TSF Lut
TSF/ZPD Digis
L1DctEnv
Online

TSF Lut Loader
L1DctBuildEnv
Init Sequences (TSF Lut, etc.)
L1TNtuple
Interface (L3, L1FMon)
Online
Moose
L3 interface
L1FMon
Online?
Must be synchronized with online release.
Provides SP6 running with trgDC
Install 'invasive' infrastructure changes. Should not effect any output.
Stage II BLT Lut? New Tsf/Blt/Ptd/Glt simulation modules Moose
Production Data - MC validation
First simulation without trgDC.
Could never be used in production if this comes after SP6 production has begun.
Useful to have L1Sim based on data XTC files to produce data/MC L1 output ntuples?
Stage III 6-bit TSF Lut
ZPD Lut
TrigConfig
New Zpd modules
Zpd Lut Loader
Bootstrap "switching" procedure
Moose
Parasitic Data - MC validation
Final L1Sim code deployed
Needed before hardware switch
Validation of core modules can begin after Stage I

Immediate Tasks for June

See also

TSF LUT

For offline work we have new classes (with same names as old classes to be confusing).

L1DctConfig/L1DTsfLutEntry (abstract base class)

L1DctConfig/L1D5bitTsfLutEntry & L1DctConfig/L1D6bitTsfLutEntry (concrete instansiations with correct unpacking facilties)

L1DctConfig/L1DTsfLut (contains an array of pointers to L1DTsfLutEntry)

L1DctConfig/L1DTsfLutArray (contains 10 SLs worth of L1DTsfLut)

these are loaded from txt file using

L1DctConfig/L1Dct56bitTsfLutLoader

there is a new xtc for loading the new LUT into the board:

L1DctOnline/L1DNewTsfLutTC (not fully tested).

The old LUT classes have been renamed (by adding the post-fix Online to their name). I have checked that the old configure should still work with these old classes (the LutArrayP class has the same name as before - but its transient method now makes a L1DTsfLutArrayOnline object - we have checked that the DB -> xtc file (using RdfLoader) with the new class names produces exactly the same xtc file as is used in ir2 - hence the configure using the old system for the old TSF boards should work (andy Salnikov said this is a sufficient test).

The new offline LUT classes will break other code (specifically because the L1DTsfLutArray::entry(size_t sl , int address) now returns a L1DTsfLutEntry pointer). This should be easy to fix in L3 and other places it is used in.

I have put a flat txt file version of the LUT at:

/nfs/bbr-nfs03/detector/trg/L1SimTest/current6bitLUT.txt

/nfs/bbr-nfs03/detector/trg/L1SimTest/current5bitLUT.txt

these are symbolic links to the currently considered best LUT's. The actual LUTs are stored at

/nfs/bbr-nfs03/detector/trg/jamie/LUTTABLES/LUTS_FOR_BOARD/

and are not deleted so we can always reproduce results with an old LUT if desired.

At the moment there is a discrepancy in format between the LUT used in the board (& in the proper simultion - that decoded by L1D5/6bitTsfLutEntry) and that used by L1DczTest. I want to make L1DczTest use the proper format to get rid of a layer of confusion. does anyone mind if i do this???

TSF Parallel Data

Some scheme for keeping both types of TSF data needs to be determined. The best solution seems to be having two HepAList<L1DTsfDigi> with different names. The TC->Digi convertor can distinguish the two from the crate identifier. The TsfDigi must be modified to play nice with the different LUT versions.

ZPD Digi

Done

ZPD TC->Digi conversion

Done

ZPD LUT configuration

  • persistent object and TC <-> Digi convertion have to be added
  • Should we reduce the size of the data memeber?
  • The default values are to be checked! (e.g. the IPXY correction is false now)
  • ip correction is not dumped to VHDL format - Stephen needs to provide code for that

ZPD Algorithm Check

Code to read XTC file, run board simulation, and check hardware output.

  • The simulation is done. The packages from the release 14.2.0-l1t-1 repeats L1DczTest exactly.
  • Add the check that trig config has a proper switch set
  • Add the check of the 6-bit TSF lut (important)
  • replace abstract TsfLut with down_cast to 6-bit lut. phi() function should be removed from the abstract TsfLutEntry class
  • The removing of Tsf segments on the edges should be moved to L1DZpdReducer from L1DZpdFinder
  • Make sure Tsf provides a Timebuffer at clock 4 !
  • Make Zpd Digis from simulation objects - but where would they be used?
  • L1TNtuple


    Digi

    Make sure we can link binaries L1DctOep with shared libraries

    TSF Digi

    We re-do complete structure AND interface of L1DTsfDigi. Most of the information (including access to LUT) is gone except address, cell, superlayer and tick. Several other packages are affected by this change (checked with srtglimpse).
    The persistent object in L1DctDataP is changed as well (new is L1DTsfDigiObj_001). The check must be performed to prove that the new objects are read/written proper to database. (27May03 - it is not yet checked - olya )


    Track Segment Finder

    Wire 0 problem

    The data and simulation seem to have a different idea of where wire 0 is. Can somebody explain this in detail, please?

    Input Hit Issue

    I have found that for about 1 in 10 events the created TrigHits are different between the new simulation and trgDC. I started tracing this problem and it is something to do with small differences between the first and last ticks looked at. its not 100% clear to me that trgDC is right (it seems to stop at an earlier tick for these events). investigating this is on my to-do list but not very high up it - jamie

    Counter logic issues

    Another recently encountered problem is - it seems the counter logic is different in trgDC versus the hardware. in the hardware a new thit only effects a tsf counter if it arrives when the counter is in state 00 or 11, however in the simulation (trgDC and my simulation) a hit arriving at the time when the counter for that wire is in the 01 or 10 state causes the counter to get messed up (what acually happens is that the counter for the frst tick is used - but after this gets to 11 the counter will go straight to the evolved counter value of the second hit). this only becomes apparent if you have two hits on the same wire within 3 clk4s of each other. i have made a quick hack to my prrivate version of L1DczTest to test this will commit if it seems to be correct (this unfortunatly slows things down quite a bit). - jamie


    Z Pt Discriminator

    Configuration


    Global L1 Trigger


    BLT/PTD

    Simulation

    Simulation needs to be written (Anders).


    Production Simulation Framework

    Sequence Switch

    To allow simulation of old and new hardware from same production executable, one or the other L1 sequence must be disabled at begin job based on some configuration parameter (what?)

    Fcs

    All modules must use same fscClock object. If we want flexibility here, we need to attach this object to the L1DctEnv. The possibility to change IfdStrKey related to fcsClock from tcl for each module must be removed.

    Root ntuple interface

    it would be usefull to be able to switch between ROOT and PAW ntuples


    Teststand Data Convertor

    The teststand convertor takes simulated data and outputs a file which can be read directly into the teststand to compare with the hardware.


    Page author(s): Eric Torrence,
    Last significant update: Sep-10-2003 Expiry date: Dec-31-2003