1 Design Details
This chapter provides details about the most important elements and concepts of the jTDC.
The central element of the jTDC is the BRAM recorder. Since most FPGAs feature lots of on-chip-memory (BRAM), the input status of each data channel (hit or no hit) is directly stored in the BRAM without doing any buffering, filtering or sorting. On Xilinx Spartan6 FPGAs, a single BRAM can be configured as 32x512, which provides storage for 512 32bit words (9 bit address space). Consider the following setup:
- BRAM is driven by a 200MHz clock and is always in write mode.
- 9bit-BRAM-address is incremented on each clock cycle (looping after 512 cycles).
- Input status of 32 data channels are used as BRAM inputs.
This setup allows to reconstruct the input status of all 32 channels for the last 2500ns (after the BRAM looped once). Since the input status of each channel is refreshed every 5ns, the BRAM recorder has a double pulse resolution of 5ns (if two hits are within 5ns, only one of them will be recorded).
A dedicated trigger channel is used to stop the recording by setting a busy flag. If enabled, the 9bit-BRAM-address is no longer incremented on each clock cycle and the BRAM itself is no longer in write mode, it is waiting for read-out. During read-out, this simple tdc is not recording any data.
The read-out is controlled by sending "readnext" commands via VME, which decrements the 9bit-BRAM-address. The currently addressed memory cell can be read via VME. After all data has been read by rewinding the BRAM, a "restart" command is issued which clears the busy flag and switches the BRAM back to recording mode.
To record data even even during read-out, the tdc needs a second memory page. On trigger input, the recording is not stopped but simply continued in that second memory page by flipping a page bit. The former write-to-page becomes the read-from-page by using the page bit as the 9th bit of the BRAM-read-address and the inverted page bit as the 9th bit of the BRAM-write-address.
To prevent further page flipping until the read-from-page has been read-out completely, the page bit is locked until a "restart" command is send. So trigger inputs during read-out are ignored.
To obtain a resolution higher than the 5ns from sampling with the system clock, the jTDC implements the tapped-delay-line method using carry chains.
To reduce the length of the carry chain, it is driven by 400MHz instead of 200MHz and its 84 steps cover a bit more than 2.5ns. The 84 bits wide high resolution pattern received from the carry chain sampler is encoded into 7 bits, representing the position of the leading edge of the signal inside the chain, the desired high resolution time information. This implies, that only one leading edge within 2.5ns can be recorded (the first one).
The 7bit information from the encoder is transferred to the 200MHz clock domain and the state of the 400MHz clock is stored in an additional 8th bit. If there are two hits within one 200MHz clock cycle, only the first one survives, so the double pulse resolution is 5ns.
For each input channel, the BRAM has to store the single hit bit (hit or no hit) and the 8bit high resolution time information. So lots of BRAM is needed, but there usually is plenty. The jTDC uses only 17% of the available BRAM on a Xilinx XC6SLX150.
The serializer automates the read-out process. As soon as it recognizes the busy state of the tdc (that means a page is waiting for read-out), it rewinds the page and extracts all hits and pushes the data into two FIFOs: An EVENT FIFO which contains an entry for each stored tdc event (containing the event number and the event size), and a DATA FIFO, which actually contains the data. The serializer generates some additional information for each event, stored as header and trailer words in the DATA FIFO alongside the hit data.
If the serializer is not able to push any more data in the FIFOs, because they are full (not beeing read out), it simply stops processing the BRAM, thus not issuing any readnext or restart commands. If the event is larger than the the DATA FIFO, the serializer has to truncate the event, because the EVENT FIFO is only written after the entire event has been pushed into the DATA FIFO - which will never happen, if the event is to large. This will be indicated by the error flag data fifo overflow in the trailer word of that event.
After the page has been read-out, the serializer issues the restart command, so the jTDC can process new triggers again. If a trigger was received during read-out, the trailer word of that event will contain the error flag trigger during read-out.
The serializer got its name, because it actually has to serialize the parallel BRAM data. The data chunk it gets from the BRAM recorder after issuing a readnext command contains the input condition of ALL input channels at a certain time. Most channels are probably empty and the serializer has to find the ones which contain a hit and has to push them into the data FIFO (one FIFO entry per hit).
In order to get this done fast, the channels are pre-processed in groups of 16 and each group sorts the channels which contain hits to the top. The serializer queries each group and jumps to the next if done. By doing so, the serializer needs only 8 clk cycles to process a BRAM chunk containing just a single hit.