YoSys: status?

[DiTBho]

There is a 2-years old article on Reddit, which says YoSys is not recommened for any personal projects with the complexity of a SoC, not even a simple RISC-Softcore with RAM, ROM, serial, and some other peripherals.

I don't know 

I have never tried it and I see that it has been removed from the Gentoo portage, a sign that ... it creates many problems and/or has little interest.
(I have a personal Overlay, I can work on it)

Another aspect, it seems to have more support for Lattice ICE40, while I am more inclined to use Xilinx { SP3-{250, 500, 1200, 1600}, SP6} which do not seem to have support.

Finally, I do not like to use Verilog, I prefer VHDL, and here I did not understand well if there is support, and how good it is.

-

Good point of YoSys: it's fully opensource, theorically it can be compiled for { HPPA2, MIPS32, MIPS4, POWER10, ... } as well as for mainstream platforms { x86, amd64, arm*, ... }

At the moment I bought an Apple MacMini intel Core Duo Dual (amd64, 2 cores, 8GB ram), dedicated exclusively to Xilinx ISE-v10 on GNU/Linux with Bash scripts to start the synthesis for Spartan3 FPGA..

From my point of view that mac mini is a "black box" that shares files on NFS and to which I send commands over SSH to get a bitstream in response, while I work on HPPA Workstation, on which I have VHDL simulation tools, text editors, etc. .

The workflow is transparent for me. I work on the HPPA workstation, I write VHDL code (usually with nedit), I simulate it on the workstation (GHDL + GTKWave + misc), and when I want to try it on the real target ... I launch a script and wait for the bitstream back, produced by a remote server.

It works very well, but it depends on that server.

My interest in YoSys was due to the desire to make the HPPA workstation completely independent and autonomous, i.e. capable of producing bitstreams for the FPGA.

Probably not feasible, not with Xilinx SP3. I still have to try Lattice's FPGAs.

[DiTBho]

ghdl-yosys-plugin, see here
not yet tried.

plus, first I need to upgrade GNAT
(which is not an easy task for HPPA
anyway, I will first try it on x86)

[iMo]

Here is a demo you may try to compare the icestorm tools (yosys/arachne-pnr), icecube and radiant (Lattice tools)..
https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB

Also a risc-v (RudoIV) and picorv32 I tried worked fine with the icestorm tools later on.
https://github.com/igor-m/Risc-V-on-FPGA-experiments

The dev tools from Lattice were a bit more optimized and efficient, but the results were similar.
Never tried icestorm with Xilinx (none Xilinx support at that time afaik).

[dolbeau]

While the open-source toolchains may not have all the features and performance of proprietary tools, they can achieve quite a bit already.
For instance, see "A Trustworthy, Free (Libre), Linux Capable, Self-Hosting 64bit RISC-V Computer".

[Nominal Animal]

I have never tried it and I see that it has been removed from the Gentoo portage, a sign that ...

... indicates there is no interested portage maintainer for yosys?  Debian packaging is similarly lagging/problematic.

Whether yosys is fit for purpose, I have no idea.  I only know it is in active development.

AFAICT, the home page is nowadays at yosyshq.net/yosys (but see also yosyshq.com/open-source), and the sources at github.com/YosysHQ/yosys.  The latter has a large number of pending issues and pending pull requests, but the commit log shows regular activity with releases coming out.

[nctnico]

I'd use the manufacturer provides tools for FPGA / CPLD synthesis. This software is tested & supported. Yosys is mainly interesting for smaller semiconductor manufacturers to base their tools on and educational purposes.

[Nominal Animal]

There is absolutely nothing wrong in using proprietary tools for business or work, even if you are/were a staunch proponent of open source software/hardware.

What matters for paid work is your productivity, and the quality of the solutions.

The reason to go open source should always be practical, and not just "lower cost".  Avoiding vendor lock-in, and having the ability to maintain, fix, and modify the tools oneself or independently from any vendor, should be very close to the top of the list of reasons, or it will not work out well.

For hobby stuff and education, there are additional aspects, like the ability to learn as much as you care to about how things work, that make open source software and hardware useful and important.

[DiTBho]

I'd use the manufacturer provides tools for FPGA / CPLD synthesis. This software is tested & supported. Yosys is mainly interesting for smaller semiconductor manufacturers to base their tools on and educational purposes.

