Trigger
Back to DVCS3
Overall status as of May 03, 14: establishing communication with the trigger module using CODA. Working with BLT mode.
Documentation
[Trigger Manual (Sept 2013)] [Trigger upgrade talk (March 2011)]
Open Issues
In preparing the trigger for the Hall A 12 GeV DVCS experiment, some issues have been encountered. Currently, attempts are being made to diagnose the problems with the hope of having them all resolved. Below is a list of the problems along with questions related to these problems. (List Maintained by J. Roche)
- Stuck readings.
- from time to time the FIFO reading gets completely stuck reading either 0x07ff07ff (mid-March '14) or other words (on May '14), sometime for all event in the run, sometimes for just a few events. We do not know why it gets stuck or unstuck. [elog 264]
- Header word, spurious words, number of words
- The number of words in the FIFO for 1 event plateaus at 151 words, but according to the trigger manual, we should expect 153 words (Feb. 26 2014). Which is correct, 151 or 153? If it is indeed supposed to be 153 words, why does it plateau at 151 words?
- Why is the header word 0xa82aa8aa instead of 0xaaaaaaaa? In the data taking of mid-march, it appears that this word some times read 0xa86aa8aa instead of 0xa82aa8aa.[elog 264] Why? ==> This was a firmware issue. Magali updated the firmware and this issue was resolved.
- In block transfer mode (in addition to the issues with the data without block transfer) the word 0xffffffff is seen thrice, but there is no mention of this word in the documentation (Feb. 26, 2014). Why do these words appear?
- Solved: Why are the filler words currently reading 0x07ff07ff instead of 0x03ff03ff? ==> As per Magali's email on 03/06/14 this is a mistake in the documentation. The filler words should indeed be 0x07ff07ff.
- ADC readings
- In February, while reading pedestals, the data show that there are ADCs with zeros. What is causing these zeros? Why does the number of channel reading 0 fluctuate?[elog 268]
- In fact in the mid-march data taking, that a large (1.5 V, 50 ns) can "un-stuck" these zero. Still about 10% of the ADCs give non-stable reading (i.e. the large signal saturate the ADC but those 10% do not stay fluctuate out of saturation from time to time). [elog 257]
- With a large square signal 1.5 V, 50 ns, the maximum value read but he ADC is 2047 (11 bits). The ADCS are supposed to be 12 bits ADC. With don't the read 2095 at max?
- Processing time: we measured with a deterministic trigger that CODA takes 170 us to read the trigger module. Is that expected? [[1]see Elog]
- There are 4 LED lights for each FPGA inside the trigger - from left to right, for the 1st FPGA the red LED (D1) is on, for the 2nd FPGA the yellow LED (D6) is on, for the 3rd FPGA the green LED (D11) is on and for the 4th FPGA the red LED(D13) is on (May. 03, 2014). According to Magali, D14 and D15 should be on, but they are not (since April 30, 2014). What do the lights mean? Should there be 4 lights simultaneously in the on state?
Tips (known work around)
This article is being created to outline various issues that have been done while working on the DVCS Trigger and DAQ. The aim is to describe step-by-step how various issues were resolved. This is mainly to serve as a future reference should issues similar to these arise again later.
Major issues are listed as follows:
1. Trigger losing firmware data: causing all channels to give the same output (see ELOG) for most (or all) events.
2. Transfer CODA configurations from adaql2 (the old machine) to adaq1 (the new machine).
Issue 1: Losing Firmware data
Download firmware data again. In order to do this, you must have a working version of Quartus II on a laptop. Check if your laptop is a 32-bit system or 64-bit system. If the laptop is a 64-bit system, do the following (in this order unless stated otherwise):
1. Download or check that you have the 32-bit version of the following libraries for your OS (if you already have a 32-bit system, then you can skip this step):
- glibc
- libxext
- libx11
- libxau
- libxdmcp
- freetype
- fontconfig
- expat
2. Download the latest version of Quartus II (Here) .
3. Install Quartus II (the installer can be found in the bin folder) by running the appropriate script.
4. Check that the USB Blaster is working by plugging it into the computer and running quartus. Then in the menu do Tools->Programmer->Hardware Setup. You should see the blaster in available hardware items. This means that you are ready to go.