Acceptance test failure for GHDL 3.0.0 under WSL2
halfow opened this issue ยท 0 comments
Hello!
Could not find this as a known issue. So lets post one ๐
Environment
Operating system used: Ubuntu 22.04 (WSL2)
Tool | Version | Note |
---|---|---|
vunit | 4.7.0 | This was also present on master b7fcc7f |
ghdl | 3.0.0 | Build from sources and to have 2008 support enabled. |
GNAT | 10.4.0 | ghdl compiled with this version |
Python | 3.10.6 | (main, May 29 2023, 11:10:38) [GCC 11.3.0] |
Issue
tb_com_lib.tb_com_codec.Test that custom record type can be encoded and decoded
fails when running tox -e py310-acceptance-ghdl
For TLDR; see Initial Conclusion at the end
Gathering some data
Running the test stand alone the fault could be reproduced. python vunit/vhdl/com/run.py
gives the same single failure (as expected).
python vunit/vhdl/com/run.py "*Test that custom record type can be encoded and decoded" -v
Starting tb_com_lib.tb_com_codec.Test that custom record type can be encoded and decoded
Output file: /<PLACEHOLDER>/vunit/vunit_out/test_output/tb_com_lib.tb_com_codec_<HASH>/output.txt
0 fs - check - ERROR - Relation check failed
/<PLACEHOLDER>/vunit/vunit/vhdl/core/src/core_pkg.vhd:84:7:@0ms:(report failure): Stop simulation on log level error
/usr/local/bin/ghdl:error: report failed
in process .tb_com_codec(test_fixture).test_runner
from: vunit_lib.core_pkg.core_failure
from: vunit_lib.logger_pkg.decrease_stop_count
from: vunit_lib.logger_pkg.decrease_stop_count
from: vunit_lib.logger_pkg.log
from: vunit_lib.checker_pkg.log_failing_check
from: vunit_lib.checker_pkg.failing_check
from: vunit_lib.check_pkg.check_relation
from: vunit_lib.check_pkg.check_relation
from: process tb_com_lib.tb_com_codec(test_fixture).test_runner
/usr/local/bin/ghdl:error: simulation failed
fail (P=0 S=0 F=1 T=1) tb_com_lib.tb_com_codec.Test that custom record type can be encoded and decoded (0.7 seconds)
To have some more data I tried running with the failing check commented out.
elsif run("Test that custom record type can be encoded and decoded") then
rec1 := decode(encode_record1_t((character'pos(lp), -1, -2, -3)));
-- check_relation(rec1 = (character'pos(lp), -1, -2, -3)); -- <--- THIS IS THE CHECK THAT FAILS
rec2 := decode(encode_record2_t((command, 1, -1, -2, -3, '1')));
...
check_relation(rec3 = (char => rp));
In this case all the following checks passed.
This got me curious. character'pos(lp)
might be the villan. As the field of record1_t
should be Natural
I tried again with out the attribute pos lookup. 40
is used as its seemed to be the intended lp
value
elsif run("Test that custom record type can be encoded and decoded") then
rec1 := decode(encode_record1_t(40, -1, -2, -3)));
check_relation(rec1 = (40, -1, -2, -3)); -- <--- THIS IS THE CHECK THAT FAILS
...
This worked! I might be on to something!
elsif run("Test that custom record type can be encoded and decoded") then
rec1 := decode(encode_record1_t((natural(character'pos(lp)), -1, -2, -3)));
check_relation(rec1 = (natural(character'pos(lp)), -1, -2, -3));
...
Wait, this also worked!
Hmm... the attribute might return a incompatible type before its cast.
Here I feel that my knowledge starts to break down and there is enough data for a lazy resolution.
Would happily follow along with any deeper analysis of the issue ๐
Deeper down the rabbit hole...
As my GHDL knowledge is to limited and I don't know of a way to print the type of a variable to the console in VHDL. I was left with a guessing game. I will not go down this rabbit hole further then trying integer
. With the reasoning that having integer as the common attribute return type would make some sense.
type record1_t is record
a : integer;
b, c, d : integer;
end record record1_t;
elsif run("Test that custom record type can be encoded and decoded") then
rec1 := decode(encode_record1_t((character'pos(lp), -1, -2, -3)));
check_relation(rec1 = (character'pos(lp), -1, -2, -3));
...
Unfortunately this guess was incorrect and the explicit casting was necessary in this case as well.
Initial Conclusion
This might be a GHDL issue/quirk. But I got to little knowledge about VUnit and GHDL to say ither.
rec1 := decode(encode_record1_t((character'pos(lp), -1, -2, -3)));
did not fail on its own. But might be due to compiler optimization. I would not swear by excluding this from the investigation- An initial quick fix can be
elsif run("Test that custom record type can be encoded and decoded") then rec1 := decode(encode_record1_t((natural(character'pos(lp)), -1, -2, -3))); check_relation(rec1 = (natural(character'pos(lp)), -1, -2, -3)); ...
- Data from other OS/python/GHDL versions would be interesting to narrow the root cause. But this is at least a starting point.