# Presentation: 605970

## L2 Software 

- Overview
- Algorithms
- Error Handling code
- Code management
- Connection to trigger DB
- Code testing
- Plan, schedule, manpower

- Peter Wittich, for L2 software types:
-  Stephen Miller, Heather Ray, Masa Tanaka, Tom Wright

## Overview

- C++ code running on  processor
- Have most strengths of C++: type safety, inheritance, inlined code
- Don’t use some of the ‘costlier’ aspects of C++: RTTI, exceptions, virtual inheritance, STL....
- No OS - Evaluation Board Software Development Kit (EBSDK) as pseudo-OS to provide basic services such as console I/O
- Code is compiled on DEC Workstation running OSF 4.0D and same CPU as on  board.

- Get data from clients
- Evaluate triggers
- Report trigger decision

- Basic job of processor:

- _Implementation:_

## Overview

- Initiate data transfer from clients
- Manage DMA FIFOs (receive data from interface boards) to receive next event
- Reformat data into local structures
- Error checking
- Evaluate triggers
- Communicate decision to TS
- On accept, read out RECES/muon board and create TL2D

- The strategy is to make the code
-  Correct
-  Robust
-  Fast
- in that order.

- Code runs on  processor, with a simplified event loop as follows:

- Code to be moved to FPGA

## Algorithms

- Necessary algorithms defined by CDF note 4718.
- ~40 triggers, covered by roughly 20 trigger objects/algorithms with differing options.
- 4718 ‘lite’ (all the physics, half the code?): an interim selection with somewhat fewer triggers.
- All algorithms -independent
- Allow porting to other platforms and to offline code.

## Currently existing algorithms

- AutoAccept         
- CentralElectron   
- Photon                 
- GlobalEt              
- HadronicB           
- Jet                        
- Dijet                    
- L2Error                
- SvtTest                 
- SvtTrack              
- SvtXftTrack         

- We currently have code in CVS for the following sets of triggers.

- Legend:
- tested successfully
- being tested
- 	code written, not tested
- placeholder

## L2 Software and CDF4718

- L2 options written are highlighted in Blue

- Many still need to be tested

- JSM slide:

## L2 Software and CDF4718 cont..

- Most algorithms have code written for them at varying stages of completion and testing.

## Code Testing	

- Currently, we have two methods of testing code
- Run it in the detector and check results (CDF as a pulser)
- Run Masa’s test code:
- Writes L2 raw data into 
-   runs triggers
- Read out TL2D and compare to expectation.

- Right Now:

- Longer Term:

-  Generate test fixture to run code in AC++ environment
-  L2_Pulsar to drive test patterns (similar to Masa’s code)

- Short of using CDF, no realistic method for getting timing or performance w/o L2_Pulsar.

- With this we can do:

-  Correctness checks
-  Simple robustness and timing checks

## Code Performance: Timing

- Only performance tests so far on prototype triggers:

- Time to run single triggers measured on single events
- Time to perform ‘bookkeeping’ measured
- Average performance goal is ~10 sec/event for entire event loop (excludes event loading)
-  Unclear (to me, anyhow) where we stand with respect to this goal.
-  However, clear paths to improving the software exist, if need be.

## Error Handling

- L2 Error handling in place and tested
- Code generates L2 timeout for three current error conditions:
- No L1 magic bus words sent
- CList buffer number mismatch
- SVT-XTRP BC mismatch
-      More error checks can be added pretty easily.
- On error, a message appears in run control explaining the error
- First two run by default in all triggers.

- To Do:
- Implement Error triggers
- Switch from L2 timeout to pulling CDFError
- Code exists, needs to be tested
- Implement error statistics

## Code Management

- Code exists in three packages
- All packages under version control system (CVS) in online DAQ repository
- Code specific to hardware implementation separated from trigger algorithms
- Trigger-table specific code limited to two two files that are created by TriggerDB and #include’d into the source code
- This is the only connection between the trigger DB and the code

- Unfinished business:

-  Need CVS package release version numbers in Trigger DB
-  Need to split L2 code from L3 code - update L2 code w/o changing L3, others (affects trigger tables?
-  Adapt build procedure to use well-defined CVS version.

## Trigger DB to code

- Trigger table-specific code is included via two files:

**void mainloop(void)             // The main prog.**
**{**
**// [code elided]**
**#include "L2cuts.hh"**
**  ****MagicBusDMA mbusdma;          //see mbusdma.h**
**  ****TSI tsi;                      //see tsi.h**
**  ****// event loop**
**  ****while (1) {**
**    ****// [code elided]**
**#include "L2triggers.hh"**
**  ****}**

- define triggers

- evaluate triggers

- // TRIGGER TABLE Physics_0_01_v-48
- numL2Trigs = 38;
- AutoAccept l2trig_787;
- l2trig_787._l2Bit = 14;
- l2trig_787._l1Bit = 21;

- // TRIGGER TABLE Physics_0_01_v-48
- l2trig_787.trigger();

- Code is auto-generated by Trigger DB GUI.

## Manpower/Schedule

- Identified L2 software writers:

-  Stephen Miller
-  Heather Ray
-  Masa Tanaka
-  Peter Wittich
-  Tom Wright

- However, it is unclear what fraction of these peoples’ time will be available to write L2 software.

- Goals:
-  Code for 4718 lite by mid-January 2002
-  Code for all 4718 triggers by end of January 2002