That's why I bought a MacMini Intel to make a dedicated server for the synthesis of Xilinx SP3 FPGAs:
I wanted to be 100% sure that the synthesis was for a supported chip, and that the tool did not introduce other problems.

[DiTBho]

The reason to go open source should always be practical

The problem I have with Xilinx/ISE is that it is a set of x86 binaries, and QEMU/x86 emulation done on HPPA works very poorly.
It would be much much better to have something that runs natively!

From what I understand, the main interest of YoSys is for Lattice chips.

I willing to change FPGA platform, I just need to figure out what kind of Lattice chip is equivalent, in terms of resources, to a SP3-500 (which I typically use for everything), then find an evaluation board.

But first I need to figure out if I can get YoSys to work on HPPA,  etc 

[nctnico]

The reason to go open source should always be practical

The problem I have with Xilinx/ISE is that it is a set of x86 binaries, and QEMU/x86 emulation done on HPPA works very poorly.
It would be much much better to have something that runs natively!

I don't think that is a worthwhile endeavour. Once your designs get larger, the time to place & route the design will increase exponentially. I have some designs which need about 8 hours to go through this process. A better route is to get the fastest x86 processor where it comes to single core performance. Depending on design size, you might need at least 8GB of ram. Preferably more. Doing synthesis on an emulated system running on a CPU from the 1990's is just asking for discomfort.

Where it comes to FPGAs with a decent amount of logic, I'd stick the Xilinx or Altera. They have a large market share and all the nitty gritty of the tools is known & documented. And the tools run on both Linux and Windows.

[DiTBho]

For job stuff I fully agree.

For hobby stuff ... umm, I don't have complex designs, both because I don't have hw to simulate complex things, and because I don't have hw hw to synthesize.
The maximum I can fill is 70% of the resources of a Spartan3E-500.

CPU from the 1990

PA-8700 CPU @ 875Mhz, released in 2001
PA-8900 CPUs @ 1100Mhz, released in 2005

It doesn't make much difference to the point you raised.
Just that 10 years of IT stuff makes it less worse than the scenario one might imagine with e.g. a mid- 1990s PA-7100LC CPU @ 90Mhz 

[asmi]

Working with FPGA it is highly recommended to get the fastest CPU you can afford, because you will likely spend most of your time in simulator, and it's a very CPU-intensive task. Speed of synthesis and place & route is not that important because normally you won't be doing it very often, but it's just so happen to also benefit a lot from faster CPU. Even though some tasks (like synthesis) can be ran in parallel (for example via out-of-context synthesis in Vivado), it still very much limited by the raw speed of a single core, or perhaps a handful of cores. OOC does reduce synthesis time sometimes by the order of magnitude if your design (and CPU of course) allows it, but like I said above, it ultimately doesn't really matter because you probably aren't going to be sitting still and staring at a progress bar anyway, and will do something else while this process is ongoing.

As for open-source tools - aside from what others have already mentioned, one issue with them is how much you can trust its results. Say what you will about vendor's tools (and I agree with a lot of criticism), but if they tell me that my design meets timing, I can "take it to the bank" that timing will be met over the entire PVT envelope, as it's guaranteed by the vendor. With OS tools there is nobody which will guarantee you anything, so you will have to perform extensive (and thus expensive) testing over entire gamut of conditions in which design will have to work properly.

[DiTBho]

you will likely spend most of your time in simulator, and it's a very CPU-intensive task. Speed of synthesis and place & route is not that important because normally you won't be doing it very often, but it's just so happen to also benefit a lot from faster CPU

For business, you are undoubtedly right, but ... here the goal is to give a hobby purpose to a line of RISC workstations that otherwise would no longer have a purpose to exist

Think that I took a plane and went in person to Sweden to collect my C3750, still packaged, from a company that had purchased it in case they needed HPUX/PA_RISC support, but then never used and replaced with a Xeon workstation!

From a construction and design point of view, this workstation line is undoubtedly much more interesting than any "PeeeCeeee" ever built.
A real shame that the PA-RISC line ended with the PA-8900.

In any case, I spent 2 years, in my spare time, to port GNAT to GNU/Linux HPPA. It was used to compile GHDL, and I can say that for not too complex HDL simulations a single CPU @ 875Mhz is fine.

Can we quantify? Sure, let's take a real project: the GameDuino-v1.
It's a "forth-oriented CPU designed to be a video Coprocessor" written in Verilog.
I rewrote it in VHDL.

