-
Notifications
You must be signed in to change notification settings - Fork 348
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
Target projects for synthesis #974
Comments
I would add:
|
There seems to be a lot of momentum behind RISC-V, and of course some cores are written in VHDL: https://github.com/riscv/riscv-cores-list It seems that among hobbyists, retro computing is very popular, for example: https://github.com/MiSTer-devel |
Is there any of them which is written in VHDL, ready-to-use and actively maintained?
Did you mean to repeat the link or should this be different? |
There seem to be a few VHDL ones (see primary language column), not sure how complete and active any of them are. Arbitrary data point: I've come across RV01 in another context. Seems most of the famous, ASIC proven ones are Chisel and SystemVerilog cores mostly. But this list seems like the best chance to get a GHDL-driven ASIC one day :)))) Sorry, meant to link to MiSTer, link updated. It's a whole bunch of retro CPU cores, most of them in VHDL. |
I added MiSTer to the list. So cool org, BTW. Regarding riscv-cores-list, I will hold from adding it for now. On the one hand, I am unsure about the status of the ones written in VHDL. On the other hand, I'd like not to open the box of HDL generators yet. As a matter of fact, I have used, modified/extended and programmed VexRiscv (SpinalHDL) with VHDL output; thus, it is healthy. Apart from wining the RISCV contest last year, VexRiscv is gaining lots of attention from (litex, antmicro/renode, etc.). Nonetheless, testing any of the higher-level generators requires additional tooling that I/we cannot assume to maintain in the context of GHDL. Should anyone volunteer to contribute a glue script to have VHDL sources as the entrypoint for the synthesis test suite, I'd be so glad to review/help. |
You can also use:
|
sorry ... but what do you exactly need so i can help you ? |
Hola Miguel! Thanks for stepping by. We don't need anything for now. Synthesis support is being added to GHDL, and it should be out of beta in the next release. This issue is to track interesting projects written in VHDL that we would like to test with that release. I found your project (video) really cool, and I added it with the hope that we can have it synthesised with open source tools in the future. However, GHDL's synthesis features do not support memories (BRAMs) yet. Since your project is mostly based on BRAMs, it won't work ATM. Apart from that, open source implementation (P&R) tools (yosys, nextpnr) support only a subset of devices yet. I think that none of the devices/boards that you use are supported. Best bets would be ecp3versa and arty. Last, it seems that you use Ethernet and DDR, which might need vendor IP, independently of the tools used to synthesise your open source VHDL sources. Therefore, I don't expect full support for your project to be available in the short-mid term. Nevertheless, GHDL's simulation features are quite mature already. You might be interested on trying it to simulate your VHDL designs. |
Hi eine,
As you mentioned the MaSoCist setup: There's a RISC-V SoC in it, too. The core is called pyrv32, written in Python with use of MyHDL, however the the repo contains only its VHDL output. Nevertheless, my goal is, to have a full VHDL based open source synthesis in the CI some day for all ECP5 powered SoC configs, so I'm glad to help, in fact, it's tackled right now. The most crucial item at this moment is indeed the dual port RAM (also referring to #1069) which I can't easily swap out by a Verilog 'black box'. One thing that would be nice to have is some kind of coverage or DRC overview of what primitives are in general recognized and inferred correctly. I've played a bit with this on an XML level (https://hackfin.gitlab.io/xhdl/) - thing is that the job needs to be done twice, first in the synthesis integration, then the corresponding style sheet for the DRC. My initial thought was to provide means for early code analysis/DRC, plus conversion to various formats (SVG, MyHDL). |
As we commented in Gitter, there is work in progress going on. Apart from @antonblanchard's ghdl-yosys-blink, which you already forked and extended (hackfin/ghdl-yosys-blink), I created eine/vhdl-cfg as a result of recent discussions regarding modularity and effort duplication in the ecosystem (VUnit, tsfpga, cocotb, edalize, fusesoc, etc.). The idea is to take existing simple and not-so-simple examples and make them work with different tools for simulation and/or implementation. I started with the examples from ghdlsynth-beta and ghdl-yosys-blink. Since most of the target tools/project do not support synthesis and implementation with GHDL + yosys + nextpnr + (icestorm | prjtrellis) yet, the first I did was a Python class: https://github.com/eine/vhdl-cfg/blob/master/GHDLSynth.py. The purpose is twofold:
https://github.com/eine/vhdl-cfg/blob/master/run.py is an example of how to use So, regarding your SoC configs, I'd be interested on extending GHDLSynth to support verilog black boxes. I know it is not stable yet, but whenever you find that name mangling is consistent, I'd like to have it integrated.
This sounds similar to Compliance-Tests, which is for simulation. See also VHDL/Compliance-Tests/tree/LCS2019/issues and eine/issue-runner. It might be interesting to reuse/replicate the same scheme:
How many primitives are we talking about? In Compliance-Tests, we want to follow this scheme for VHDL 2019, because the number of LCS is ~60. However, for VHDL 2008 it could be a nightmare.
I think it would be relatively easy to replace crashes with nice errors. However, I don't know if it provides any advantage to the user. I believe that's why Tristan keeps the crashes until a feature is implemented.
I'm not sure I understand what you mean with "display them as default". Are you thinking about snippets/contructs with generics/parameters and "default" means hardcoding values for those? |
I felt free to add such an example to ghdlsynth-beta (isolated from MaSoCist). This also does the wrapper dance again, I'll get rid of the blinky fork shortly. In general, the wrappers should have a short life time, once GHDL can map generic parameters. (NB: ghdl/ghdl-yosys-plugin#46) Update: Build instructions: In general, the main obstacles I found to get complex projects synthesised (and which partially require wrapping):
For the Lattice ECP5 it's roughly 150. See also https://github.com/tgingold/ghdlsynth-beta/blob/master/library/ecp5u/components.vhdl.
With crash you refer to 'GHDL bug' caused by pragma asserts? It definitely helps knowing where and in what file it occurs. So for debugging I tend to replace the
With 'default' I mean the component display in the 'xhdl' browser. You can otherwise drag an XML output from GHDL into it to get it 'DRchecked'. |
I have lot of basic GHDL examples already available here: https://github.com/kost/ulx3s-ghdl-examples Feel free to take them. If there's any way I can make it more available for your CI needs - do let me know! |
The purpose of this issue is to gather a list of projects that we can use as tests for ghdl's synthesis features.
We did not set up any automated testing job/workflow (CI). However, if authors of the projects provide an entrypoint script, we can easily gather them.
The text was updated successfully, but these errors were encountered: