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.
The header size is specified with 4 bytes while in reality it is 64 bytes.
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.
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.
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.
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.
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.
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).