Tuesday May 13:
    brainstorming on script downloading options

Action items:

    Dan: think about synchronous-with-event processing, esp how DMA engines
        get set up
        in progress; 
            merge Input and Output buffers, have sum > VRB buffers
            rethink whether any mechanism that would allow FEB if R/O to L3
                fails, eg.

X    Jim: think about how much complication happens with downloading of params
        without full download of .exe and consts
            not much
X        also ask Jan H. about how scalers interacted with test runs in RI L3
            see below
startup
----------
code download (+ constants)
init node
    (From whom?  SCL or is this a different "init")
receive programming
parse/check tools and params
report back ready status


synchronous with event processing
----------------------------------
[Dan will think about]

asynchronous with event processing
-----------------------------------
input buffer management (DMA setup)
readout buffer management 
        VBD micromanagement
SCL management

Manage state and advertize
end run report
alarm detection
      reporting
monitoring collection
           serving/packaging up

Error handling:
--------------
two types:
    tool errors
    data movement errors
            eg consistency check failure
    may need to report via SCL error reporting


SCL commands: (for which we need a response)
-------------
    new L1 trig  (qualifiers come along, 
        eg M+P
           "ignore event"  (should this be done this way, or by having no
                filters enabled--if so, frame has to default bits to on and turn
                off as filters fail)
    L2 accept/reject    [verify our precognition of result was correct]
    INIT

Issues:
_______
Do COOR pauses need a response?  
        Or just ignore and let frame stop sending events

monitoring: 
        serve up packaged, 
        or just raw info

* what counters need regular database logging in order to be able to 
        analyze the run 
        monitor the run

* how not to be pestered by test runs (again, scaler issue vs logging)

* how to salvage physics data of run if l2 global dies during a run
    is it acceptable to say "couldn't build full run summary?"

How to start:
    always full restart and download?
        how long would this take for global + preprocessors?
    just reload params: partial restart
        [how much complexity does partial restart cause]
    when are scalers cleared?
    
    From COOR:
        full download of code + params probably kills scalers
        or...add this to your list of things to work on

Comments from Jan H on RI L3 [May 7 1997]

separation of exe and constants cost little in practice since I/O path for
    constants was not difficult, though gained little in flexibility in the end
    [release procedures used later in run generated both]

separation of parameters and scripts cost little, but no strong argument in its
    favor

separation of run start from init made sense and cost little

scalers:
    nodes had a simple "clear scalers/no clear" run start
        COOR issued clear only for global run start
    surveyor knew about start of test runs 
        captured scalers at start of run
        info requests were in context of a specific run; gave differences
            so save scaler start values for each individual run
            present numbers since start of this run
            [who knew which bits were owned by a run? GM? Run Summary?]
        [Cf L1: reset scalers by bit when bit reprogrammed]

    GM periodic requests used as basis for run summary ["logging"]
        so crash during a run resulted in at least some info