ibex icon indicating copy to clipboard operation
ibex copied to clipboard

riscv_debug_wfi_test failed

Open cnan123 opened this issue 4 years ago • 3 comments

Hi, When I use the make TEST=riscv_debug_wfi_test SEED=27946 the case 27948 will failed due to timeout.

It's failed because the second instruction of main function is wfi instruction, but the task check_stimulus of the class core_ibex_debug_wfi_test is start later than wfi instruction execution( after wait_for_setup, it also wait another 50 cycles), so it will never wait for wfi instructions until timeout.

Does anyone know how to solve this issue? My current approach is to comment \\clk_vif.wait_clks(50); at line 456 of core_ibex_test_lib.sv, and can pass, but not sure if it will affect other cases.

Tool: vcs o-2018.09-SP2-9 Config: small

cnan123 avatar Dec 24 '21 12:12 cnan123

Hi @cnan123 and thanks for the helpful bug report. This definitely looks wrong to me! :-)

@gregac: Is this something you've got time to have a look at?

rswarbrick avatar Jan 04 '22 09:01 rswarbrick

Thanks for the report @cnan123, we've got a few of these kinds of issues where in some cases we sit waiting for something to happen that's already happened so wait forever. It's all down to the checking strategy the testbench is employing (wanting to check specific things have happened).

Your fix may do the job but I remember there being some other issues that can crop up without the initial 50 cycle wait.

The good new is this will all be dealt with through our co-simulation work (see https://ibex-core.readthedocs.io/en/latest/03_reference/cosim.html), the specific checking strategy used will be removed as the co-simulation does more general checking by cross checking with Spike.

This work is on-going, I can't give a timescale for it's completion but it's currently a priority for us so it should be sooner rather than later.

GregAC avatar Jan 04 '22 17:01 GregAC

Timeout behaviour with the test sequences has changed quite a lot since this issue was raised. Change to using cosim should also cover this, so wondering if the bug report from the original poster is something that we are likely to see again and/or should have a test for? Otherwise if resolved we can close out the issue.

johngt avatar Jul 20 '22 13:07 johngt