[RFC][WIP] Fix failing ghdl test

[garzetti]

While trying to fix the ghdl issues with dec_viterbi, another error popped up, this time apparently with VPI. Somehow, here cocotb fails to get the element 0. Tracking down the issue, it seems that the problem comes from here, as the returned new_handle is 0.

Unfortunately, I'm not yet able to track it down by myself, any suggestion? This seems to be quite important, as it is currently impossible to reference any instance generated with the "for ... generate" construct.

Thanks.

[garzetti]

Now Travis with GHDL starts but still fails some test units. Please check the log and let me know.

[imphil]

Please check the log and let me know.

Can't you access https://travis-ci.org/potentialventures/cocotb/jobs/545147125?

Essentially, it's

/home/travis/build/potentialventures/cocotb/tests/test_cases/test_iteration_vhdl/../../../tests/designs/viterbi_decoder_axi4s/src/generic_sp_ram.vhd:16:10:error: unit "std_logic_unsigned" not found in library "ieee"
/home/travis/build/potentialventures/cocotb/tests/test_cases/test_iteration_vhdl/../../../tests/designs/viterbi_decoder_axi4s/src/generic_sp_ram.vhd:16:10:error: (use --ieee=synopsys for non-standard synopsys packages)
/home/travis/build/potentialventures/cocotb/tests/test_cases/test_iteration_vhdl/../../../tests/designs/viterbi_decoder_axi4s/src/generic_sp_ram.vhd:42:14:error: entity 'generic_sp_ram' was not analysed

[cmarqu]

So adding --ieee=synopsys to the Makefile may make it work.

[garzetti]

Can't you access https://travis-ci.org/potentialventures/cocotb/jobs/545147125?

With this commit the test starts, but fails with IndexError: gen_branch_distance contains no object at index 0, have a look at this.

So adding --ieee=synopsys to the Makefile may make it work.

Already done. Anyways, this was only the first step; thanks to b36337b the design it is now consistent and can be elaborated and run by GHDL.
However, it seems that the VPI interface fails in passing some objects (e.g. array object, constant object). Now it is difficult for me to investigate further, maybe someone with more experience in VPI interface can have a look.

In short now the test fails when it tries to access any element in HierarchyArrayObject or ModifiableArrayObject, so the test fails here

[themperek]

Any idea this is an issue of cocotb or ghdl?

[garzetti]

For me it is related to GHDL because with Questa Modelsim all the tests pass without error. Moreover, i have checked the dut._sub_handle_key after a manual _discover_all() and the fetched elements are more consistent using Questa respect to GHDL

[imphil]

Without looking deeper into this, this could be both a cocotb bug or a GHDL bug. GHDL is special in that it uses VPI, while any other VHDL simulator uses VHPI. I wouldn't therefore rule out bugs in this area as well. However, VPI support is pretty stable in cocotb and very well tested, so a GHDL bug seems more likely.

How to debug further:

• Run cocotb with full debugging information (set COCOTB_LOG_LEVEL=debug in your environment) to get all VPI calls
• If you see VPI calls failing report a bug to GHDL. It's hard to double-check the GHDL behavior against any other simulator, as all other simulators use VHPI for VHDL.
• Feel free to CC me on GHDL bugs and I can try to help out if needed.

(Looks like there are other GHDL bugs open on VPI, e.g. this one ghdl/ghdl#762. Maybe you can look through their bug reports as well?)

[eric-wieser]

Needs close / reopening to rerun travis

[garzetti]

As you can see from travis this little PR only uncovers more errors. Unfortunately i can not go deeper in ghdl and cocotb by myself at the moment. Please let me know if you find something else

[themperek]

I think this went in with #1052 @garzetti

Can I close this? The rest seems to be on ghdl side.

[garzetti]

Yes, you can close.

[themperek]

@garzetti You ware first but I have missed this due to [WIP] sorry and thank you!