Complications with the VFAT Payload Format

[rodwyer100]

Here is a run through of the 8 VFAT settings w/ regard to Zero Suppression

Basic Facts

1. You have 3 choices you can make: Sequential Zero Suppresion (DT), Data Package Suppression (SZP), and Data Suppresion (SZD)

These have been listed by their order in the 3 bit registry

2.If we have a package with absolutely no hit on any channel, then SZP and SZD activate

a.SZP will not send any information except a Header (no EC,BC, or CRC, nothing)

b.SZD will send the entire package except the data.

3.The hardest to implement will be DT (sequential zero suppresion)

c. This actively perpetrates the channels into 16 sections of 8 channels. This has been described in the last issue.

Current Software

1. The current implementation handles no suppression and sequential via a switch statement, where we can set whether or not we have sequential suppression with a single number in the src file (not Event.cpp).

2.In a short period, I will implement the other two choices into the code.

3. At the moment their is no part of the code which verifies which mode is being used (its manually set), and I imagine the structure of the AMC13 payload may need to be changed in order to give me this information.

4. That said at the beginning of each VFAT payload their is a 3 bit unused space, perfect for the required 3 bit number telling us which mode is being used.

Details about Sequential Suppression Mode

1. The first line up to BC (bunch cross count) is identical; the last 16 bits of this line is a control sequence.

2.The control sequence will detail which packet of 8 channels is nonzero (i.e. 1001 means first and last nonzero)

3. Afterwards a variable number of packets follow, each 8 bits, and then the 16 bit CRC as before.

Things to Tackle

1. Changing the last 16 digits of line 1 from data to control sequence is easy, but that control sequence is really imperative to keeping track of channels

2. I have implemented an array uint8_t packets[16] to hold the various packets upcoming, may not be the best way.

3. In order to correctly read off the CRC after all the packets, I needed to count the number of 1's in the control sequence. Method I used may not be optimal.

4. The variable position of the CRC means that there may be required a lot of empty space at the end of a particular line in order to keep the VFAT payload one block of 64 bit lines.

Context (for feature requests)

1. At the moment changes are just being made to the VFAT read_fw,sw,tw methods in GEMAMC13EventFormat.h, but changes will also need to be made to their instances in the unpacker c++ file (now read_fw accepts two arguments, one to switch modes).

2. I am just starting this project; at the moment the changes look like they made only need to be applied locally, but that may change as I look into the surroundings of the unpacker file.

Images of the VFAT payload for every one of this Nodes has been included in the data google-sheet under V300

[bdorney]

@rodwyer100 I think the same issue is here with respect to what @jsturdy requested. The image is not really visible; can you make a new tab on the gem event format sheet with these images so we can inspect the proposed changes. The image is too low resolution.

[jsturdy]

I do not understand why there are two issues on this topic... The description of all possibilities, and the decision on implementation should all be discussed in a single issue (with inputs from @evka85 especially vis-a-vis usage of bits)

[rodwyer100]

I have made the changes to the excel sheet you asked in the first issue. I will resolve the old issue and add the necessary information to this current one tomorrow morning. The changes have been made to V300, but they are easily movable if that is not the desired location

[bdorney]

I have made the changes to the excel sheet you asked in the first issue. I will resolve the old issue and add the necessary information to this current one tomorrow morning. The changes have been made to V300, but they are easily movable if that is not the desired location

Could you revert all changes to the V300 sheet. Right now this is the "standard" and accepted format that the DPG team is using for SW development.

Please make your changes in a separate sheet tagged with "proposal." In this way the current format is preserved.

[jsturdy]

@rodwyer100, I would suggest to strip out everything except for VFAT payload from this proposal tab (at least for now).

• Define clearly what registers must be set, and what values they must be set to in order for the data packet to be represented (this is table 22 in the VFAT3 manual V2.2)
• Each mode needs to be given a very specific identifier, that is then used elsewhere in the data format to determine the event builder and unpacker behaviour (though this is probably the domain of @evka85)
  • If we decide not to support certain modes, this should be clearly stated, and the configuration should be prevented from being set in this way
• Differentiate, for each of the ZS modes, what the relevant markers are. In each mode the packet can either be zero-suppressed, partially zero-suppressed, or non zero-suppressed
  • There is currently a table with these, but since you are outlining all the modes individually, you should just fill these in
  • These headers aren't very logical, so it is not as simple as having a set of bits that tell you all the information that can then be programatically derived...
  • There does appear to be a WARNING bit (bit 6)
  • There appears to be a not ZS bit, but it is bit 2 in the standard header, and bit 3 in the WARNING header...
  • Perhaps @evka85 will parse all this in the event builder and be able to put this all into a sensible place within the GEM data format, but I would hesitate to do this right away, as it would necessarily require dropping the raw data of this header in favour of rearranging it "sensibly", and this carries a risk
• Define what each set of bits represent, e.g., Control sequence
• Get inputs from @evka85 regarding the "unused" bits (I'm fairly confident that we won't have 40 or 48 unused bits per VFAT... because this will defeat the purpose of zero suppressing)

[rodwyer100]

Just a little update. I have yet to strip things from the proposal tab atm because I am more or less using it as a helpful guide for implementing the software. With @evka85's input, the VFAT software has been redesigned to be compatible with the wrapping we settled on, and it also now includes a mode for calibration. The only thing is that there is some considerable empty space in the chamber header, which @evka85 may decide to wrap as well, which will be a relatively quick fix. If you want to read over the software to see how it works, it is on my fork on the branch ending with "wrap".

I will certainly address concerns with regards to the excel file when the final means of packaging chamber and vfat loads in singled upon (at this point we are close, but I am also coming up with optimal idea on how to present the structure of the packet visually when it no longer fits nicely in big 64 bit blocks).