Wishlist for serializer testfiles

[dinyar]

Hi Joschka,

the following describes what the current parser in the testbench for the serializer stage (dinyar/uGMTfirmware#35) expects:

• The inputs in the format used by the testbench for sorting. Would it be possible to add empty bits as well, just to make the parser happy? (They can be any value, but the parser is expecting a fixed number of fields.)
  • I'm using the same keywords for the muons, so OUT for the final muons and xIMD for the three intermediate collections.
• The output would ideally be encoded by frame. i.e. one line per frame with each word being represented by a 33 bit value (or 32 bit if the valid bit should always be set to '1'). At the moment I am expecting the links for final and intermediate muons to be filled, but it wouldn't break the parser to add more words.

[dinyar]

Regarding the identifier for each word, I have now used FRM (optionally with the number after it, however my logic expects the frames in increasing order), but let me know if you have another one.

[jlingema]

When you say the output should be the 32 / 33 bit words per frame do you mean something like this (omitting the 2 leading frames with 0s):
FRM2 OUT0_0 OUT2_0 OUT4_0 OUT6_0 IMD0_0 ... IMD22_0
FRM3 OUT0_1 OUT2_1 OUT4_1 OUT6_1 IMD0_1 ... IMD22_1
FRM4 OUT1_0 OUT3_0 OUT4_0 OUT7_0 IMD1_0 ... IMD23_0
where OUTX_Y denotes the x'th muon and the y'th 32 bit word (+valid)? Or should OUT and xIMD be separate?

[dinyar]

No, exactly the way you wrote is perfect (so, not separate). :-)

On Tue, Nov 11, 2014, 09:34 Joschka Lingemann notifications@github.com
wrote:

When you say the output should be the 32 / 33 bit words per frame do you
mean something like this:
FRM0 OUT0_0 OUT2_0 OUT4_0 OUT6_0 IMD0_0 ... IMD22_0
FRM1 OUT0_1 OUT2_1 OUT4_1 OUT6_1 IMD0_1 ... IMD22_1
FRM2 OUT1_0 OUT3_0 OUT4_0 OUT7_0 IMD1_0 ... IMD23_0
where OUTX_Y denotes the x'th muon and the y'th 32 bit word (+valid)? Or
should OUT and xIMD be separate?

—
Reply to this email directly or view it on GitHub
#13 (comment).

[jlingema]

A first version was just pushed. The patterns are in the same dir as those for the algo test-bench but prefixed with serializer_. I.e.:
https://github.com/jlingema/uGMTScripts/blob/master/ugmt_patterns/data/patterns/testbench/serializer_single_muons.txt

One comment: The valid bit is separate as in V0 WORD0 V1 WORD1. If that leads to a problem, I can put it also in the WORD, but it makes it much less readable. Another thing: Is the test-bench also able to read hex-values or does it have to be dec? (Might also make it more readable.)

Let me know if that is OK.

[dinyar]

That sounds good! Let me know if you change the values to hex, then I'll
adapt the parser.

On Tue Nov 11 2014 at 10:53:42 AM Joschka Lingemann <
notifications@github.com> wrote:

A first version was just pushed. The patterns are in the same dir as those
for the algo test-bench but prefixed with serializer_. I.e.:

https://github.com/jlingema/uGMTScripts/blob/master/ugmt_patterns/data/patterns/testbench/serializer_single_muons.txt

One comment: The valid bit is separate as in V0 WORD0 V1 WORD1. If that
leads to a problem, I can put it also in the WORD, but it makes it much
less readable. Another thing: Is the test-bench also able to read
hex-values or does it have to be dec? (Might also make it more readable.)

Let me know if that is OK.

—
Reply to this email directly or view it on GitHub
#13 (comment).

[dinyar]

It turns out that I will only be able to read the outputs if they are provided as hex (or binary) strings. The expected format however is just a string of characters [0-9,A-F] without the leading 0x.

[jlingema]

Hi, has been fixed in the newest push. The field is filled with leading 0s to always have 8 digits. Let me know if that leads to any problems.

[dinyar]

Great! Works well, thanks!

On Tue Nov 11 2014 at 10:14:26 PM Joschka Lingemann <
notifications@github.com> wrote:

Hi, has been fixed in the newest push. The field is filled with leading 0s
to always have 8 digits. Let me know if that leads to any problems.

—
Reply to this email directly or view it on GitHub
#13 (comment).

[jlingema]

Alright then I'll close it.