Trigger Configuration File Changes for 2004 run

I. Preliminaries

Almost all of the significant changes were in the L0 configuration, and in getting the trigger prescales. There were also a few places where individual fields were moved between structures. I won’t be considering these here at all.

The conceptual outline for the calculation of the trigger configuration has not changed at all from last year. The specific structures have changed.

There are two representations of the configuration. The first is what the user enters. The second is a form that is easy to use to configure the hardware. Last year, the translation between these two representations of the configuration was performed by the GUI. This year it is performed by the nodes that use the information using helper functions provided by me.

The first step is to load rtsCfgLib.

vx: ld /RTS/xxx_lib/VX/rtsCfgLib.o

linux: -lrtsCfgLib

All of the prototypes for the functions in rtsCfgLib are available in RC_Config.h

The second step is to read the configuration file, and then build the internal tables.

STAR_CFG cfg;

TrgCfg trgtabs;

TrgPS pstabs;

ic_msg m; // assume contains the send_config message

// getConfigFile() handles endianness

if(getConfigFile(&cfg, &m) != sizeof(cfg)) error;

// Need to get PS’s

if(!cfgBuildPS(&pstabs), &cfg)) error;

// Need to get L0 tables

if(!cfgBuildTrgTables(&trgtabs, &cfg)) error;

{ ... configure ... }

// trgtabs contains dynamically allocated info

// so you need to free it when you are done

cfgFreeTrgTables(&trgtabs);

It is quite possible that the trigger setup you are sent is impossible to configure. For this reason it is important to handle the errors from the Build functions. You must free the trgtabs structure even if the build fails.

II. Pre-scale calculations

Pre-scale calculation is easy once you have called cfgBuildPS()

// Pre-scales for trigger x at each level

pstabs[x].l0ps;

pstabs[x].l1ps;

pstabs[x].l2ps;

pstabs[x].l3ps;

// These are not to be used for L0 configuration

// because the l0ps is the effective prescale

// for this trigger l0ps = L0ps(tw) * l1rescale(tw)

// It can be used for monitoring/analysis

III. L0 Configuration

rtsCfgLib contains helper functions for most of the main configuration tasks:

Building the PW table:

// Assume 16 physics bits

for(i=0;i<(1<<16);i++) {

PW[i] = cfgGetPWForInput(&trgtabs, &cfg, i);

}

Building the TW table:

// note the boundary conditions carefully...

// Also note that this procedure gives you the

// twtable for a given detector mask / pw

// The actual index of the TW LUT is something like

// (pw << 12) | i

// I’m not sure whether the detector bits or the pw are

// the high order bits, so it may be the other way

// around (in which case you have to use the right

// number of detector bits in the shift operation.)

// Also note that this loop will write some zeros to

// to the TWLUT (valid pw, but some detector is busy)

// however, it won’t write the zeros in cases where

// the physics was not satisfied... The assumption

// is that the whole table has been previously cleared.

for(pw=1;pw<=trgtabs.pwdef.n;pw++)

{

// assume 8 detector bits

for(i=0;i<(1<<8);i++)

{

TW[i] = cfgGetTWForInput(&trgtabs, &cfg, pw, i);

}

Building the AW table:

for(i=0;i<trgtabs.awc.n;i++)

{

int tw = i+1;

// assert(tw == trgtabs.awc.awc[i].TW);

AW[tw].PS = trgtabs.awc.awc[i].PS;

AW[tw].AW = trgtabs.awc.awc[i].AW;

AW[tw].pre = trgtabs.awc.awc[i].pre;

AW[tw].post = trgtabs.awc.awc[i].post;

}

Getting the L1 Rescale values:

// Rescale value for trigger trg, tw tw

trgtabs.info[trg].rs[tw-1];

Does a given physics input contribute to a given trigger?

// First get the PW, then check if the PW contributes

// input is input bits

// trg is trigger to test

int pw = cfgGetPWForInput(input);

if(cfgPwSatisfiesDaqTrgId(&trgtabs, trg, pw))

{

satisfied!

}