Giters

ghdl / ghdl

VHDL 2008/93/87 simulator

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Target projects for synthesis

eine opened this issue · comments

commented

I would add:

commented

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

commented

There seems to be a lot of momentum behind RISC-V, and of course some cores are written in VHDL: riscv/riscv-cores-list

Is there any of them which is written in VHDL, ready-to-use and actively maintained?

It seems that among hobbyists, retro computing is very popular, for example: riscv/riscv-cores-list

Did you mean to repeat the link or should this be different?

commented

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.

commented

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.

commented

You can also use:

commented

sorry ... but what do you exactly need so i can help you ?

commented

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.

commented

Hi eine,

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.

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.
This one is kinda 'active', i.e. CI'ed and passes the official riscv-tests (see https://section5.ch/index.php/2019/10/24/risc-v-in-the-loop/), so I'd consider it kinda stable. It just doesn't follow the official debug and CSR 'standard'.
You're right about not opening the box with the generators, as MyHDL has some deficiencies as of now, some bugs need fixing in upstream before until a fully automated chain can be set up.

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).
Problem with XSL/XML is in general that it is hard to not create write-only code.
Don't know if that could be reused easily in the GHDL synth to back-annotate code, saying like: This construct doesn't synthesize.
The other approach to take during ghdl-synth development could be to integrate all synthesizeable snippets/constructs from the test suite and display them as default. Maybe including the forbidden ones to see the DONT'S as well.

commented

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'.

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:

  • To generalise ghdl-yosys-blink's Makefile to more easily handle different target platforms. Hence, GHDLSynth.py supports docker, podman or natively installed tools; and it supports either ICE40 or ECP5 targets.
  • To have it imported/copied in Python based projects (such as tsfpga or edalize) or used by developers directly.

https://github.com/eine/vhdl-cfg/blob/master/run.py is an example of how to use GHDLSynth to build multiple bitstream for the Icestick. I now want to focus on adapting/testing the UART loopback example to all the platforms. Both VUnit and cocotb have examples of UART VCs, so it should not be hard, as soon as I have some free time. For tsfpga and edalize/fusesoc, I'll need some more effort. Contributions are welcome!

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.

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.

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:

  • A YAML file listing all the features and providing some metadata about them.
    • At least one MWE per desired feature.
  • A script (Python or JS) that creates one issue per feature in the target project's repo. If the issue exists, it is updated.
  • Use issue-runner to detect when a previously failing issue is supported by some latest commit.

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.

Don't know if that could be reused easily in the GHDL synth to back-annotate code, saying like: This construct doesn't synthesize.

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.

The other approach to take during ghdl-synth development could be to integrate all synthesizeable snippets/constructs from the test suite and display them as default. Maybe including the forbidden ones to see the DONT'S as well.

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?

commented

I now want to focus on adapting/testing the UART loopback example to all the platforms

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)
With workarounds, the ZPUng based SoC is synthesizing. RISC-V works as well, but still has some quirks.

Update: Build instructions:
https://section5.ch/index.php/2020/02/17/masocist-support-of-opensource-synthesis-for-ecp5/

In general, the main obstacles I found to get complex projects synthesised (and which partially require wrapping):

  • Black box vendor primitives
  • Dual port RAM inference
  • if..then generate statements (test cases being gathered) Fixed with #1076

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.

For the Lattice ECP5 it's roughly 150. See also https://github.com/tgingold/ghdlsynth-beta/blob/master/library/ecp5u/components.vhdl.
Most of them are probably obsolete, as trellis has own primitives and no one would probably instance a LUT4 manually. All black boxes should eventually resolve anyhow, once generics can be mapped from GHDL synthesis.

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.

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 pragma Assert into Error_Msg_Synth.

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?

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'.

commented

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!