Inconsistency in RDH and unexpected fill-words

Hello,

i checked the raw data from the TPC readout and decoded the header. There i see some inconsistencies.

0000000 : 0x01f00403 <- Start Header. Block-Length : 0x1F0 = 496. Header size = 0x4
0000001 : 0x000012ec
0000002 : 0x20000000
0000003 : 0x00000000
0000004 : 0x00000000
0000005 : 0x00000000
0000006 : 0x00112244
0000007 : 0x00112200
0000008 : 0x00000000
0000009 : 0x00000003
0000010 : 0x00112255
0000011 : 0x00112233
0000012 : 0x00000000
0000013 : 0x00000000
0000014 : 0x00112266
0000015 : 0x00112233 <- End Header : Size = 16 x 4 byte = 64 byte 
0000016 : 0xa72228e3 <- Start Payload
0000017 : 0x2aaf0f02
. . .
0001980 : 0xa9e020f0
0001981 : 0xa0278e88
0001982 : 0x79e08a72
0001983 : 0x0000e080 <- End Payload (???) : Size = 1968 x 4 byte = 7872
0001984 : 0xeeeeeeee <- Start Fillwords (???)
0001985 : 0xeeeeeeee
. . .
0002046 : 0xeeeeeeee
0002047 : 0xeeeeeeee <- End Fillwords (???) : Size = 64 x 4 byte = 256 byte
0002048 : 0x01f00403 <- Start Header next packet
0002049 : 0x000012ec
0002050 : 0x20000000
  • Header = 64 byte
  • Payload = 7872 byte
  • Fillword = 256 byte
  1. The block length information in the header is 0x1F0 = 496. The actual payload is 7872 byte. Even if i add the fillwords (why are they there?) i end up with 8128 bytes. Interpreting the 496 as the number of GBT words (128b or 16 bytes) and not as bytes gives 7936 bytes. No match there either.

  2. The header size is specified with 4 bytes while in reality it is 64 bytes.

  3. Why are there fillwords? They are not supposed to be there. Apart from the RDH, the rest of the payload is supposed to be GBT frames.

Cheers,
Torsten

Hello,

Indeed the RDH contain bad information:

  • header size was expressed in 128 bit words instead of bytes (0X4 instead of 0x40)
  • block_length and memory size were wrong also

We are about to release a new firmware (v2.3.0) that will correct these (matter of days). Also the padding (what you name fill word) will not exist any more as it is useless and eat bandwidth.

Cheers

Ciao,
Following my comments on the RDH fields:

  1. HEADER SIZE is a fixed value of 64 bytes (4 words of 128 bit) … this is done so the software can easily go through the header.
  2. The block length information it is something optional. The FEE can decide to fill it or not. The block length field in the rdh should be filled by the FEE to specify the size of the payload. The software should anyway check the memory size field, that is filled by CRU computing the actual amount of data pushed into the memory of the FLP. This is done because the FEE doesn’t know how the data is transformed inside the CRU, so the 80 bit sent by the FEE becomes 128 bit … and the software must know about the actual data moved into the memory.

As specified by Olivier, the memory size is still not properly filled, but this will be the case in the next tag.

Hi CRU team,

we took data with the latest firmware and while the header now seems to show the correct information, the fill words are still there. In fact, the number of fill words increased slightly and the fill pattern changed. Before there where 256 bytes of fill-words (Pattern 0xE), now there are 288 bytes of fill words (Pattern 0x0). Header shows a payload size of 0x1EA0 ( 7840 bytes). This is consistent with the number of fill words we see: 8192 - 64 (Header) - 7840 (payload) = 288.

Cheers,
Torsten

Ciao,
yes the “padding” value is programmable. The important is the value are correct.
If you change the number in the tpc script it should change as well.

vi tpc-readout-test.py

for l in links:
        cru.dwrapper.linkEnableBit(l)
        cru.dwrapper.setGbtDatapathLink(wrap=0,link=l,is_GBT_pkt=0,RAWBYLEN=1,RAWBYID=0,RAWMAXLEN=0x1EA)

change 0x1EA in 0x200 … you should have 8KB packet without hole (0x0).

Let me know
Cheers

Hi Pippo,

cool, will check it out! Then i can also test the automatic payload check in my decoder.

Cheers,
Torsten