Who's working with Symbiflow, Migen, Litex, Risc-V and the like?

[betocool]

Hi all,

First time poster here, somewhat longer lurking...

I've dabbled with FPGA's in the past, for extended periods of time or specific projects... about once a decade... 2002, 2009 - 2010 and 2018, going from the older Xilinx's and ISE Webpack with dev kits to the newer Intel (of Altera fame) MAX10's. Usually in VHDL, from simple things like a demo for the first project, a PCI interface in between, and the bootloader for the Max10s.

I started looking some time ago (new decade, see?) into the Digilent Arty boards, got one, and got sucked into the Symbiflow and Risc-V rabbit hole thanks to the Amp Hour podcast.

It seems like a ton of information, and still spread around wildly I guess.

Fortunately, I was able to download the Symbiflow examples, compile them and flash them onto the board. So far so good. The Verilog examples are simple enough, and then there's a big jump into the SoC world. The projects compile and load, unfortunately I still don't know exactly how to go on.

I will start looking into Migen for code creation. Then I guess I will look at the Risc-V cores (VexRiscv, PicoSoc, etc). But I still don't know how do I generate the firmware that actually goes into the hardware... also, I haven't yet been able to permanently store a design into flash memory.

Anyone here ventured that path?
Any recommendations for a non-vendor-specific IDE for .v or .vhd files (project managing mostly)?
Any good advice that I might be missing?

Cheers,

Alberto

[jeremy]

Neorv32 has really great documentation: https://github.com/stnolting/neorv32

I too have been looking at trying out the migen and symbiflow combo, but haven’t got around to it yet. Also, I’m more interested in the larger Xilinx FPGAs which don’t seem supported yet? (though I’m not totally sure)

[dolbeau]

I will start looking into Migen for code creation. Then I guess I will look at the Risc-V cores (VexRiscv, PicoSoc, etc). But I still don't know how do I generate the firmware that actually goes into the hardware...

You can start with https://github.com/litex-hub/linux-on-litex-vexriscv ; the infrastructure will generate the firmware/BIOS for you, along with the rest of the SoC. And it also simplifies building a buildroot to get Linux on it.

Litex supports many different cores, peripherals, and boards, so you can try your hands at different things once you get a basic configuration running as a 'baseline' experiment.

[SiliconWizard]

As talked about in another thread, I've played a bit with the yosys/nextpnr toolchain (with a Lattice ECP5). I have a hard time figuring out what Simbiflow really is, even after (admittedly quick) a look at it. Is it different from yosys? Does it actually use yosys? Is it some kind of fork? Is it completely separate? For some reason, while yosys/nextpnr projects are pretty "clear" (at least to me), Simbiflow looks a bit more nebulous. And one reason I'm wondering about it is that it seems to support the Xilinx Artix 7 series, while yosys still doesn't.

So if anyone can enlighten me on this...

And to the OP: I know about yosys/nextpnr and RISC-V, but nothing much about Migen and (as you figured) Simbiflow.

[DiTBho]

Do these things support VHDL?

[SiliconWizard]

Do these things support VHDL?

