Implementation of Pseudo And-Or Terms
             ----------------------------------------


                                                Original Rev.  19-MAY-2003
                                                 Current Rev.  6-JUNE-2003


The intent of this file is to document the details about the way that
we implement the Pseudo-Term function in the Run II Trigger Framework.
This collection of information may start out as just a number of
points with the hope that it will eventually grow into a full text
description of this part of the Trigger Framework.  This file is also
a convenient place to keep a description of what Pseudo-Term functions
have been implemented in what version/revision of this FPGA.


Points about how we will implement the Pseudo-Terms:

1. AONM FPGA designs that include Pseudo-Terms will be used in both
   the Upper and Lower And-Or Network Modules.  The Pseudo-Term system
   is designed to handle up to 48 Pseudo-Terms in the Upper And-Or
   Network Modules and a separate set of up to 48 Pseudo-Terms in the
   lower And-Or Network Modules.

2. PT's in the Lower And-Or Network Modules must be defined in terms of
   Hardware And-Or Terms 0:127.    PT's in the Upper And-Or Network
   Modules must be defined in terms of Hardware And-Or Terms 128:255.

3. The PT's in the Lower And-Or Network Modules are referred to as And-Or
   Terms 256:303.  The PT's in the Upper And-Or Network Modules are
   referred to as And-Or Terms 304:351.

4. All And-Or Term functions that are used in the definition of PT's
   must be "locked" to a fixed Hardware And-Or Term by COOR.   E.G. if
   a And-Or Term that represents  >= 1 Trigger Tower over 5.0 GeV EM
   is used in the definition of a PT then COOR must lock this function
   to a fixed Hardware And-Or Term input, i.e. COOR must always use the
   same EM Reference Set and the same Count Comparator to implement this
   function.

5. Configuration of the And-Or Network Module FPGA's will continue to
   be managed by ".dcf" and ".dci" files.  We will need to separate
   the files that control configuring of the Upper and Lower And-Or
   Network Modules.

6. We will use the same version FPGA firmware in the Lower Exposure
   Group AONM card as in the Lower Physics AONM cards.  In the Upper
   Exposure Group AONM card we will use the same FPGA firmware as in
   the Upper Physics AONM cards.  From the first use of Pseudo-Terms
   all 6 of these L1 AONM cards will be configured with FPGA firmware
   that implements the full set of new registers that control the
   operation of the Pseudo-Terms.

7. TRICS will still need to be able to work with AONM/FOM FPGA firmware
   that does not implement the new registers that are used to control
   the operation of the Pseudo-Terms.


<=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=>


6-JUNE-2003
-----------

Official request for the first P-Term.  It is to be:

    CEM(1,HI)  or  CEM(1,MEDHI) CEM(2,LO)  or  CEM(2,MEDLO)

Assume that things are setup such that COOR will use:

   EM_Low      will be built on   EM Ref Set 0
   EM_MEDLOW   will be built on   EM Ref Set 1
   EM_MEDHI    will be built on   EM Ref Set 2
   EM_HI       will be built on   EM Ref Set 3

   count thresholds of 1   will be built on  Count Comparator 0
   count thresholds of 2   will be built on  Count Comparator 1

Thus the hardware And-Or Terms that are used in the definition of
this P-Term are:

   CEM(1,MEDHI)   arrives at the TFW as And-Or Term # 130
   CEM(1,HI)      arrives at the TFW as And-Or Term # 131
   CEM(2,LO)      arrives at the TFW as And-Or Term # 132
   CEM(2,MEDLO)   arrives at the TFW as And-Or Term # 133

This will be the first P-Term in the upper And-Or Network Module.
Thus COOR and TRICS will refer to it as  And-Or Term # 304.

The official name of this P-Term is:  CEO(HI)

The requested P-Term is:

          CEM(1,HI)  or  CEM(1,MEDHI) CEM(2,LO)  or  CEM(2,MEDLO)

which translates to:

     And-Or_Term_304  =  AOIT_131  or  AOIT_130 & AOIT_132  or  AOIT_133

which in the FPGA design reduces to:

             PTerm_0  =  AOIT_3   or   AOIT_2 & AOIT_4   or   AOIT_5  


For diagnostics in this first production P-Term implementation we will
include a second P-Term to be used for testing.  Directly route the Hardware
And-Or Term for Tick_Select_0  to the highest P-Term in this module, i.e.
AOT # 351.  We can use this to make the following types of tests:

   Run just on AOT 351
   Run on AOT 351 ANDed with the real Tick_Sel_0
   Run on AOT 351 Anded with Tick_Sel_1  which is set to be the same as, or
                                         one before, or one after Tick_Sel_0

Recall that   Tick_Select_0   arrives at the TFW as  And-Or Term # 251

So the design for this P-Term is:

     Highest P-Term in the upper And-Or Network Module == Tick_Sel_0

which translates to:

     And-Or_Term_351  =  AOIT_251

which in the FPGA design reduces to:

     PTerm_47  =  AOIT_123


The design for all the above is in:   $FPGA_DESIGNS/pt2_aonm_uber/pterm_proc
It was implemented in: pt2_aonm_uber/xproj/ver5/rev1/pt_aonm.exo   6-JUNE-2003

<=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=><=>