Some VHDL simulation files not fully supported

[oscargus]

I created a VHDL file that used lots of different types and then simulated those using NVC and GHDL, dumping all available formats. It is clear that simulators dump things in the same format differently...

wavefiles.zip

The files ending with 2 contains a few more signals (arrays of records, strings, and signals with units), but otherwise are the same.

ghdl2.ghw crashes with

  not yet implemented: Support: TypeP32

All NVC-files triggers

TODO: handle Integer Natural better!
TODO: handle Integer Positive better!
TODO: handle String Character better!

Here one can note that NVC seems to store the character string escaped in VCD \'a\'. Maybe one can deal with that in the parser? One can also argue if it should be stored with ' around it or not. While in some sense correct, the actual information is the character. In VCD, NVC stores times (and variables with units) with \040 as space. Again, it would be nice if wellen could replace that with a space (there may be other situations where this happens as well).

Hence, one would need to handle escaped strings somehow, but one should also try to confirm how other simulators handle this to not break other cases.

(Interestingly GHDL stores strings as a union of enums in fst, so one gets an array with a separate signal for each character position padded with spaces. I may open an issue with GHDL to suggest that they are stored as strings, which would make things quite a bit easier on the viewer side. NVC worked out of the box.)

Edit: here are the escape patterns for strings btw https://github.com/gtkwave/libfst/blob/6a52070cd62ec65c29832bc95e7db493504aa7ac/src/fstapi.c#L6774

[ekiwi]

Thanks for looking into this, @oscargus!

Adding support for TypeP32 seems pretty straightforward, and I have an implementation of that on a branch already.

However, with the other issues, I am not sure what the “correct” output would be. Can you elaborate a little on what the current behavior is and what you would like to see? How does GTKWave deal with these data types right now?

[oscargus]

It turns out that GHDL and NVC stores several of the signals in different types...

For natural and positive, GHDL stores as integer, while NVC stores as natural/positive. As both natural and positive are defined as a subtype of integer:

subtype natural is integer range 0 to integer'high;
subtype positive is integer range 1 to integer'high;

so only a "range check" on the simulator side.

I think wellen deals with these as good as it can and one can just drop the comment. (I wasn't sure about this and thought that these might be u32 so there was a risk of wrapping, but that isn't the case.)

GTKWave renders the FST values in hex, while Surfer already now renders as integers (not sure why though...).

To this end, I think the main thing is to deal with escaped characters in VCD. fst2vcd (which NVC relies on) escapes some characters, see https://github.com/gtkwave/libfst/blob/6a52070cd62ec65c29832bc95e7db493504aa7ac/src/fstapi.c#L6774 (Not sure why they have chosen to escape ', but that seems to happen. Unfortunately, the history was lost when they moved to a separate repo for libfst, or, rather, I do not really have time to dig it up from the old repo...) GTKWave handles the character decoding (and strings in general).

We can of course handle this in Surfer, but it would maybe make sense if wellen does this?

One can also consider if character should actually drop the surrounding ', both in VCD and FST, but I guess one can argue for both cases. (Comparing to std_logic there is also '0', 'z' etc and there one wouldn't expect the ' to show. It's not like we put " around strings when they are displayed.)

I also created some string tests to see what happens in some cases. I realize the following:

GHW stores as an array of characters, but for some reason Surfer chooses to deal with the elements separately. For FST there is still an array resulting in a scope, but then it is string variable. One improvement would be to create a string out of an array of characters in the GHW case. A second to move the string scope to a string variable directly (but that, I guess, is a bigger change as we have not yet moved scopes to variables). GTKWave seems to do both.

For the VCD, there are now many cases, especially spaces since the string is 200 characters long, that are escaped and it is also clear that one would like to do the decoding. (I think it makes sense from a Surfer perspective to have the option to trim the strings in the translator to avoid lots of trailing spaces.)

No VCD from GHDL as it doesn't store the strings.

There are some instances of characters being turned in to double escaped characters, e.g., \302\260 for ° which I think is an UTF8-encoding (it should only have been \260 = 176. (I recall some discussion about UTF8 in NVC.) But maybe a start is to decode things per the standard and then one can possibly consider UTF8 (which isn't really part of VHDL if I understand it correctly, everything should be latin1).

strings.zip

(The testbench was vibe coded, so not all of the strings do actually add any value.)

Edit: if I store my file as ISO-8859-1 instead of UTF8 the \302 disappears. However, I guess many editors will store in UTF8 more or less automatically.

Here is another file with "all" ISO-8859-1 characters in the string. Some show up as squares in Surfer (and GTKWave), but I haven't looked more into it.

latin1.zip

[ekiwi]

Thanks for the detailed comments. Could you also share the source VHDL files with me? That would help me understand a bit better what is going on.

[oscargus]

Sure, here they are. Vibe-coded so some things are quite stupid...

vhdlfiles.zip

[oscargus]

I've played around with ways to get the >=128 characters to display correctly, but to no avail. So just wanted to say that if you figure out a way to get a proper UTF-8 encoded String from the files, that would be great! It seems like ö et al are messed up in Surfer when getting them from the fst-files and I do not think it depends on incorrect encoding of the VHDL...

[ekiwi]

Is the top-priority getting the string to display correctly?
If so, could you please make a separate issue with a simple test case and, ideally, some screenshots of how things are currently displayed in Surfer and GTKWave and how you would like to display them instead? I know this is a lot of work, but it would help me immensely if you could narrow the problem down in this way, as it makes the bug small enough to tackle when I have an hour or two of spare time.

[oscargus]

Maybe not top priority, no. Just annoying when I realized it...

Sure, I'll do that. But for now: everything(?) above 128 displays as a square (same in GTKWave btw). So my guess is that the ISO-8859-1 characters in the FST file is not converted to rust UTF-8-Strings correctly. But I'll try to debug a bit more and see what is actually in the strings etc and then open an issue.

Edit: Sorry, a bit too tired at the moment... I think it would be nice if all the \040 etc are removed (at least replace \040 with a space since that is probably the most likely one to show up), but the ISO-8859-1 leading to a square has clearly lower priority (and needs more investigation). Regarding the discussion in the next item, again, I guess spaces will be spaces, but the rest can wait.

Edit 2: This holds for VCD strings, so if one can add something like .replace("\\040", " ") in the VCD reader that should probably be the best guess. (I realize that I can naturally do this part, possibly even something more complicated.)

[oscargus]

FYI, there are also some discussions about how exactly NVC will encode its strings in nickg/nvc#1337 so it may even be better to wait with the string coding until a decision has been made there.