-
Notifications
You must be signed in to change notification settings - Fork 488
[EMCAL-675] Handling of pages without trailer #5101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Errors unrelated @shahor02 could this be merged? |
|
@mfasDa just to be sure: what is the size of the trailer? If it is > than 16B, the default splitting algo. may split the trailer. Do you handle this case? |
|
@shahor02 The trailer consists of 9 32 bit words, so the total trailer size is 36 Byte. I think we don't handle that the trailer might be split into two pages, I was not aware of this. The firmware always put the trailer at the end of a page, so the decoder expects the trailer at the end of a page. But this case becomes obsolete as we will remove the trailers in intermediate pages and only add the trailer on the last page. Also in this case the traIler must not be split. |
|
So, potentially, it can be split. Is it ok? |
|
I need to check this with Martin but according to my understanding the firmware never splits the trailer - it expects it at the end of a page. |
|
But then, it is better to implement the carry-over which makes sure it is never split, i.e. split the payload little bit before the trailer. |
In the new version of the raw format the trailer will be only on the last page. In order to be compatible with both version the last trailer word is checked for bit 30 (trailer marker), in case it found the trailer is decoded and chopped from the page as it is re-encoded when the multi-page payload is combined. Otherwise the full payload is added to the multi-page buffer. This works for single and multi-page payload and therefore consequently for the old and new raw format.
|
Trailer marker fixed in the last iteration (both bits 30 and 31 need to be checked - 31 alone is intermediate trailer marker, 30 alone is channel header marker). |
@shahor02 How could I do this in the carry-over method? This would mean chopping the stream and filling the words on the page which would be used or the trailer with 0. How does the RawFileReader know in this case where to start the next page from? Furthermore I would need to determine that the last words on the page are intermediate trailer words (there are special markers for this, but how do I know what are the last words on the page?). And in addition the payload size on the last page in the trailer would need to be adapted for 0-words I added. |
|
@shahor02 This commit is independent from the simulation - the raw parsing can handle both versions of the raw format, because it use trailer and channel markers in order to determine consecutive payload, which are set both by the hardware and in the simulation. Can you please merge it when the CI passes? We need this to be part of the next FLP suite so that it becomes available on the FLPs for our vertical slice test. |
RawFileReader looks only into the RDH, which is adapted according to what |
In the new version of the raw format the trailer will be only
on the last page. In order to be compatible with both version
the last trailer word is checked for bit 30 (trailer marker), in
case it found the trailer is decoded and chopped from the page
as it is re-encoded when the multi-page payload is combined.
Otherwise the full payload is added to the multi-page buffer. This
works for single and multi-page payload and therefore
consequently for the old and new raw format.