Skip to content
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

Open
mbty opened this issue Jun 9, 2021 · 3 comments
Open

Different behavior in simulation and FPGA #14

mbty opened this issue Jun 9, 2021 · 3 comments

Comments

@mbty
Copy link

mbty commented Jun 9, 2021

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.

@mbty mbty changed the title Different behavior between simulation and FPGA Different behavior in simulation and FPGA Jun 9, 2021
@cpitclaudel
Copy link
Contributor

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)

@mbty
Copy link
Author

mbty commented Jun 23, 2021

I just tried setting WAIT to larger values (2'000'000, 20'000'000, ...) to no avail.

@cpitclaudel
Copy link
Contributor

Thanks, I'll look into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants