Subject:  SVT 30 MHz Operation - L1 Trigger Latency
     Date: Mon, 18 May 1998 16:08:37 -0700 (PDT)
     From: Ariane Frey <frey@scipp.ucsc.edu>


 Additional Trigger Latency Delays due to SVT 30 MHz Operation
 =============================================================

 SVT 30 MHz operation means that the Readout Module will send 
 down the command stream through the optical link at the nominal
 speed of 60 MHz. On the SVT MUX Modules these commands will then 
 be decoded by a FPGA and 'stretched', and thus provided at 30 MHz 
 to the AToM chips. 
 The data from the chips will be sent back to the ROM at 30 MHz.
 During data taking mode, only global commands will be sent down 
 the G-Link. These all have a fixed length of 12 bits 
 (one leading 0, start bit, five command bits and 5 data bits)

 The 30 MHz operation affects the trigger latency budget in the
 following way:

 A) Common component of the L1 latency budget for BaBar:
    ----------------------------------------------------
   
    Due to the stretching of the commands, the minimum spacing 
    between commands is increased. 
    I'll define here the minimum spacing as the number of clock 
    cycles between the start bit of the previous command and the 
    start bit of the next command.
    If the chips could operate at 60 MHz, this minimum spacing would 
    be 12 clock cycles, just the command length.
    At 30 MHz, however, the minimum spacing between command start
    bits is 24 clock cycles since the ROM delays the start of an
    L1 accept command upon receipt of a trigger by a long enough
    period to ensure that a previous command being sent has been
    received by all front-ends.
    
    ---> For the BaBar global trigger latency we add 
                12 clock cycles, i.e. 200 ns.
                ----------------------------

 B) Subsystem component of the L1 trigger latency budget
    ----------------------------------------------------

    In addition to the global trigger latency, running at 30 MHz
    means: since we transmit the commands at half the speed, 
    it takes 12 clock cycles (60MHz) longer for a command to be
    decoded by the AToM chips. 
    The FPGA on the MUX has also some overhead and delays the rising 
    edge of an incoming command by 3 or 4 clock cycles, depending on the
    phase of the 30 MHz clock. 
    
    ---> The additional SVT subcomponent trigger latency is
         12 + 4 = 16 clock cycles i.e. 267 ns
         with a jitter of 1 clock cycle.
         Adding the global trigger latency we end up with 
          28 clock cycles = 467 ns.
          -------------------------
 
     This corresponds to 7 pipeline cells when running the pipeline 
     at the nominal 15 MHz.
           
     Just for comparison: The propagation time for a signal from the 
     ROM to the front end through 38m fiber optics cable, electronics
     and the ~20 m front cables is about 280 ns (ball park figure), 
     corresponding to 17 60Mhz-clock cycles and 4 pipeline cells.