You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When synthesizing the RV32E example with the unit/led program on my TinyFPGA BX, the LED stays off.
On the other hand, Cuttlesim and Verilator both behave as I expect them to following the definition of the test.
I tried the following things independently from each other:
replacing
if (led_wr_valid)
led <= led_wr_data;
with
if (!led_wr_valid)
led <=!led_wr_data;
in top_uart.v results in the LED turning (and staying) on (FPGA only, simulation not impacted although making the same change to top.v indeed inverts Verilator's behavior);
replacing both may_run and on by Ob~1 in the extcall to ext_led in RVCore.v results in the LED turning (and staying) on, as should be expected (FPGA and simulation);
replacing the contents of led.c with a simpler infinite loop containing only a call to putled(1) does not fix anything - the LED is still off, and simulation spams the output with the "☀" symbol.
Do you observe the same thing on your side? I don't have access to an ULX3S-85k as of now, does this test behave any differently on there? Are other tests featuring extcalls impacted?
I'm quite surprised by Verilator and synthesis disagreeing.
The text was updated successfully, but these errors were encountered:
mbty
changed the title
Different behavior between simulation and FPGA
Different behavior in simulation and FPGA
Jun 9, 2021
From the first part of the description I would have guessed that it was a speed issue (I've had issues with blinking LEDs too fast in the past). But the second part doesn't support this. Still, can you try changing WAIT to something larger and see if the problem remains? I'll investigate further soon. (Sorry for the long delay, your message came right after I left on a 2-weeks trip)
When synthesizing the RV32E example with the
unit/led
program on my TinyFPGA BX, the LED stays off.On the other hand, Cuttlesim and Verilator both behave as I expect them to following the definition of the test.
I tried the following things independently from each other:
with
in
top_uart.v
results in the LED turning (and staying) on (FPGA only, simulation not impacted although making the same change totop.v
indeed inverts Verilator's behavior);may_run
andon
byOb~1
in the extcall toext_led
inRVCore.v
results in the LED turning (and staying) on, as should be expected (FPGA and simulation);led.c
with a simpler infinite loop containing only a call toputled(1)
does not fix anything - the LED is still off, and simulation spams the output with the "☀" symbol.Do you observe the same thing on your side? I don't have access to an ULX3S-85k as of now, does this test behave any differently on there? Are other tests featuring extcalls impacted?
I'm quite surprised by Verilator and synthesis disagreeing.
The text was updated successfully, but these errors were encountered: