Fix bug in parsing the values section of PSFBIN files

[jonnykl]

The binary PSF parser is unable to parse another file generated from a transient simulation with Spectre 23.1.0.802.isr17. The value_section_type is 768 which is not defined in the corresponding enum. The type of the values section should be SIMPLE but the section also contains GROUP_DECLARATION chunks which are currently not handled.

Where did you find the information about the value_section_type field in the PSFBIN file? Is there any further information for the value 768? I couldn't find anything the C++ libpsf library (which is the reference for this lib?). However, it checks whether there is the sweeps section and whether a specific key in the header is present to decide how the values section has to be parsed. I adapted it from the libpsf library. This change doesn't break any of the tests in this lib.

This change alone is not sufficient to parse my file because it contains GROUP_DECLARATION chunks in the values section. It looks like the structure of the following data is the same as for the DECLARATION chunks. Therefore I think the data should be added to all declarations within the group. I'm unsure whether group declaration can be nested or not. My implementation assumes they are not nested.

I tried loading the file with the libpsf library. I doesn't throw an error during loading/parsing, but it's not possible the access all signals, i.e. psf.get_signal(psf.get_signal_names()[1]) fails (there are way more than 2 signals). I didn't trace the error back to its origin, but it might be related.

Unfortunately, I can't share the simulation output file. However, I will try to reproduce it independent of my work so I can add it to the tests.

Btw, great work, thanks for publishing your lib!

[jonnykl]

I figured out that Spectre creates such simulation output files with +preset=lx (I was using mx before). The full command I'm currently using is spectre -64 +log spectre/spectre.log -raw spectre +preset=lx -format psfbin input.scs. The inputs/etc. are the same as described in #1 (comment). I've generated a small file with 10 signals and just added it to the tests.