-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different behavior in simulation and FPGA #14
Comments
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) |
I just tried setting WAIT to larger values (2'000'000, 20'000'000, ...) to no avail. |
Thanks, I'll look into it. |
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: