Readout artifacts

O² O² CRU
1

Dear CRU team,

during our readout tests we observed the following behavior.

  1. Executing the readout a few times in a row (start DMA, start DAQ, stop DAQ, start DMA, start DAQ, …) with the same parameters for the roc-bench-dma tool, the file sizes vary for each readout.
-rw-r--r--  1 talt z2 17825792 Oct 11 21:37 rdo_0-7_001.bin
-rw-r--r--  1 talt z2 14680064 Oct 11 21:37 rdo_0-7_002.bin
-rw-r--r--  1 talt z2 15728640 Oct 11 21:37 rdo_0-7_003.bin
-rw-r--r--  1 talt z2 16777216 Oct 11 21:37 rdo_0-7_004.bin
-rw-r--r--  1 talt z2 18874368 Oct 11 21:37 rdo_0-7_005.bin
-rw-r--r--  1 talt z2 18874368 Oct 11 21:37 rdo_0-7_006.bin
-rw-r--r--  1 talt z2 17825792 Oct 11 21:37 rdo_0-7_007.bin
-rw-r--r--  1 talt z2 14680064 Oct 11 21:37 rdo_0-7_008.bin
-rw-r--r--  1 talt z2 15728640 Oct 11 21:37 rdo_0-7_009.bin
-rw-r--r--  1 talt z2 17825792 Oct 12 13:37 rdo_0-7_010.bin
-rw-r--r--  1 talt z2 18874368 Oct 12 13:37 rdo_0-7_011.bin
-rw-r--r--  1 talt z2 16777216 Oct 12 13:37 rdo_0-7_012.bin
-rw-r--r--  1 talt z2 17825792 Oct 12 13:37 rdo_0-7_013.bin
-rw-r--r--  1 talt z2 18874368 Oct 12 13:37 rdo_0-7_014.bin
-rw-r--r--  1 talt z2 14680064 Oct 12 13:37 rdo_0-7_015.bin
-rw-r--r--  1 talt z2 17825792 Oct 12 13:37 rdo_0-7_016.bin
-rw-r--r--  1 talt z2 17825792 Oct 12 13:37 rdo_0-7_017.bin
-rw-r--r--  1 talt z2 16777216 Oct 12 13:37 rdo_0-7_018.bin
-rw-r--r--  1 talt z2 18874368 Oct 12 13:37 rdo_0-7_019.bin
-rw-r--r--  1 talt z2 17825792 Oct 12 13:40 rdo_0-7_020.bin
-rw-r--r--  1 talt z2 14680064 Oct 12 13:40 rdo_0-7_021.bin
-rw-r--r--  1 talt z2 18874368 Oct 12 13:40 rdo_0-7_022.bin
-rw-r--r--  1 talt z2 16777216 Oct 12 13:40 rdo_0-7_023.bin
-rw-r--r--  1 talt z2 18874368 Oct 12 13:40 rdo_0-7_024.bin
-rw-r--r--  1 talt z2 15728640 Oct 12 13:40 rdo_0-7_025.bin
-rw-r--r--  1 talt z2 16777216 Oct 12 13:40 rdo_0-7_026.bin
-rw-r--r--  1 talt z2 15728640 Oct 12 13:40 rdo_0-7_027.bin

This seems a bit strange to me, seeing that the DMA engine is configured with identical parameters every time.

  1. It seems there is some “hidden feature”/bug. By accident i started the DMA transfer without disabling the DAQ before. So data is taken immediately after the roc-bench-dma is started. After this, i continued taking data with the correct procedure (DMA start, DAQ start, DAQ stop, DMA start, DAQ start, …). When analyzing the data i saw that in approx. half of the events the SYNC pattern is missing. Data looks alright but there is no SYNC. Seems to be random which event is affected.

Cheers,
Torsten

2

Ciao,
I will check this with the software, could you share the options you use in the roc-bench tool?

I will try again the DMA … but in principle the DAQ start is a RESET to the CRU so all the FIFO should be cleaned and the SM go back to IDLE.

I will try and see if I can get a consistent behavior … how many links are you using?

Cheers

3

Hey,

the command was

roc-bench-dma --verbose   --id=05:00.0   --buffer-size=12Mi --superpage-size=1Mi --links=0-7  --no-errorche --bytes=12Mi  --to-file-bin=/tmp/rdo_0-7_027.bin --loopback=NONE --generator=0

So, there were 8 links being read out.

Cheers,
Torsten

4

Ciao,
so indeed there was a bug in the SM for the patternplayer and it was not detecting the run_enable signal in some situations.
It has been fixed and it will be pushed to develop soon.
Concerning the different file size it is a software “issue”, we are looking what the bench-dma is doing when it dumps the data on the disk … but the data should be correct anyway.

Cheers