Sept 2, 1997 L2 Meeting at MSU: Philippe, Dan, Jim

TCC test stand:
    where physically?

Mentioned to Philippe discussion of monitoring on Friday 29 FNAL meeting

Discussed TCC/Download interface
    Ascii messages from COOR -> C structure -> memory layout for Alpha

    C structure needed both in TCC and for simulation
        code can run on generic Unix
    memory layout
        could be C code, with byte swap etc routines provided by Philippe
        must be at detailed level so as to send to alpha via VME
        
    Author:
        does Philippe do both of these, or do we have these done by 
            MSU and NIU physicists?

===================================================
Question for Myron:
    How is restart capability in Alpha implemented?
        preferred method is VME-visible register
        rather than needing Universe set up, or debugger working
===================================================

Start planning for TCC work:
---------------------------
Dowloading code:
minimum is being the BOOTP/TFTP server which provides the .exe for the alpha
More complete service would include
    readback of status (where, how soon) to verify download of code/data was OK
    what order to start nodes
    
Synch errors:
    default is just clear out buffer counters to "all free"     
        this requires new message(s) from Admin to workers
More violent restarting such as re-init of data structures or new code by
    hand intervention

Monitoring:
    VME window to memory must include a "this is fresh data" word
    If TCC is to be able to dump events, the Universe Chip (read) memory window
        must overlap with the MBus data mapper windows

Other asynchronous (faster than 5 sec?) communication with TCC?
start/stop run?
    needed?  just let timeouts occur and have them suppressed by TCC if during
        a run pause
clear scalers?
    5 sec is probably fine if starting from paused
    what if want faster run turnaround?
TCC communication with nodes:
    directly only to/from Admin, (except event dump???)
        let Admin distribute messages such as "clear scalers"--new Admin msg
TCC "console" function
    where VME cycles can be performed
    does this substitute adequately for Shea consoles?

Debugger:
    can it be connected after the fact only in case of disaster?
        motivation: simplify the online environment by leaving it off
    does using it at all imply huge performance penalty
        compile/debug/noopt