FIC


Receive whatever fiber outputs are used by
    a) the tracking L1 trigger, in particular L1 CFT, L1 CPS, L1 FPS
    b) possibly, for receiving raw data from optical splits from the tracking
    system for some or all of CFT, CPS, FPS

    Presently, these are seen as g-link running at 16 or 20b wide X 53 MHz

Buffer as necessary, up to 16 events maximum.  Likely FIFO size is 64KB (data)
plus possibly extra bits to mark end of event.  Buffering is necessary only to
handle the mismatch between fiber speed and Cypress output speed.


During transmission, recognize end of event.
    This may be nontrivial, as it seems that at least raw data does this by
    special values of data, rather than control symbols.

Send the data out on Cypress (320 or 160 Mb/s, to be decided) to be received 
by 
    MBT card    (320 or 160 to be decided)
    SLIC card   (160 most likely)

Number of channels?
    4 or maybe up to 8

If no VME interface, could live anywhere.  If VME, need to decide between 6U and
9U card; 9U preferred if space to dump into standard L2 crates

Issues:
    can ANY VME interface be avoided
        highly desirable
    can ANY SCL inteface be avoided
        highly desirable

    Since there is no flow control required, it is possible to imagine that the
response to a SCL Initialize for this subsystem is to wait an appropriate amount
of time during which it would be drained, counting on the DAQ system to stop
sending and the FIC itself to send as quickly as it can.

    Does it need any monitoring capability?
        Fast monitoring: 
            connector with 5-bit counter for number of events (0-16) in each
            channel
        Slow monitoring?
            VME registers to capture counts of all channels, then read out each
            count via VME?

Discussion on 28 Jan 1998

Block diagram:

    Pin Diode Receiver
    HP Glink/Clock  1.3 Gb/s probably
        selectable between 16 and 20 b wide?
    FIFO    64KB data
        with BSM = ????
    Cypress Hotlink chipset
    transformer/SMB connector for copper
    possibly in parallel a fiber driver
        LED?  probably exists up to 150Mb/s

Some questions:


Monitoring:
    requires an event counter.
        count up on start of event from HP chipset
        count down on end of event (generated by logic, or recognized, going
            into Cypress chipset)
        zero counter when FIFO recognizes it is empty
    not hard, no VME needed on-board.  If can expose on connector, could be
        someone else's responsibility to record it 
            (eg logic analyzer, or possibly HWFW scalers, or MBT digital I/O
                if need a place it can be read)

End of Event:
    in worst case (reading raw data), may need to recognized special address
        and generate end-of-transmission signal to give to cypress hotlink

Header/Trailer:
    need only generate header/trailer if reading raw data, assuming that all
    other sources (i.e. L1 CFT-style cards have developped that ability)

    If so, could grow a new interface with clock signals, and, like Muon and
    like STT, generate crossing number locally.  Also need an interface to
    resynch the clock.

    Think about: can I guarantee that the buffer needs to be only 1 event deep?
This would be the case if I can find that the guaranteed time between being hit
by the data (need to find time by pressing tracking readout and L1 cft experts)
is sufficient to empty the speed-shift FIFO into the slowest output.  At
16B/usec for slow Cypress copper, the longest event is 4KB, and this clearing
time would be 250 usec, so there is no such guarantee for raw data.  This makes
insertion of trailer/header in the data stream awkward.  But one could still
imagine a sequence such as
    recognize end event
    insert trailer
    send end event symbol to cypress
    insert header of NEXT event (even if one not available...)
    

Initialization:
    If no events are flowing, the FIFO will clear naturally in a time given by
    the FIFO size and the output speed, 64KB/16B/usec = 4msec.  Thus, if the
    alpha in charge of the FIC's waits at least that long before attempting to
    clear the objects fed by the FIC's, no special control is needed.  The FIC
    is self-initializing.  However, it may well be that this breaks in the case
    of the header insertion scheme above.


1) Can L1 CFT send an end marker on glink
2) can it also generate the standard L2 header 
    with locally generated turn number, requiring restting hdwe
        das is planned for STT output

Feb 7, 1998
In the fancier version of the FIC which has to read raw data, the data comes in
as grey code and needs to be translated into binary.