File L1_TRIGGER_QUALIFIER_NOTES.TXT
Rev. 29-JAN-1996

                 Notes about providing additional information
                       along with each Level 1 Decision
                  (e.g. the Mask of Specific Trigger Fired)

List of potential customers 
---------------------------

   1) Level 3 Customers, 
    only events that passed L2, 1 kHz rate

        a) readout to Level 3 (sequencer)
            Wants to know which Geographic Section i.e. VBD needs readout.
            Decoded info = 128 bits = 16 bytes

        b) Level 3 Supervisor 
            Possibly might want to pick which node/queue to use.
            Decoded info = 64 bits ?

        c) Level 3 Nodes
            Wants to know which filter(s) to run 
            Decoded info = 256 bits ?


    2) Level 2 Customers
       all Level 1 Triggers, 10 kHz rate

        a) L2 Pre-processors
           Wants to know whether to participate to this event, 
           and/or possibly what "level" of processing it should perform
           Decoded Info = 1-4 bits

        b) L2 Supervisor and/or L2 global node(s)
           Wants to know which filter(s) to run
           Decoded info = 16-64 bits ?

        c) L2 Framework
           Certainly needs to be closely coupled to the Level 1 framework and
           in particular needs the Mask of Specific Trigger Fired.


    3) (other) Front-End Geographic Sections
       There is no known need for a "standard" front-end geographic section to
       want to know information about which specific triggers have fired.



notes:  
------

    a) This information does not necessarily need to be available immediately
    and at the same time as the Level 1 information; shortly after (a few us)
    would be enough (especially during the minimum delay between successive L1
    Accepts. In any case, any additional triggering information mus be clearly
    connected to its Level 1 Trigger Decision.

    b) The L3 customers are NOT Geo. Sect. and do NOT receive a Serial Command
    Link, and thus need private delivery anyway.

    c) The Level 3 nodes can actually look inside the event data to extract
    the mask of sptrg fired from the L1 or L2 frameworks.

    d) The readout sequencer (and all L3 customers in general) do NOT
    want L1 information from the L1 Framework, but information that matches the
    L2 decision and that would thus likely come from the L2 Framework. 

    e) the L2 Global processor(s) and the L2 Framework are (likely to be) MSU
    devices and a private data path from the L1 Framework is more manageable

    
Conclusions:
-----------

    a) We cannot identify any system that is going to use the Mask of Specific
    Trigger Fired directly.  The exception being the Level 3 Nodes, but they
    have access to the event data and can read this mask from the L1 and L2
    readout.  

    b) In most cases (except the readout sequencers) the usefull information is
    condensed down to a few bits from the 64 bit Specific Trigger Fired Mask. 

    c) the most critical customers in the above list are the L2 Pre_Processors


Passing the Mask of Specific Trigger Fired 
------------------------------------------
would (pros)
    - allow deducing the necessary information
    - be flexible, and device-independent
    - allow generating any arbitrary amount of derived information

but would (cons)
    - require run-to-run download from COOR about Specific Trigger programming
    information
    - require a lookup or a software routine to derive the necessary information
    which is a problem in time critical systems like the the L2 pre-processors
    - transport more information than the useful extracted information 
    (in most cases)

and there is no room on the Serial Command Link for 8 more bytes of information