VHDL has been supported for a while now with yosys, through a plugin from the GHDL project. All my testing with this toolchain was with VHDL, and it worked fine.
( https://github.com/ghdl/ghdl-yosys-plugin )

As to Simbiflow, I don't know, as I again don't even know what it is based on.

[jeremy]

symbiflow is a tool which combines yosys and several other tools (including an open source place-and-route that supports artix7-35T devices) to target multiple FPGA families from different vendors. You could consider it to be a superset of yosys and nextpnr.

As far as I know, it does support VHDL via GHDL, but the process is not straightforward at all. Probably the easiest method is to synthesise your VHDL to verilog using GHDL, and then passing that into symbiflow. If you just wish to use VHDL with yosys/nextpnr, have a look in the examples for neorv32; there are examples for ice40 and ecp5 FPGAs.

[SiliconWizard]

After a closer look, Simbiflow is based on yosys and nextpnr indeed. But they apparently use their own fork of yosys - I don't know how close to the main project it is. So in particular, I don't know if it supports VHDL through the GHDL plugin as well as vanilla yosys. On the latter, VHDL support is actually rather good at this point.

I found Simbiflow a bit "obscure" at first - possibly due to their home page,  which I find more marketing-like than technically informative. I had to dig a bit deeper in the github repos to figure more things out.

As to using GHDL synth separately - which generates Verilog from VHDL - and passing the result to yosys, that's something I had tried when I was experimenting with it, and it's ridden with pitfalls, in particular when dealing with "blackbox" components. So the preferred way is to use the GHDL plugin, which works way better.

Regarding the support of the Artix-7 in Simbiflow, it looks like still a WIP. In particular - from the little I've seen so far - you still need Vivado at some point of the workflow? So right now, this is a bit pointless for end-users.

[jeremy]

I don't think you need vivado unless you want to manually build the chip databases from scratch (which regular users should not be doing). You can download the pre-generated databases directly.

[woofy]

I love that the Symbiflow project is there and progressing. One day it has the potential to be the goto FPGA flow for a wide range of devices.
Its still a WIP though. I use yosys/nextpnr for the iCE40 to go from verilog to bin in one makefile. That's hard to top.

[betocool]

Good comments all, thanks for the input, and I welcome the questions as well... might result in something useful for all of us after all.

My little experience (feel free to correct me where I'm wrong):
- Symbiflow is a superset of Yosis, nextpnr for Lattice FPGAs and VPR for Xilinx routing. Project Trellis and X-Ray are the bitstream generators.
- At this stage it is possible to generate a bitstream and load it onto the FPGAs using JTAG (I'm using the Arty-7 board JTAG). I have not yet figured out how to load it in flash! But I think that's a matter of time.
- Some Lattice FPGAs are supported. As of December 2019 I'd say most of the functions and blocks are supported
- Xilinx FPGAs, I believe Ultrascale and Artix are well supported (bar the DSP blocks I believe), not sure about Spartan 7. There was less support for older devices.
- Quicklogic FPGAs are completely open source and work together with Symbiflow.
- For me, the best way to get started was to go to the https://symbiflow-examples.readthedocs.io/en/latest/. Less technical details, but more of a how to get started page. Really helpful. All projects I've tried have generated bitstreams.
- All these tools run on Linux, apparently Windows support is a bit meh...

Like I said, I'm missing a way to permanently flash the bitstream, a decent-ish editor (I'll try VS-Code just for kicks), and a way to figure out how to write firmware once the controller is on the FPGA and where to store it. It's a long term project for me, so I'm taking it a step at a time.

There are a bunch of good videos on YouTube where Tim "Mithro" Ansell explain the concept of Symbiflow and how far it has gone. Last one was from 2019, I haven't seen any updates yet. And yes, the Symbiflow main page seems a bit difficult to navigate. Seems to be made more for software developers that actual users.

Cheers,

Alberto

[Boscoe]

Simbiflow etc seem very interesting and I’d absolutely love to ditch the awful (but very powerful) tools provided by the vendors. However, does anyone know the status of generating vendor IP in these 3rd party tools? How do I create a memory interface for Artix 7 for example? Or use the ARM processor in a Zynq? Until those things are sorted I can’t see these tools going beyond the hobby community. I also understand those things are a big ask.

[SiliconWizard]

Simbiflow etc seem very interesting and I’d absolutely love to ditch the awful (but very powerful) tools provided by the vendors. However, does anyone know the status of generating vendor IP in these 3rd party tools? How do I create a memory interface for Artix 7 for example? Or use the ARM processor in a Zynq? Until those things are sorted I can’t see these tools going beyond the hobby community. I also understand those things are a big ask.

I have evaluated yosys/nextpnr/prjtrellis a bit on the ECP5, enough to get a good idea of this. While amazing projects, they are still not on par with the vendor tools in terms of the end result. Of course it all depends on the design itself, but an approximate average is 30% more resource utilization and 30% (or sometimes lower) lower Fmax on a typical moderately complex design. I admit it's already not too shabby at all.

Regarding vendor IPs, of course there would be first the question of license. Even if the IP are free, they usually come with some form of licensing which is not necessarily (or even rarely) open source. Meaning you may not legally be allower to use vendor IPs with tools others than their own. I'm no lawyer, so if anyone knows more about this particular point, they can chime in. Beyond the licensing issues,  technically, as I think I said earlier, it's just a huge pain. Vendor IPs will usually not be usable as is with the open source toolchains, because most of them use attributes and blackbox primitives that are simply not supported by them.

For instance, something as "simple" as a dual-port memory block using EBR, generated as an IP in Lattice Diamond, required significant hand modifications to be used with yosys. That was doable because this kind of IPs is relatively simple, but I wouldn't even think about doing the same with much more complex IPs.

So don't expect those tools to be a plug and play replacement for vendor tools - they will likely never be. But there's still a lot you can do with them at this point. It just requires some significant homework to get there.

[betocool]

My interest in all of this is to have a template or cookbook how to get a Risc-V core running on an FPGA, add one or more peripherals, as you would on a micro, say, SPI, Timers, and the like, as required; then program the firmware for it (start with the famous blinky example) and go for a FreeRTOS port; finally, have a bitstream that gets loaded from an SPI Flash and a .bin firmware file that resides on said Flash, that finally gets loaded into DRAM and run from there.

I'm guessing someone must have done this, I believe the folks at Antmicro have this, only they use Zephyr instead of FreeRTOS. I've only compiled Zephyr once, and yeah, it worked, but I prefer FreeRTOS because I have a bit more control about how the peripherals are used.

But for such niche applications it seems very difficult to find a suitable explanation on how to do things. Still, slowly we'll get there.

Cheers,

Alberto

[dolbeau]

My interest in all of this is to have a template or cookbook how to get a Risc-V core running on an FPGA, add one or more peripherals, as you would on a micro, say, SPI, Timers, and the like, as required; then program the firmware for it

As I mentioned earlier, this entire process is what linux-on-litex-vexriscv is for, except with Linux instead of FreeRTOS. There's also a zephyr-on-litex-vexriscv, but I've never tried it. Those should provide a good starting point to create freertos-on-litex-vexriscv :-) Of course Litex supports core other than VexRiscv as well - it's just that VexRiscv is currently the best supported for working-out-of-the-box Linux.

[betocool]

Hi all,

Linux on SoC is something I will look into after I've got at least Bare Metal and FreeRTOS running on a chip. I found this page:
https://github.com/cliffordwolf/picorv32, where there's a bit more detailed information about the core and an example based on Lattice. I reckon I can use said example as a starting point for a simple core, UART and GPIO on the Arty7.

Still, there's still much to read. At the moment I'm also in touch with the Symbiflow crew, trying to figure out why the FPGA takes 10 seconds instead of 2 to load from SPI flash. But we're moving...

Cheers,

Alberto

[betocool]

Hey all,

I started a series of posts (two, actually) documenting what I've done so far regarding RISC-V, Symbiflow and an Artix-7 FPGA.

Feel free to have a look, test, download, comment, etc. I don't think this will be a terribly fast process for me, but it'll help me re-check and write down what I'm up to so far.

https://github.com/betocool-prog/symbiflow_adventures
https://github.com/betocool-prog/picosoc_step_01

Cheers,

Alberto

[betocool]

Hey everyone,

does any one know how to generate a schematic out of a verilog module (or modules) using the Symbiflow tools? I'm trying a small design and while there are many ways to skin a cat, I'd like to see a graphical representation of the differences.

Cheers,

Alberto

[laugensalm]

does any one know how to generate a schematic out of a verilog module (or modules) using the Symbiflow tools? I'm trying a small design and while there are many ways to skin a cat, I'd like to see a graphical representation of the differences.

You can simply use the 'show <module selection' command in yosys to display a .dot schematic or output to a .dot or PDF using the '-format' option.
However this is just ok for debugging and not very beautiful in the sense of a classic gate level schematic display, once you display more of a logic zoo than a simple block level hierarchy.
You might also check for 'netlistsvg' or the utilities from the 'libhwt' suite, those require a bit of programming glue in Python or Javascript, depending on the target display.
There are a few Jupyter Notebooks around with documenting examples IIRC.

[laugensalm]

My interest in all of this is to have a template or cookbook how to get a Risc-V core running on an FPGA, add one or more peripherals, as you would on a micro, say, SPI, Timers, and the like, as required; then program the firmware for it (start with the famous blinky example) and go for a FreeRTOS port; finally, have a bitstream that gets loaded from an SPI Flash and a .bin firmware file that resides on said Flash, that finally gets loaded into DRAM and run from there.

Just read this -- there are VHDL based templates in this repo (https://github.com/hackfin/hdlplayground/, most recent intro is the ew2021 presentation) allowing to code/synth/verify/download to an ECP5 target, in fact I've got an almost running RISC-V SoC flow using VHDL/Verilog mixture, however, since the yosys upstream memory inference is not complete yet when it comes to TDP RAMs (this is why it's tagged 'almost'), I've abandoned that path for the time being and put my bet on pure direct RTL inference via the yosys Python API using myHDL front ends. This has unfortunately opened up a few more construction sites than expected, so I refrained from publishing more about it, after all, documentation asks for a lot of maintenance.

I can't speak about Symbiflow, as I'd tend to cherry pick, but yosys is presumably on the way to have these last issues with TDP RAM fixed, so that it should be possible to achieve results close to Lattice proprietary tools. With hand woven interaction, I was able to get some legacy designs running at the same speed as with the Synplify flow.

[SiliconWizard]

does any one know how to generate a schematic out of a verilog module (or modules) using the Symbiflow tools? I'm trying a small design and while there are many ways to skin a cat, I'd like to see a graphical representation of the differences.

Apart from the .dot output mentioned (which uses graphviz if I'm not mistaken, and which doesn't look all that good for moderately complex designs), there is netlistsvg, which should look better, but it's probably far from perfect and bug-free: https://github.com/nturley/netlistsvg

[betocool]

Yes, I went down the path of netlistsvg and tried out yosys as well... They look ok, but ended up trusting the simulation instead.

@laugensalm, I'll have a look at that Repo later on this week, thanks! I'm still in two minds whether at this stage open source is practicable for users rather than very involved developers, I find that documentation is the problem mainly, there's not much you can do if you run into issues. Still an interesting exercise.

Cheers,

Albert