Minutes of Aug 29 L2 Global/Cal Meeting at FNAL
              -----------------------------------------------

Present: Dan Edmunds, Jim Linnemann, Dan Owen, Mark Adams, and Nikos Varelas

Jim presented the current status of the Global/Cal crate hardware.  A design for
the transceiver card is needed.  Mark was supposed to investigate whether such 
a board can be built from UIC engineers (with Dan E help).

After that we had a discussion on what needs to be done prior to the arrival 
of the preprocessor card(s).  The following list is an attempt to start this 
process of preparation:

    o DOCUMENTATION
        It is very important to document any piece of the apparatus, hardware or
        software.  Besides our own good, we need documentation for the new
        people that will be joining the efforts (MSU and UIC postdocs/students
        for example).  Some of the items that documentation is needed now 
        are the following:

        1. Update L2 crate/card diagrams (Jim)
        2. Establish a 1st version of the Input/Output data to/from global/cal
           crates (Owen/Edmunds/...)

        Item 2 is going to be one of the key issues of the trigger workshop
        at NIU next month.

    o CAL "SIMULATION" SOFTWARE
        Terry Geld has written a C program to identify e-'s and Jets and store
        the information in an ntuple. This was done for preliminary timing 
        studies (for the D0 upgrade report) and needs modifications.  Dan Owen 
        is currently the keeper of this code.
        
        List of immediate updates to the existing "simulation" code:

                    1.  Implement IN/OUT data buffers to check potential timing 
                        penalties.  Include crude data integrity checks
                    2.  Study tower threshold truncation (Dan E. pointed out 
                        that we may not have a choice in the hardware and L1 
                        will pass again EM and TOT towers - he is supposed to 
                        check on whether it is possible to get EM and HAD with
                        some amount of work)
                    3.  Study number of thresholds needed vs timing and for list
                        building 
                    4.  Think about triggering on LT and propagate
                        recommendations to the Physics Groups for comments
                    5.  Think algorithms more carefully in terms of physics and
                        time budget
                   

        w/ Administrator Logic
                    5.  Find a way for program communication so we can simulate
                        the talking between the ADM and Preprocessor modules.
                        We know how to do it on the VAX (through system flags)
                        but no idea how to implement it under UNIX.


    o BEFORE HARDWARE ARRIVES
        Under the current plan, UM will have a version 1 processor board 
        sometime in January.  We are currently not interested in getting the 
        early prototype version of the preprocessor (with less functionality) 
        this October since it may slow down the debugging process of that card
        and therefore the arrival of the v1 processor.  

        There is a lot or preparation that needs to be done before the arrival
        of the v1 board.  Here is a (partial) list of things to do.  We have to
        come up with a more specific planning in the very near future.

           1.  Find way(s) to talk to the preprocessor and to other workers in 
               the VME crate.
                 - NT path:  The TCC will be running Windows-NT so an NT path 
                             has to be implemented (Philippe)
                 - Unix Station:  We will be able to communicate through 
                             ETHERNET from a DEC-UNIX ALPHA station.  We will
                             use this path to download programs (for the test
                             station modules - since in the real system we will 
                             use the TCC) to the preprocessor.  
                             We can also access the processor's memory and CPU
                             through the debugger, but we will have to 
                             implement the ability to originate VME cycles so 
                             we can communicate to the other modules in the 
                             crate.  The later requires setting up the UNIVERSE 
                             chip in a similar (?) fashion as needs to be done 
                             for the NT path.  
                             I am not sure what needs to be done for the MB
                             communication(?)

                Is the UNIX path needed if Philippe finishes a version of the 
                NT path soon???  Then at UIC we can buy an NT and use that way
                to communicate to the VME modules.  The UNIX path is needed for
                at least the program debugger for the module that is connected
                to the UNIX box.  How do we run a debugger to another module in
                the VME crate?  

           2.  We need to write diagnostic programs that can be used to
               single/block write/read data to/from all modules in the crate.
               This is important during the debugging/learning period.
          
           3.  We will have to find a way to simulate data flow in the test
               crate so we can have an closer-to-reality environment to test our
               programs and VME/MV bus activity.