Waveforms not generated correctly (GHDL)

[Ariel]

Hi,
I’ve just started learning about OSVVM and I want to see the wave forms after the simulation to help me debug. I am currently using GHDL.
I have a custom DUT, which I can see its simulation in Vivado (2024.1) with a testbench that doesn’t include any OSVVM-related code. The DUT involves a master and slave axi stream, so I duplicated the folder structure as in OsvvmLibraries/AXI4/AxiStream.
The build.pro script in TestCases contains:
`
SetSaveWaves true
RunTest TbStream_SendTthreeInputs.vhd
`
I can see it creates a .ghw file in mysimdir/reports/DefaultLib (haven’t figured out how to change DefaultLib so far) and when I open it with gtkwave, it gives the following error:

`
gtkwave TbStream_SendTthreeInputs.ghw

GTKWave Analyzer v3.3.104 (w)1999-2020 BSI

ghw_read_type: unknown type 37
ghw_read_base: error in section TYP
Error in ghw file ‘TbStream_SendTthreeInputs.ghw’.
`

To be on the save side, I went to the examples and modified OsvvmLibraries/AXI4/AxiStream/TestCases/build.pro to save the waves only for the SendGetDemo test

`
SetSaveWaves true
RunTest TbStream_SendGetDemo1.vhd ; # Demo of Send, Get, and Check of words and bursts
SetSaveWaves false
`
When I tried to open the generated .ghw, I got the same error.

I tested gtkwave with other past projects and I am able to see their waveforms.

Is the error even related to osvvm? to my script, DUT, VC?
If I would like to run the simulation in Vivado, would it be possible to use launch the GUI and use breakpoints for example?

Thanks for the help.

[Patrick]

Your GTKwave is propably too old. You have 3.3.104, whereas GTKwave is now at 3.3.121.

What platform do you use?
Linux, macOS, Windows, MSYS2, …?

As an alternative: https://surfer-project.org/
Unfortunately, the made there own GHW reader as far as I know. So it could be failing as well.

GHW is a waveform format from GHDL specially made for waveforms with VHDL datatypes. All other formats are variants of VCD (value change dump – part of the Verilog standard). These also have the limitations of Verilog data types.

You might experience these problems with OSVVM, because OSVVM makes use of almost all VHDL-2008 features in combination with lots of user defined types etc. So consider OSVVM as a VHDL-2008 user pushing the language (and the tools) to the edge :). OTOH, you get a powerful and brillant framework.

[Ariel]

Of course! I assumed gtkwave would update when updating to the latest ghdl version. It wasn’t the case. Now with gtkwave 3.3.221 it opens as expected.

What about running the simulation in vivado? I’m mostly interested in post synthesis functional simulation as I have a vhdl module currently that works fine in behavioral simulation and works differently in post synthesis.
According to the scripting user guide the internal tests don’t pass, but Jim posted about version 2025.2 (to be released). Would it then be possible to run post synthesis simulation? If so, is it possible to use breakpoint?

Thanks for the help.

[Patrick]

I don’t advertise simulations with Vivado xSim
* very low speed (>10x) compare to commercial simulators or open-source simulators
* creates masses of output data (multiple GB where others write just a few MB)
* explicit VHDL features like range checks need to be activated by the user (if not, xSim doesn’t produce correct simulation results according to IEEE Std. 1076)
* limited VHDL-2008 support

Do you really need to mistrust your synthesis tool? What are you using?
If there is no real concern and proof of mistrust, don’t spend hundreds of ours in post synthesis simulations. It’s awful slow.

I didn’t get the point why you need breakpoints for post synthesis simulation. Breakpoints are for debugging and step-by-step investigations of designs.

[Ariel]

I am using Vivado, with behavioral simulation for debugging and step-by-step investigation. Then, I can run all the tests with GHDL, because as you said, Vivado is very slow.

I am getting the same results in behavioral simulation in vivado and also in GHDL. As I want to be sure that post-synthesis works without generating a bitstream (which takes obviously longer) and test it on a board, I ran the post-synthesis simulation and I get different simulation results as behavioral.

So, how much could I trust that the simulation (in Vivado or GHDL) will match when implemented on an FPGA? Could it be then, as you said, the issue with xSim then that produces a “bad” post-synthesis simulation?

[Patrick]

Usually, you can trust the synthesis tools. If you really mistrust them, you should skip post-synthesis and post-placement simulation and go to post-routing simulation. Post-synthesis is just after synthesis without optimization, placement and routing. So you would miss critical parts in the transformation from VHDL to bitstream.

Please keep in mind, you need to drive your data differently in post-*** simulations, as almost all wires have delays on them. A simple behavioral simulation without delays can’t be easily used to drive and check a post-*** simulation. OSVVM verification IPs have lots of tpd parameters, so you can set propagation delays for every signal in relation to clock.

I never needed a post-*** simulation in designs. The tool bugs I had so far (the list is not short …) wouldn’t be discoverable with this kind of simulation.

Also, timing simulations (post-*** simulations are timing simulations) don’t discover timing problems. They check your design for a subset of value transitions, but you can’t find (compute) all input combinations (sequence of inputs) to trigger the internal worst case, which will potentially surface the critical path.

[Ariel]

Hi Patrick,

Thank you for the clear answer. Makes total sense to skip the post-synthesis simulation then for my purpose. I am in fact using the OSVVM AXI Stream components which have tpd. I have a design with mainly several axi streams, so I am following the testcase OsvvmLibraries/AXI4/AxiStream/TestCases/TbStream_SendGetDemo1.vhd.

I need to play around with tready (for a receiver), when to assert it (before or after tvalid). I played with RECEIVE_READY_DELAY_CYCLES and RECEIVE_READY_BEFORE_VALID but I noticed tready is asserted at the beginning of the simulation no matter what. I found this post . Can that behavior be changed?

Thanks for the help.

[Patrick]

Do you need this as strict “on” and “off” for tready or do you need e.g. random back-pressure on the bus?

I think for the latter we need @JimL answer. For the former, you can setup a coverage model, which acts as a distribution function. This CovModel can be handed over to the receiver to randomly accept data or delay reception.

[Ariel]

Actually both, to have a robust test.

For the former, just to be clear, , I have an AxiStreamReceiver and I am testing my DUT which has an axis master. So, I want to assert in the TestCase tready before tvalid or after tvalid (1, 2, n clock cycles). Is that what you meant? Is there any example to follow?

[Author]

Posts