Years ago, Olimex commercialized a similar thing using a Spartan3-250, and the resources used are not even at 90%.

I have no commercial interests, I took that project simply because I was interested in studying the architecture of that strange CPU, and then I needed a real project to test GHDL on HPPA.

I mean, my little projects are usually much more "clean" and GHDL oriented, a slight difference that however makes a "big" difference between simulating something with iSim (Xilinx) or with GHDL.

Well, on my single PA-8700 CPU @ 875Mhz, with only 8GB of ram (which is the maximum for that workstation), I was able to simulate the entire project using GHDL and GTKwave, and it didn't even take long to have the timing diagrams.

From the Makefile, to the wave file it takes less than a quarter of a minute.

Consider, on PA-RISC ... HDs are usually SCSI @ 7200RPM, the PCI-SCSI-HBA subsystem (in my case Adaptec 29160) does not even work optimally on linux kernels v5, and typically wastes 40% of the bandwidth, with a maximum of 30Mbyte/sec in read/write.

For me it is more than acceptable, so much so that I have been using the workstation for about 1 year to develop parts of my study SoC.

It is a personal RISC architecture (read it "my personal toy"), similar to MIPSR32, but with some modifications.
At the moment I am working on a transactional memory, about 900 lines of VHDL code.

The problem is: I cannot synthetize the "GameDuino-v1" for my Digilent SP3-500 eval board (cheapest version) without the need of an external servel, and when I send the file to the MacMini intel server where XILINX ISE runs natively, it takes at least 15 minutes before the bitstream is returned.

So I would probably buy a more powerful x86 computer to run Xilinx ISE on, while I wouldn't replace the HPPA workstation because - as far as my needs are concerned - for simulation it's more than acceptable 

[DiTBho]

As for open-source tools [..] one issue with them is how much you can trust its results.
Say what you will about vendor's tools (and I agree with a lot of criticism), but if they tell me that my design meets timing, I can "take it to the bank" that timing will be met over the entire PVT envelope, as it's guaranteed by the vendor. With OS tools there is nobody which will guarantee you anything, so you will have to perform extensive (and thus expensive) testing over entire gamut of conditions in which design will have to work properly.

This is exactly one of the doubts I had: how much can I trust the results of YoSys&its friends?

Not that it has any kind of time constraints, usually I almost never have any time or phase constraints in the UCF file, but ... e.g. this could be a big problem if I wanted to ... support the Papilio/Pro(1) that mounts SDram that has a couple of constraints to consider during the synthesis.

I usually get by with BRAM, I never use PLL, I always have only one system clock, which usually never exceeds 50Mhz.

So let's say I work in a "comfort zone"
But it is very frustrating not to be able to trust the tool, also because it does not have any kind of means and know/how for experimental verification 

(1) I am not sure, but I don't think Xilinx Spartan 6 LX9 is supported by YoSys&its friends

[SiliconWizard]

I had done some tests with it (using VHDL and the corresponding GHDL plugin) a while back, targetting a Lattice ECP5. I did test it with a Z80 core at the time (T80) and the Fmax was announced to be about 50 MHz with that design. Which was OKish, but I would get significantly higher with Lattice Diamond. It did appear to work fine, although I haven't tested the resulting core thoroughly either.

The part strictly from the GHDL project (for VHDL support), I trust 99.9%. I have been using GHDL for simulation for a long time.

The Yosys toolchain is used commercially by some of the newer FPGA vendors themselves. So it's probably considered stable enough.

In terms of features, it still doesn't support IO timing constraints (that I know of) and no block-specific timing constraints either (so you can only specify a global required min. frequency), but that latter part may have changed since I tested it. And the result is still not quite on par with the commercial vendor tools (if again we except the ones that actually use Yosys), both in terms of timing and utilization.

But for hobby use and if you don't have very specific timing constraints, it's certainly worth considering. It is used successfully to generate bitstreams for RISC-V SoC (LiteX) on various FPGAs (mostly Lattice), with SDRAM or even DDR RAM support.

[pcprogrammer]

What is not mentioned here is that all the FPGA manufacturers keep the inside information close to their chests. This means that all the needed FPGA data to create a bit stream is obtained by reverse engineering, which allows room for lots of errors and uncertainties, depending on how and who did the reverse engineering.

