Gowin Vs. Yosys

[Rainwater]

Gowin (1) Yosys (0)

I have been trying to figure out why this design works in simulation but not on my device
I have been tracking down an off by one error "on-chip", that does not match simulations.
If I build and load the verilog with yosys and nextpnr, the error is present and the design broken.
If I build this with GOWIN's toolchain, the design works as expected.

anyone have any tips about this kind of problem?
If this is a bug in yosys, whats the proper way to report it?
Code can be found here
https://github.com/Adivinedude/UART-Echo-Service
Dev board tang nano 9k.

UART.fs - Yosys/nextpnr
GOWIN_UART.fs - Gowin toolchain

Please feel free to give coding pointers as well. every bit helps

[iMo]

..If this is a bug in yosys, whats the proper way to report it?
..

https://github.com/YosysHQ/yosys/issues

Gowin
https://github.com/YosysHQ/apicula
https://github.com/YosysHQ/apicula/issues

[colorado.rob]

Apicula has many bugs. Report them as you find them.

Use Apicula if you want to help them chase down bugs and improve the tool.

Use Gowin if you need a tool that works.

[pcprogrammer]

Don't forget that Apicula is the result of reverse engineering and not based on any proper manufacturers documentation. This simply because there is none available.

This makes it very likely that there are errors in both timing information as well as missing configuration bits that make or break something.

Also the reverse engineering will most likely have been done on older versions of the Gowin software and might not be up to date on already by Gowin solved bugs in their own software.

[Rainwater]

Im just not sure if its a bug or inexperience.
Before I got my code this far, i spent a week chasing down why different modules where randomly resetting. (Directly using an external input is bad practice)
Then another few days figuring out why logic was randomly sampling just after clock edges and not before `always @( posedge clk)` instead of `always @(*)`
Im almost 90% sure this is something being inferred in a way I dont yet understand. This has been the reason for every misunderstanding me and yosys have had.
Ill send this their way, might be able to help them.

[SiliconWizard]

This is the case for pretty much all architectures supported by yosys/nextpnr, apart from the ones officially supported (some newer FPGA vendors now use this toolchain so obviously they have integrated the right models for their chips.)

[HunterMuller]

Does anyone have experience using Yosys on RISC-V level projects? If so, please share. Does it make sense to attempt something on such projects, or has Yosys not yet reached such heights?

[tverbeure]

Does anyone have experience using Yosys on RISC-V level projects? If so, please share. Does it make sense to attempt something on such projects, or has Yosys not yet reached such heights?

I use VexRiscv CPUs for all my FPGA projects, and some of those projects are done on an ECP5 FPGA with Yosys and NextPnR as backend. If your clock speeds are pushing the limits (I can run the CPU at 48MHz without issue), then it works fine.

Latice ICE40 and ECP5 FPGAs have the most stable Yosys/NextPRN support. I would stick to those 2 families if you want to give it a try.