playing around with the CRU and the SCA communication, we encountered some issues which we can reproduce.
After initialization of the CRU with the “standalone-startup.py” the SCA communication is not working. Probably because the GBT link is in GBT/FEC mode and TPC uses WB mode. Setting the GBT mode to WB with the “-g wb” flag does not resolve the issue.
Only after executing the “tpc-readout-test.py” script, the GBT link seems to be in the right mode. SCA communication works.
After 1) the busy flag of the SCA core gets stuck. It needs to be cleared, otherwise any communication will fail, even if the GBT link is in the right mode.
Remark: Setting the GBT link into the right mode should be part of the initialization script of the CRU and not part of the readout scripts.
Hello,
ok I will check the busy flag issue … it was fixed in the past, maybe an error was introduced when moving out the core.
The tpc-readout script is still part of the initialization of the card (wrong name) … we will make an effort to provide a single initi script with detector options.
I checked and the busy flag is cleared after a reset
Did you try to execute the reset of the core doing
# Reset the CORE
self.rocWr(self.base_add+CRUADD[‘add_gbt_sc_rst’], 0x1, debug)
self.rocWr(self.base_add+CRUADD[‘add_gbt_sc_rst’], 0x0, debug)
Concerning the init script we will discuss the issue during a meeting and we will reduce the number of commands to init the CRU for a detector.
seeing that we now configure and control 33 FECs (33 SCAs), we encounter some issues with the SCA communication. Every now and then, we see wrong readings, even from the internal SCA registers, of which we know the content. Executing the same command several times, the wrong reading jumps between SCAs.
The busy flag doesn’t seem to get stuck, however, the reading sometimes delivers a “0” back.
We encountered similar issues in the past with our own SCA FPGA core. This was basically a large shift-register and the decoding was done in software. One of the issues we saw was that there would actually be wrong bit-stuffing in the reply frame from the SCA. Does the SCA core currently in the CRU provide any kind of error report? Would be interesting to see where things go wrong.