What I read about it while working on the reverse engineering of a bit stream for an Anlogic FPGA, is that a lot is done by automated tools that use the manufacturers tools to create bit streams based on a simple design and then try to determine the meaning of certain bits in the bit stream. This way timing information is not obtained and no guarantee can be given on any design made with this data set.

For the Anlogic FPGA's the actual databases used by the manufacturer tools are decrypted and studied, but interpreting that data is also not as straight forward as one might think. It does provide timing information though and could allow for better output. But it is all based on labour of love from mostly a single person per FPGA manufacturer.

To make it work for your current target, the Xilinx Spartan 3 series you would also have to reverse engineer the Spartan 3 database and create data sets that can be used by yosys and the place and route tools. Which I think will be a hell of a job to get it right. Could be fun though if something like that tickles your interest.

[DiTBho]

I had done some tests with it (using VHDL and the corresponding GHDL plugin) a while back, targetting a Lattice ECP5.

Which target board?

[DiTBho]

What is not mentioned here is that all the FPGA manufacturers keep the inside information close to their chests. This means that all the needed FPGA data to create a bit stream is obtained by reverse engineering, which allows room for lots of errors and uncertainties, depending on how and who did the reverse engineering.

Eh, this leads me to consider only some targets/vendors, only those(1) that have the greatest interest, enough to have a small group of hackers who do reverse engineering and testing.

Means forget Xilinx Spartan3, I guess =''''''(

After all, supporting HPPA is already too burdensome in terms of man-hours that I have to dedicate to both the Linux Kernel and Gentoo/HPPA, I just don't have the time and the skills to start reverse engineering FPGA bitstream.


(1) only a few Lattice' devices, I think

[DiTBho]

the Fmax was announced to be about 50 MHz with that design

How did you get this information with YoSys?
It is particularly one of the things that interests me.
In the last VDU project I'd like to complete
I would not want to go below 50Mhz
(I need 50Mhz pixel clock)

[DiTBho]

The Yosys toolchain is used commercially by some of the newer FPGA vendors themselves.
So it's probably considered stable enough.

This looks a very good idea 

I mean, assuming that this is exactly the case rather than a soft commercial-move
to exploit open source to advertise for free targets that ...
... otherwise would not attract any audience

I would say that it could be a good idea to only consider targets
for which YoSys has commercial support for the discussion above:

if someone offers support,
-> it means that they have at least tested it
--> that is, that they have done the work that otherwise I would have to do

excellent 

and I would be fine with one of these FPGAs
if and only if that have these things

• bitstream in ram, and not in flash
• at least 500K LU, and at least 8Kbyte of bram/dual port
  i.e. the resources of a Spartan3-500
• TQFP package, and not BGA
• LVDS i/o and lvTTL i/o

[DiTBho]

GHDL plugin

I saw that the new experimental versions of YoSys allow to compile the GHDL plug-in
It seems there are at least two ways to integrate it:
A) compiling GHDL as built-in (static)
B) compiling GHDL as dynamic library

On Gentoo HPPA there are obviously problems here and there
and being it a rolling distro where ...
the more dependents you have, the easier it is for something to break
... I would tend to prefer a monolithic approach
even if I saw in the notes that it is "not recommended" by the authors.

Which of the two { A, B } have you used successfully? 

[pcprogrammer]

The Yosys toolchain is used commercially by some of the newer FPGA vendors themselves.
So it's probably considered stable enough.

This looks a very good idea 

I mean, assuming that this is exactly the case rather than a soft commercial-move
to exploit open source to advertise for free targets that ...
... otherwise would not attract any audience

It depends on how they implement the place and route part. For what I understand of yosys is that the base part is mainly for converting the high level HDL in to "gate level" HDL to prepare it for the place and route tool. This translation part uses specific macros to describe the low level parts of the FPGA. It is the place and route tool that takes care of placing these macros in the FPGA and fix the routings in such away that the timing constraints are met. (If possible)

This is based on how it was when I did the reverse engineering of the Anlogic one, so over two years ago. The yosys part was used with the Anlogic "database" and to place and route the design the vendor tools were used. Have not looked at the current status of it all.

So if the place and route software is still vendor proprietary it won't be of any use to you.

At the time they were busy looking into Xilinx 7 series FPGA's, so maybe you could use one of those. There is (was) also work done on some Gowin FPGA's.

[DiTBho]

the choice is then narrowed down to
some FPGAs from  { Lattice, Gowin }

[glenenglish]

How about Gatemate?

[DiTBho]

How about Gatemate?

never heard about