BEC Test Summary of Activities

BEC Test Summary of activities

CW06------

03.02.2004

Setup: 1 ROD with 4 PUs, TBM, TM with 4 HOLAs, SPAC

Check of FEB-ROD connection by VME access. Glink locks, but PU does not see data. StFPGA needs to be reprogrammed

SPAC fuse problem

04.02.2004

SPAC repaired

Problems between AFS and SSH login. TDAQ will be installed locally

06.02.2004

Fatih made SW installation

CW07------

09.02.2004 Annie

StFPGA modified, programmed with stag_busy2_3

The ROD SW used for the production TestBench installed

10.02.2004 Annie, Julie, Henric, Pierre

The FEB and TTC environments are those of Henric. It means that 2 different SW are used: 1 for the ROD, and the other to drive the triggers. FEB sends pedestals, 5 samples/1 gain.

Managed to inject successfully TTC and FEB events up to the DSP. The number of events received is the same that the number of triggers sent

The SLINK drivers were installed successfully and 65k events were sent on the 4 links

New TBM from Orsay (#4) programmed with the latest code version

Managed to use the TTC RX clock on the ROD MB (through TTCVx, TBM, P3, TTCrx and TTC FPGA) TM #6 was repaired

11.02.2004 Julie

We injected FEB and TTC events to the ROD module. In the DSP we receive the same number of events (FEB and TTC) that the number of triggers sent. The data received in the DSP seems to be correct (data checked manually):

The event ID is incremental and synchronized in FEB versus TTC
The BCID are not synchronized and the difference between TTC BCID and FEB BCID is not constant. It seems that the BC Reset is sent only to the FEB, but not to the TTC system. The way the BCR are generated versus trigger is to be clarified
The RADD (words in which the cell number is indicated) are always the same for a given sample, which is normal
The samples seem to be correct compared to what is sent by the FEB

12.02.2004 Gelu

FEB SW upgrades completed

New release LargOnline-00-10-00 issued. It will be used for BEC tests

Stand-alone program prepared to compare INJ and DSP data

13.02.2004 Julie

The BCID in the FEB data are now synchronized with the TTC data (thanks to Stefan and Henric)

The InFPGA code is modified to have a complete transparent format VHDL code. It allows to validate the data "parallelization" in the InFPGA (thanks, in particular, to the number of ADC contained in ctrl1 word).

The InFPGA code checks the FEB data and looks for the following errors:

Parity for each word, except the start and end of event
Start of data alignment to check half-FEB synchronization
Identical gain for all samples of a given channel
Identical RADD, BCID and EVT ID value within the 8 ADCs of the same half-FEB
Identical RADD, BCID and EVTID value between two half-FEBs

Henric's file containing the FEB data that are sent was treated and incorporated in the DSP memory to allow data comparison.

CW08------

18.02.2004 Julie

Good news:

All 8 ROD inputs were checked and are working (use of a splitter 1->4).

The FEB data format is checked in the InFPGA and monitored in the DSP. We never found any error on all the events sent.

The DSP is ready for TTC synchronization check.

Bad news:

The TTC info is never synchronized with the FEB data (whereas it worked correctly last Friday).

The BCID are never the same, the difference is not the same either.

The event ID starts at 0 in the FEB and at 1 in the TTC.

Some times, we receive N TTC events and N-1 FEB events.

The tests were also made with the "old" DSP and FPGA programs. The results are the same as with the last codes.

19.02.2004 Julie, Henric

After systematic studies of the TTC-FEB synchronization:

The TTC and FEB events are synchronized again. The reason why, is not clear.

The evtID in the FEB always starts at 0 in the FEB, and at 1 in the TTC.

Is the FEB and TTC event ID counter initialized the same way?

Some times, one FEB event is missed in the ROD. It appears more frequently on some links (in particular on links 5 6 7 8).

The missing event is always the first, as if the Glink had some difficulties to lock on the first event!

Comment from Stefan

This has been seen also at BNL. It is not entirely understood. It is possible as Jacques said, that if you send all-zero data, the phase cannot be determined unambiguously (false lock). The first non-zero event causes re-synchronization, this time correct lock is achieved, at the expense of the first few events being lost. We should try in the future to use the DAV (fill frames) in between events. This should work, except for a "subtility" that some OTx have D+ and D- swapped. Inverting the link does not matter for data frames, but matters for Fill Frames.

CW09------

24.02.2004 Annie, Julie, Fatih, Gelu, Henric

Setup: TTC vi and TTCvx (installed in the ROC), SPAC (installed in the ROC), 2 ROD modules equipped with 6 PU, the FEC (with 1 FEB and 1 controller), new RCC of Gelu and Fatih

SW was successfully used at EMF for the first time. The control panel was not yet enough completed to control everything

We managed to inject TTC and FEB data to the ROD

26.02.2004 Gelu

The LargOnline-00-10-00 release is compiled for VP110 CPU. You can download it from:

/afs/cern.ch/atlas/project/LargOnline/releases

/afs/cern.ch/atlas/project/LargOnline/downloads

27.02.2004 Julie

The evID(TTC) = evID(FEB) +1. This comes from the TTC FPGA, the VHDL of which must be modified

Problems with VP110 were detected in LAPP again

CW10------

04.03.2004 Julie

Test with staging FPGA injection. Data from 4 slinks reception in FILAR. Use of LOCAL clock (i.e. local oscillator). 200K events sent, 200K events received. No error found.

Same test using the TTCrx clock on the ROD mother board. It means that the LVDS serializers were clocked with this clock. This test did not work. The Filar did not (or seldom) receive the events.

Maybe, a FPGA (for example OC) was catched out, because of the clock change. By default at reset, the TTC FPGA is configured to use the local oscilator. When we change the control register to use the TTCrx clock, what happens in the FPGA? I asked, the TTC FPGA vhdl was changed, so that by default at reset, the TTCrx clk is taken. Further investigations are ongoing

05.03.2004 Guy

First try to operate injectors. Continue next week.

CW11------

11.03.2004 Julie

Test with Staging FPGA injection

Use of local clk on RODMB: no error found in the FILAr (use of 4 Slink)
Use of TTCrx clk on RODMB: no error found in the FILAr (use of 4 Slink)

FEB injection

Use of SPAC master, FEC controller,TTCvi, vx, TBM, P3. Controlled by RCC. Use of a splitter 1->6. Readout at the FILAR Level using 3 Slinks)

200K events sent at a L1A frequency of 100 Hz. The number of events seen by the DSP is the same as the number of events received in the Slink. All the 3 Slinks receive the same data, which could indicate no error occured in the hardware.

Busy not yet handled

Problems observed:

BCID desynchronization(sometimes) due to a TTCvi command (bsend), which is not always taken into account.
First FEB event sometimes lost. The same seen at BNL, Glink not locked for first event
Event Id shifted by 1, TTC FPGA VHDL will be modified soon by Francois Corageou.
Bad FEB config in the RCC: error seen in RADDS, SCAC, gain. SW will be modified by Gelu.

Software updates

RCC and testbench installed and working correctly.
RCC SW has been modified to allow status check and monitoring. Still some improvements to perform.
VME pb worked around.

12.03.2004 Guy

I have 2 injectors, one sending fill frame, the other not.

I started both Injectors with 4 of the 5 links of each injector connected to the ROD sitting in another crate. I found that the links were locked (locked means locked and with no error on error bit) properly at power up. One of the link of the injector without fill frame would not lock as we know it can happen. All links started unlocking as soon as I configured the modules. The only thing related to the Glink in the configuration phase is the setting of the programmable delay line for the Glink 40 MHz clock.

I scanned different values of this delay line and discover that when increasing the value the links first start unlocking from time to time up to permanent unlocking. During this increase, which goes from 0 to 125 ns plus a zero delay of 12 ns, the clock comes back in the same position every 25 ns. As there is no data transmitted, the position of the clock by itself is of no importance.

My conclusion is that the delay line introduces jitter or disturbance to the Glink clock and it is related to the delay value setting. below 15ns the glink is stable, at 25 ns it is unlocking regularly, at 50ns it is always unlocked. This phenomena is more important and comes sooner when the module is cold.

I set the value of this delay to 0 and verified the setup and hold time of data relative to the 40MHz clock at the input of the smux. They are respectively 17ns and 8ns, which is OK. Prevously we had set a delay value of 20ns so that the clock was in the middle of the data.

With this setup using the injector with fill frames, I have injected many times 1 million of events at 10 KHz with incremental data and a few times 10 millions of events. There were no lost events and no data error (each word is tested) as long as I am not making any VME access to the Injector for checking the status.

When I am manually accessing the injector status then I got one or 2 events with data mismatch but no unlocking of the link. I did not loos any event, but it could happen, as the start of event is a data like any other.

The test was done with all links on the injector sending events, but only 1 or 2 links were connected to the ROD. I did try all the Injector links and they are working identically.

CW12------

19.03.2004 Julie, Jean-Luc, Jean-Marc, Henric

Injection with FEB and data reception in the Slink PC. Use of a transparent data format that allows easy data check. Only event IDs are checked by the DSP.

The TTC FPGA was modified (no more event ID shift).

The FEB is now configured correctly by the RCC.

The TTC synchronization is still not completely available.

System is now working well and in a reliable way.

The busy handling is working.

No systematical test was performed with TTC synchro (not yet).

We perform 2 "long term tests". DSP channels 1 and 2 received data, which had crossed 2 optical splitters 1->2, chanels 3 to 6 crossing 3 splitters. DSP 7 and 8 were not receiving data.

The first run was performed at a low L1A frequency, sending all events to the Slinks. 700K events were sent at about 200 Hz. No error was found by the PU in the FEB format (parity, uniformity of control words in all ADC, etc.). No event was lost, no error found at the Slink level.
The second was performed at 50 kHz, without sending any events after the DSP

Results are in table below. Some glinks (specially number 5) unlocked some times and damaged the events, probably because the connection between FEB and Glink was not point to point (to be checked).

Some TTC events were lost. This point is worring (in some others tests the number of missing events was much bigger). It is due to the DSP internal interrupt EDMA management (to clarify).

DSP1 / 2 / 3 / 4 / 5 / 6 / 7 / 8
FEB events / ad85661 / ad8565e / ad85661 / ad85661 / ad85630 / ad85661 / 0 / 0
TTC events / ad8565f / ad8565f / ad8565f / ad8565f / ad8565f / ad8565f / ad85661 / ad85661
Nb of glinks errors (+1 every 3s) / 0 / 2 / 3 / 0 / 64 / 0 / 4a9 / 4a9
Nb of events found in error by the DSP / 0 / 1 / 2 / 0 / 731 / 0 / 0 / 0
Error type / parity / parity / 731: parity 8: radd

CW13------

26.03.2004 Stefan

The FEB for the BEC test has the serial number 138344. This FEB was modified to send Fill Frames between events, as requested by Jacques.

CW14------

29.03.2004 Julie, Jean-Marc, Guy

Second FILAR installed and connected.

31.03.2004 Annie

New versions of Stag. FPGA and OC (vs 3.15) produced

Water cooled PS sent back to Wiener. Not expected soon

CW15------

05.04.2004 Julie,Guy

TBM from H6 beam setup is in second crate at EMF. The board is not operational. To be checked by Pierre

The Sdram read is now working (OC vs.3.15). The codes for staging mode and 32 samples events handling should be tested this week.

06.04.2004 Jean-Luc, Louis

FILAR does not treat B0F properly. Markus Joos made upgrade. Now DF vs.8 has to be used.

09.04.2004 Guy

This morning I installed the definitive setup for the BEC test in the EMF:

The ROD board, the SPAC master and the 2 TM have been moved in the ROD crate. A TBM has also been put in this crate.

The TTCvi and TTCvx and TBM remains in the TTC crate. One injector has been put there.

The sequencer of the injector drives the TTCvi and modules from both crates get their signals from the TTC system.

2 Glinks are connected between 2 outputs of the injector and the 2 inputs of PU1.

The Slinks are connected but have not been exercized at all

The busy from the ROD TBM to the Injector was not connected and the busy was disabled at the Injector level

The TTCvx we are using has not been modified to get better decoupling!

This setup has been tested with Jean Luc testbench for access to the ROD, with local program Xinj for the injector and special VME program for the configuration of the TTCvi with XVME.

The setup has also been exercized using the RCC program TestInj, which includes the Injector. In this program the TTC configuration has been desacivated as it is not configurable and it is different for the FEB and for the Injector. The TTC configuration is done with XVME.

Results from the tests:

All modules are seen and configured correctly by the different softwares

When the injector is not started, the Glinks are almost locked correctly. You see one of the 2 Glink led blinking every few seconds. The other one almost never blinks.

When the injector is started, the links are unlocking permanently. This is not due to activities in the Injector or ROD, but to traffic on the B channel of the TTCrx. If you take away the BCR cable between injector and TTCvi, then you go back to the previous situation where the links are almost ok, but there is now traffic on the links and L1A on the A channel of the TTCrx.

At the Injector level, I used the local Injector clock to drive the Injector Glinks only, with the rest of the board driven by the TTC clock (This is possible as this is the same clock which is used for driving the TTC system though time relationchip might be wrong and data transmitted incorrect) and in this condition the 2 links were perfectly stable (no blinking at all)

CW16------

14.04.2004 Daniel

OC vs 3.20 ready and tested at GeUni. It will be distributed next days

Acex 1K100 ordered, expected in a week, so OC FPGAs will be replaced in CW18

CW17------

19.04.2004 Guy

It is observed that when TTCrx clock (generated by TTCvx in INJ crate) is used, the Glinks unlocking periodically. If INJ clock is used, there is no unlocking

21.04.2004 Guy, Louis, Jean-Luc, …

Configuration tested: INJ, 4 channels, 1 ROD, 4 PUs, 4 HOLAs, , FILAR card, 1 to 4 Slinks. Clk from INJ

OC code v3.11, no calculations in DSP

Maximum data rate reached with different number of links connected to FILAR is 400 KB/s that is 25% less than PCI rate: 66MHz*8B = 528 MB/s. The trigger rate was max. 50 KHz (not 100 because event size is ~twice bigger than normal)

It is observed that INJ sends some data during initialization phase

22.04.2004 Guy, Louis, Marumi, Guillaume

One ROD in ROD crate has 8 glinks connected to the injector, some direct, some with optical splitters. 4 slinks connected to one filar board. TTC information coming from P3 through TTC system. The DSP copy the events from the input to the output without data and ttc verification

One injector in TTC crate with 4 glinks used. The sequencer drives the TTCvi and the data injectors. The TTC systen cannot be used for the injector. This is because of a bug when it is set in ttc mode and where it generates false events during the configuration. Event frequency is set to 100 Khz. Busy is used but comes through the front panel cable. (due to the fact that we do not use the ttc mode)

one filar board with 4 slinks. Verification is done on every data word received (not control words). It can be done for every event or for 1 of n events

All but last test have been done using dsp program 1.42t. last test was done with dsp program 1.43 where there is 3 more control words per ADC. This version has the official format0 format