Gowin Vs. Yosys - Page 1
Forum section: electronics / general

author: Rainwater
author_rank: Regular Contributor
timestamp: March 21, 2024, 12:57:16 am
content: Gowin (1) Yosys (0)I have been trying to figure out why this design works in simulation but not on my deviceI 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 herehttps://github.com/Adivinedude/UART-Echo-ServiceDev board tang nano 9k.UART.fs - Yosys/nextpnrGOWIN_UART.fs - Gowin toolchainPlease feel free to give coding pointers as well. every bit helps

author: iMo
author_rank: Super Contributor
timestamp: March 21, 2024, 10:56:44 am
content: Quote from: Rainwater on March 21, 2024, 12:57:16 amhttps://github.com/YosysHQ/yosys/issuesGowinhttps://github.com/YosysHQ/apiculahttps://github.com/YosysHQ/apicula/issues

author: colorado.rob
author_rank: Frequent Contributor
timestamp: March 21, 2024, 05:29:02 pm
content: 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.

author: pcprogrammer
author_rank: Super Contributor
timestamp: March 21, 2024, 08:03:37 pm
content: 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.

author: Rainwater
author_rank: Regular Contributor
timestamp: March 21, 2024, 08:06:07 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 21, 2024, 08:08:16 pm
content: 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.)

author: HunterMuller
author_rank: Newbie
timestamp: April 06, 2024, 11:25:37 pm
content: 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?

author: tverbeure
author_rank: Regular Contributor
timestamp: April 09, 2024, 11:38:17 pm
content: Quote from: HunterMuller on April 06, 2024, 11:25:37 pmI 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.