Status of the new firmware

— DAQ user 2018/06/18 07:26

1. Clear separation of acquisition and data transfer: The firmware is not controlling the acquisition time, it just throws a BUSY when one TDC fifo is ALmost Full (25 over 32). The BUSYs are collected by the MDCC board that terminates the acquisition window when one busy is seen and do not restart a window until all BUSYs are low.
2. Data transmit per channel: Once the acquisition window is end, a BUSY is set per FEB until the data transfer is completed. It consists first to an Event packet containing the GTC (window count) and the Absolute BCID (readout time 200 ns steps). Then TDCs are scanned one by one , if not empty a channel packet is sent. Once all TDCs are browsed, BUSY is released and the FEB is in IDLE for the next window.
3. Trigger Mode : If the trigger mode is set, at data transfer stage, the trigger TDC (0) is first check, if the FIFO is empty, all FIFOs are cleared, BUSY is released and the FEB go back in IDLE state. It minimizes the dead time and only events with external trigger are transmitted.

• The data transfer per channel is less performant but compulsory since there is not enough space in CYCLONE II to handle large enough transfer FIFO for all channels. Nevertheless since TCPIP packets are adding 54 bytes of header it mights be a large overhead if only few channels are acquired in a TDC
• The maximum bandwidth of the Wiznet is indeed 50 Mbits/s and a feature of the chips decreases it to 33 Mbits/s (including TCPIP header)
• When we use Raspberry PI with USB ethernet interface the badnwidth is even decreased to 12 Mbit/s due to the sharing of the USB bus on those SOCs PC. We got much better performances (80 Mbits/s for 4 FEBs) connecting all FEBs to a switch and the switch to an additional Ethernet card on a standard PC. It will require to buy small PC with at least 2 ethernet card that can be installed in GIF.

Each new window is tagged with an event packet

Each channel is read separately if there is data. Since the counters are reset for each new window, the BCID can be calculated from the TDC time and 2 bytes are saved per channel. The channel number is kept to align data in words.

Remaining bugs : From time to time (<1/min),an empty event header is sent with same GTC number , good ABCID and no channels, the event synchr is recovered on next event header. Since the DAQ is synchronised on GTC, no inefficiencies is seen. It might come from MDCC firmware

The data forwarded to the Event builder are grouped per event. It has similar structure to the previous one.

  // 28 bytes header
  itemp[0]=_event; // Readout event
  itemp[1]=_gtc; // Window number used to synchronize packets
  ltemp[1]=_abcid; // 8 bytes
  itemp[4]=_event; // unused indeed
  itemp[5]=_adr; // IPV4 address 
  itemp[6]=_channels.size(); // Number of lines
  // and then list of channels in 6 bytes structure