[ci/processor] test all GHDL backends, test VUnit master too

[umarcor]

This PR is NOT to be merged. It's for illustrating an issue.

As commented in #116, when changing the container image used for running VUnit, it would fail. In this PR, the VUnit test is executed six times:

• GHDL mcode with VUnit stable
• GHDL LLVM with VUnit stable
• GHDL GCC with VUnit stable
• GHDL mcode with VUnit master
• GHDL LLVM with VUnit master
• GHDL GCC with VUnit master

All three jobs using VUnit stable do work, but the ones using VUnit master fail.

The problem seems to be in the NEORV32 codebase, so it's surprising to me why changing the version of VUnit triggers it. @LarsAsplund, any guess?

[stnolting]

Regarding this error (https://github.com/stnolting/neorv32/pull/126/checks?check_run_id=3056287922#step:7:973):

=== Command output: ===
/src/rtl/templates/processor/neorv32_ProcessorTop_stdlogic.vhd:354:23: can't associate 'slink_tx_dat_o_int' with signal interface "slink_tx_dat_o"
    slink_tx_dat_o => slink_tx_dat_o_int, -- output data

There is a typo in neorv32_ProcessorTop_stdlogic.vhd

neorv32/rtl/templates/processor/neorv32_ProcessorTop_stdlogic.vhd

Lines 215 to 218 in e6da52c

	signal slink_tx_dat_o_int : sdata_8x32r_t;
	signal slink_tx_val_o_int : std_logic_vector(7 downto 0);
	signal slink_tx_rdy_i_int : std_logic_vector(7 downto 0);
	signal slink_rx_dat_i_int : sdata_8x32r_t;

slink_tx_dat_o_in and slink_rx_dat_i_int should be of type sdata_8x32_t (UN-resolved, 8x std_ulogic_vector) and not of type sdata_8x32r_t (Resolved, 8x std_logic_vector).

[umarcor]

@stnolting that is correct. Thanks for fixing it! It allowed to clean #116!

However, it does still not explain why one version of VUnit ignores that bug but a newer version fails. It's the same NEORV32 codebase in both cases, same testbench. Therefore, since the bug existed, CI should have failed as soon as you pushed that. However, it slipped into the repo because the current stable VUnit and latest GHDL do not complain about it.

[stnolting]

Is this really a problem of VUnit or might it be a problem of/with GHDL?

I am currently using an older version (I think) of GHDL using no VUnit at all on my Windows WSL system and that version also ignored the bug.

GHDL 0.37 (Ubuntu 0.37+dfsg-1ubuntu1) [Dunoon edition]
 Compiled with GNAT Version: 9.3.0
 mcode code generator

[umarcor]

I'm pretty sure it's because of some change in VUnit's VCs, which get connected to the NEORV32 signals. During elaboration, the error is reported in the NEORV32 source, but it is motivated by where is that connected to outside. My perception is that VUnit might have some explicit casting in the stable version which was removed in master. That casting might have hidden the bug.

You can try the following:

git clone https://github.com/VUnit/vunit
PYTHONPATH=$(pwd)/vunit
./sim/run.py
# That should fail

cd vunit
git checkout -b stable v4.5.0
cd ..
rm -rf vunit_out
./sim/run.py
# That should pass

[umarcor]

This seems to be fixed with the updates to NEORV32 during the last 1-2 months. I'm closing it, since there is fortunately no point in spending time into this one.