OSDB: requirements

[ecstrema]

Some requirements have been stated before at different places. I tried to gather them here. Please add any I've forgotten.

Also, to discuss a specific requirement, please open a discussion concerning it instead of adding here.

• Relatively good compression (comparable with fst)
• High compression speed (needs realtime encoding)
• Streaming support. A file should be able to be open in a simulator while being appended too. This is currently the case for fst AFAIK.
• Fast random time access. FST stores data in chunks of time intervals, which allows jumping relatively fast to any specific timestamp. However, it uses large blocks to aid for compression, so this is only useful for large simulations.
• Fast random signal access. As opposed to other formats, such as video/image/audio where all pixels/samples are used, the consumer of a waveform only chooses to view a small portion of the file.
• Rich metadata section. This should contain at least enum value to name mappings and available signal types. Maybe signal location (file:line) and relationship.
• Rollover support
• Blackout regions
• Ability to store delta cycles, and order value changes within an instant.
• Support for transactions.
• Rich types - enums. structs and arrays

A table comparing the support of these in existing formats (both open and proprietary) would be very useful

[gezalore]

I would like to propose the following in addition:

• Enable fast, time ordered diffing of waveforms:
  A diff tool like veripool/vcddiff is tremendously useful for debugging race conditions (e.g., when you get a test failure after upgrading your simulator, or bringing up your design on a different simulator), and other simulator issues (e.g.: bad optimization that only shows in large designs). For this to be really useful, the diff tool must report the differences in simulation time order (you want to see the earliest mismatch - the cause - not the later dependent mismatches), and the format should enable implementing such a diff tool in a performant way.
• Low writer performance variance:
  This is important for good performance with parallel dumping in Verilator. If you have huge latency spikes on some threads, it will waste CPU cycles on the other thread that would then be idle. Some variance is probably unavoidable due to block compression, so alternatively, a mechanism to coordinate these longer phases across multiple writers is required (this is what Produce split FST files when using multiple threads verilator/verilator#5806 does).

You seem to be calling it "rollout", but Verilator uses the term "rollover" for the feature that limits file size. I assume this is just a typo?

[ecstrema]

You seem to be calling it "rollout", but Verilator uses the term "rollover" for the feature that limits file size. I assume this is just a typo?

Yes, sorry, corrected.