Date: Wed, 4 May 2011 16:17:28 +0200
From: Kael Hanson <kael.dylan.hanson@ulb.ac.be>

Subject: Re: ARA Station / IRS raw event format RFC

Thanks Gary,
FYI, I put this on doc DB - it is our official document store: many
things that could be better but I can definitely live with it.  The
topics areas setup have sofar been a pretty good mapping - I put it
under Data Acquisition > Data Structure with keywords event DAQ
readout format firmware.  So I hope it will not get tucked away and
lost therein.

Sorry, the rest of this mail is a bit technical so if you are not
interested in the low-level operation of the triggers and the readout
then you can save yourself some time.

Thomas has gotten the jump on me and started writing the trigger
handler and event readout firmware modules.  We are already coming up
with some questions regarding design that should be discussed in a
larger group but we will definitely talk about in the phone call that
Thomas, Ryan, Jonathan, and Patrick now are attending:
 *  Triggers : the event format has room for 16 trigger lines
    although now I can really only foresee 3: (1) a CPU / forced /
    clock / minbias trigger that would go off every second or so to
    collect minbias waveforms; (2) a calibration trigger; (3) the >N
    antennas fired trigger.  Note we are not writing the triggers
    themselves at this time (we could - these triggers are kind of
    easy - but I am scared of the ToF trigger still) but just the
    module that aggregates them.  Some questions here:
     +  Each trigger needs to have a configurable readout pre- and
        post-trigger or can there be just one, at least to start?
         Having different lengths allows for a readout order problem
        which I will describe below.
     +  How will the configuration take place?  There's going to be a
        set of registers somewhere I guess.  Should we just have a
        bunch of wires coming into the module or it there going to be
        a configuration state machine.  I guess I need a bunch of
        registers eventually so maybe just the wires option. OK to
        code this like 8*reg + 4 so that we could pack this into
        4-bit registers.  Yeah, I am getting paranoid about logic
        resources but that's probably because I am using the
        Spartan-3 right now that only has about 1000 CLBs.
 *  Event Readout : We've been thinking that the trigger itself could
    raise it's line at the trigger moment and then the readout would
    happen when the line fell again.  I realize that one would like
    to get the readouts in the pipeline as fast as possible but I'm
    guessing this in reality would come up as a delay of maybe
    200-400 ns which is 0.1 % of the total readout time.  What should
    happen when two readouts overlap?  The readout needs to expand to
    cover, I guess.  Imagine trigger A wants a readout at 100 ns and
    trigger B wants a readout at 200 ns and both want 400 ns
    readouts.  Then the readout should happen from -300 ns up to 200
    ns - 500 ns in total.  What happens in the case of a short
    readout coming first and a long readout coming next.  We won't
    necessarily have an extended readout but we could have started
    the state machine to readout a block later in time associated
    with the first shallow-readout trigger than the first blocks of
    the follow-on deeper-readout trigger.  Having a single readout
    length obviates this problem.  OK it is not impossible just a
    pain.

Kael


Kael HANSON
Université Libre de Bruxelles
Faculté des Sciences
Service de Physique des particules élémentaires
Boulevard du Triomphe, CP 230
B-1050 Bruxelles Belgique
Tel : +32 (0)2 629 35 82
Fax : +32 (0)2 629 38 16
GSM : +32 (0)479 88 18 17
Off.: 0G-125, Gebouw G, VUB Campus