April 2013

Date : 1st April 2013 (K.Allada)

The new TI has a 5-pin connector which connects to faSDC. Below are the instructions from B. Moffit for using this feature.

From B. Moffit:

These are the things you need to do in order to properly use the ribbon cable that connects the faSDC to the TI's FADC connector:


- On the TI Enable dip switch 6 on SC01 (dip switch back near top of Module).
  - This will allow for 250MHz clock to go out through FADC ribbon output. 

- Update to "latest" driver in 
  /site/coda/3.0/linuxvme/ti

- Compile for ARCH=Linux
  make -k ARCH=Linux
  make -k ARCH=Linux tiFirmwareUpdate

- Get the newest firmware for the TI at:
  https://coda.jlab.org/wiki/Downloads/Firmware//ti96.svf

- Update the firmware on the TI:
   tiFirmwareUpdate <VME Address> ti96.svf
    where the <VME address> is the a24 vme Address of the TI... e.g. slot 3:
    <VME Address> = 0x180000


Stuff that needs to be changed in your crl:

- Change busy source:
  tiSetBusySource(TI_BUSY_LOOPBACK | TI_BUSY_FP_FADC);

- Make sure faInit contains the flags necessary for all Front Panel inputs:
   bit    0 (sync source): 1
   bits 3-1 (trigger source): 0 0 1
   bits 5-4 (clock source): 0 1
   High 10bits: A16 Address of FADC signal Distribution module (faSDC): 0xea00 (?)

  that is:
    iFlag = (1<<0) | (1<<1) | (1<<4) | (0xea00);
   OR
    iFlag = 0xea13;
 

- Change faSDC into "level translator" mode... after 
   faInit(...)
  make a call to:
   faSDC_Config(2,1);
  - The '1' is to enable the busy from ribbon 1.  This argument is a mask.. so if you're using
    a different connector, use a bit shift.  E.g. for connector '3':
      faSDC_Config(2,1<<3);
    or if you have several fa250s (using 1 and 2 in this example):
      faSDC_Config(2, (1<<1) | (1<<2) );
    which is equivalent to:
      faSDC_Config(2, 0x3 );

- Change the manner in which Sync is delivered to the system:
  - Replace 
     faSDC_Sync()
    with
     tiSyncReset()
  - This may already be defined in tiprimary_list.c... if so... just comment out
    the call to faSDC_Sync() in your readout list.


The Data format from the TI is found on page 6 of this document:
http://zimbra.jlab.org/home/moffit@jlab.org/docs/eventbuilding.pdf

The TI delivers the "Trigger Bank"

Date : 24th April 2013 (K.Allada)

I did a different measurement to understand the deadtime from the FADC. I used a fixed rate pulser and measured the time difference (dt_event) between consecutive events (using FADC time-stamps for every event). Ideally (for zero deadtime), dt_event should give us back the input trigger rate. Any deviation from input trigger rate is the measure of deadtime.

The integration window was set to 70 (280ns) and was running in pulse integral mode (mode 3). The theoretical rate limit is 468 KHz with this window size.

Here are my observations (see pdf file for plots Media:deadtime.pdf):

1. Zero deadtime (as calculated using above method) up to ~280 KHz
2. Beyond ~280 KHz there is non-zero deadtime (also "Data not ready" errors)
3. The dt_event is a sharp peak (as expected) for rates below ~700 KHz or so.
4. Beyond ~700 KHz there are two distinct peaks in the dt_event. I think around here FADC is loosing events due to a different reason than it was when the rate was lower (~ 300-700 KHz range).

Conclusions (also see PDF file above):

1. The theoretical rate limit is set by "time to write out data from the buffer" which is 2.136 uS (468KHz) for window size of 70(280ns).
2. If we are below this rate limit, we can reliably calculate the deadtime.
3. If we go beyond this limit then deadtime calculations become unreliable due to others reasons FADC might lose events (as seen by two peaks in time difference between events)
4. When I compare the deadtime calculated in this way to my previous method (where I actually count lost events in FADC), they agree for rates up to ~450 KHz. Beyond this rate they don't agree. And I think both methods fail beyond this rate.