How trigger throttling works

From HELIOS Digital DAQ
Revision as of 23:06, October 8, 2017 by Jta (talk | contribs) (Created page with "== Design and operation of the trigger throttling function == '''Throttling''' is a term used to specifically describe the temporary cessation of trigger acceptance messag...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Design and operation of the trigger throttling function

   Throttling is a term used to specifically describe the temporary cessation of trigger acceptance messages from the trigger system to the digitizer modules.  The reader is reminded that the trigger system receives various inputs from the digitizers and from external sources, and from those the trigger issues Trigger Accept messages that cause events within a given timestamp range relative to the timestamp at which the trigger condition was met.  Delay in the issuance and reception of the trigger accept message is, to first order, immaterial as the match comparison is between the timestamp of the discriminator firing and the timestamp contained within the Trigger Accept message, not the timestamp at which the message is sent or arrived.  As events flow through the digitizer, a queue of Pending Events is formed within the firmware for each channel.  When run in the Internal mode, every Pending Event is read out and passes unscathed to the board-wide FIFO of the digitizer.  When run in the "TTCL" (or triggered mode), only those Pending Events that have been marked by timestamp comparison against timestamps in the Trigger Accept messages are passed to the board-wide FIFO, and all other Pending Events are discarded.
    In general trigger messages can be generated at rates up 500kHz, with trigger algorithms independently capable of handling bursts of triggers at rates in excess of 5MHz.  Similarly, each channel of a digitizer module can fire at rates >500kHz (depending upon parameters) but limitations in both the internal queueing of per-channel information into the digitizer module's FIFO buffer and also the rate of FIFO readout over the VME bus can result in conditions where some channel(s) of some digitizer(s) would benefit by temporarily stopping the Trigger Accept messages to avoid buffer overflow or lost events.
    Throttling is distinct from and complementary to simple pre-scaling of the trigger rate.  Throttling is based on signals sent from the digitizers themselves to the trigger and thus forms a true closed-loop feedback system to modulate trigger rates.

Picture showing relevant inputs and outputs

Breakdown of solution by module type

Digitizers

    Correct selection of parameters within the digitizer is paramount for obtaining maximum throughput.  Each of the 10 channels of a digitizer is an independent pipeline that constantly runs at the full sampling speed (100MHz).  This full-speed operation is maintained throughout the pipeline and into the buffer that holds the Pending Events.  Only at the last moment, when data from Accepted Events is read out of the pipeline and into the FIFO system, does down-sampling occur.  While down-sampling will reduce data volume as written to the board-wide FIFO, the entire full-speed dataset is continuously processed; thus down-sampling only helps from a volume standpoint and cannot change the rate at which raw pipeline data is processed.  
    The FIFO system of the digitizer firmware has three stages. 
  • On a channel-by-channel basis each pipeline's Accepted Events are copied into a buffer called the Accepted Event FIFO. The Accepted Event FIFO is 2048 sixteen-bit words deep. Every event has a header that is 28 sixteen-bit words long; thus the number of events that can be simultaneously held in the Accepted Event FIFO is extremely dependent upon the amount of waveform information stored per event. Thankfully, down-sampling does help here, but if the Accepted Event FIFO backs up to the point where the next Accepted Event won't fit in the Accepted Event FIFO at the time the Accepted Event becomes ready, the event must be dropped and data is lost.
  • On a board-wide basis, a state machine scans the 10 Accepted Event FIFOs in round-robin channel order, copying events one at a time from each of the 10 Accepted Event FIFOs into a single Collected Event FIFO. The efficiency of this process is obviously dependent upon event size, but is also quite dependent upon the event rate present in each channel. Because the state machine scans in strict channel order with no preference, significant imbalance in the event rate across channels of an individual digitizer may cause loss of data.


Router Triggers

Master Trigger

Other Devices

Relevant data flows

Trigger Timing and Command Link from master to routers

Trigger Timing and Command Link from router to digitizer

Data Link from digitizer to router

Data Link from routers to master

Major firmware sections in use by module type

Master Trigger

Router Triggers

Digitizers

Other Devices

  • Specific links to the formal documentation for further details.
  • Explicit new drawings specific to the application that are explained with detailed text to show not only how it works but also how to set it up