YoSys: status? - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: August 29, 2024, 07:47:16 pm
content: There is a 2-years old article onReddit, 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 knowI 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 forLattice ICE40, while I am more inclined to useXilinx { 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 toXilinx ISE-v10on 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.

author: DiTBho
author_rank: Super Contributor
timestamp: August 29, 2024, 07:49:35 pm
content: ghdl-yosys-plugin, seeherenot yet tried.plus, first I need to upgrade GNAT(which is not an easy task for HPPAanyway, I will first try it on x86)

author: iMo
author_rank: Super Contributor
timestamp: August 29, 2024, 09:04:30 pm
content: 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-15kBAlso 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-experimentsThe 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).

author: dolbeau
author_rank: Regular Contributor
timestamp: August 30, 2024, 06:16:21 am
content: 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".

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 30, 2024, 07:29:11 am
content: Quote from: DiTBho on August 29, 2024, 07:47:16 pm... 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 atyosyshq.net/yosys(but see alsoyosyshq.com/open-source), and the sources atgithub.com/YosysHQ/yosys. The latter has a large number of pending issues and pending pull requests, but thecommit logshows regular activity withreleasescoming out.

author: nctnico
author_rank: Super Contributor
timestamp: August 30, 2024, 08:47:04 am
content: 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 30, 2024, 09:15:47 am
content: 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 yourproductivity, 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.

author: DiTBho
author_rank: Super Contributor
timestamp: August 30, 2024, 09:21:52 am
content: Quote from: nctnico on August 30, 2024, 08:47:04 amThat'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.

author: DiTBho
author_rank: Super Contributor
timestamp: August 30, 2024, 09:31:23 am
content: Quote from: Nominal Animal on August 30, 2024, 09:15:47 amThe 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

author: nctnico
author_rank: Super Contributor
timestamp: August 30, 2024, 08:55:06 pm
content: Quote from: DiTBho on August 30, 2024, 09:31:23 amI 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.

author: DiTBho
author_rank: Super Contributor
timestamp: August 30, 2024, 09:59:16 pm
content: 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.Quote from: nctnico on August 30, 2024, 08:55:06 pmPA-8700 CPU @ 875Mhz, released in 2001PA-8900 CPUs @ 1100Mhz, released in 2005It 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

author: asmi
author_rank: Super Contributor
timestamp: August 31, 2024, 03:34:40 am
content: 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.

author: DiTBho
author_rank: Super Contributor
timestamp: August 31, 2024, 07:26:34 am
content: Quote from: asmi on August 31, 2024, 03:34:40 amFor 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 existThink 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

author: DiTBho
author_rank: Super Contributor
timestamp: August 31, 2024, 07:40:22 am
content: Quote from: asmi on August 31, 2024, 03:34:40 amThis is exactly one of the doubts I had: how much can I trust the results ofYoSys&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 thePapilio/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 byYoSys&its friends

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 01, 2024, 03:16:07 am
content: 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.

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 01, 2024, 06:55:01 am
content: 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.

author: DiTBho
author_rank: Super Contributor
timestamp: September 01, 2024, 12:43:58 pm
content: Quote from: SiliconWizard on September 01, 2024, 03:16:07 amWhich target board?

author: DiTBho
author_rank: Super Contributor
timestamp: September 01, 2024, 12:55:24 pm
content: Quote from: pcprogrammer on September 01, 2024, 06:55:01 amEh, 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

author: DiTBho
author_rank: Super Contributor
timestamp: September 01, 2024, 01:03:11 pm
content: Quote from: SiliconWizard on September 01, 2024, 03:16:07 amHow 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 completeI would not want to go below 50Mhz(I need 50Mhz pixel clock)

author: DiTBho
author_rank: Super Contributor
timestamp: September 01, 2024, 01:11:10 pm
content: Quote from: SiliconWizard on September 01, 2024, 03:16:07 amThis looks a very good ideaI mean, assuming that this is exactly the case rather than a soft commercial-moveto exploit open source to advertise for free targets that ...... otherwise would not attract any audienceI would say that it could be a good idea to only consider targetsfor 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 doexcellentand I would be fine with one of these FPGAsif and only if that have these thingsbitstream in ram, and not in flashat least 500K LU, and at least 8Kbyte of bram/dual porti.e. the resources of a Spartan3-500TQFP package, and not BGALVDS i/o and lvTTL i/o

author: DiTBho
author_rank: Super Contributor
timestamp: September 01, 2024, 01:29:10 pm
content: Quote from: SiliconWizard on September 01, 2024, 03:16:07 amI saw that the new experimental versions of YoSys allow to compile the GHDL plug-inIt seems there are at least two ways to integrate it:A) compiling GHDL as built-in (static)B) compiling GHDL as dynamic libraryOn Gentoo HPPA there are obviously problems here and thereand 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 approacheven if I saw in the notes that it is "not recommended" by the authors.Which of the two { A, B } have you used successfully?

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 01, 2024, 02:15:09 pm
content: Quote from: DiTBho on September 01, 2024, 01:11:10 pmIt 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.

author: DiTBho
author_rank: Super Contributor
timestamp: September 01, 2024, 03:12:28 pm
content: the choice is then narrowed down tosome FPGAs from { Lattice, Gowin }

author: glenenglish
author_rank: Frequent Contributor
timestamp: September 02, 2024, 04:00:47 am
content: How about Gatemate?

author: DiTBho
author_rank: Super Contributor
timestamp: September 02, 2024, 09:17:36 am
content: Quote from: glenenglish on September 02, 2024, 04:00:47 amnever heard about

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 02, 2024, 09:55:59 am
content: Olimex has two variants ofOSHW GateMate development boardfor about 50€ (+VAT and shipping). It uses yosys for synthesis; see thetoolchain installation guide.

author: nctnico
author_rank: Super Contributor
timestamp: September 02, 2024, 09:56:39 am
content: Quote from: DiTBho on September 02, 2024, 09:17:36 amThose are designed by Cologne Chip, they have been around for decades. A small company and Yosys has enabled them to get into the FPGA market without needing to spend lots of money on tool development.

author: laugensalm
author_rank: Regular Contributor
timestamp: September 02, 2024, 09:59:29 am
content: Hi,I'm using yosys on a daily basis, actually. There are architectures that work well, some less optimal, and the memory handling with respect to efficient dual port ram was, to address it neutrally, suboptimal, so I've had to mostly hack my own memory inference rules. However, since TDP is working somewhat ok in upstream, you can actually get a full SoC running on Lattice ECP5 using the ghdl synthesis plugin. You might find relicts here:https://github.com/hackfin/hdlplayground, but it's no longer maintained.There's just a few important things to keep in mind: ghdlsynth won't just eat any VHDL like for instance the Synopsys tools, so you don't normally get to easily port an existing project, or you might end up with rewriting some modules in Verilog.Then: No timing optimization will be done for you on the mapping stage. You'll have to know details about your architecture and write your code accordingly, but this is not an entirely new phenomenon, if you have been porting clock optimized designs among various architectures. Dealing with f_max / 2 is a safe assumption.On the other hand, you have a good guarantee that you can port a GHDL-understood design easily to the $-Tools.Unfortunately, you don't get fine grained control over the synthesis via the V* languages, there's a way out via direct synthesis (cyrite HDL to pyosys target), but that's again not trivial.And last but not least, you might be left with an urge to do verification at the early mapping stage, but this turned out to be not such a bad idea anyhow, due to yosys' volatile behaviour once in a while.The other issues is with architectures that are reverse engineered. Some results simply can not be published unless one wants to trigger anal behaviour of lawyers claiming violated trade secrets. So some architectures will just be left orphaned in one or the other way...The closest to productive fun is probably Lattice ECP5, unless you're going to do heavy video I/O like HDMI, there you'll need the Diamond $-ware. Gatemate was also promising, but I've only verified it 'dry dock'.

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 02, 2024, 10:12:06 am
content: Quote from: Nominal Animal on September 02, 2024, 09:55:59 amThe way I interpret the chart on page 5 is that the place and route is done with GateMate proprietary software, so porting to another platform won't be possible.

author: DiTBho
author_rank: Super Contributor
timestamp: September 02, 2024, 10:57:47 am
content: Quote from: laugensalm on September 02, 2024, 09:59:29 amThis is the reason for my previous comment about using an existing project (I mentioned GameDuino-v1) to "test" the tool.Because it is also valid with Xilinx/ISEi.e., not necessary but sufficient condition if GHDL does not emit errors or warnings, then it is also synthesized on ISEUnfortunately, the opposite is not true either, and this is clearly visible when taking projects from OpenCore(1)ISE completes the synthesis, while GHDL crashes with errors, or in any case emits rather worrying warnings.I compared GHDL compiled on HPPA (experimental), with GHDL compiled on x86 (mainstream).Same results. At first I thought it was a bug with GNU/Linux HPPA,which is often the real reason why things don't work as they should.(1) OpenCores does not have typical well-written projects

author: DiTBho
author_rank: Super Contributor
timestamp: September 02, 2024, 11:16:04 am
content: Quote from: laugensalm on September 02, 2024, 09:59:29 amthis is a big problem to support two of the hobby projects I would like to completeVDU, all-in-oneTrMem, all-in-oneBoth are "all-in-one" profiled without any external dual port ram chip.So, the bram is the only RAM resource I have availableand it must be dual-port, two read, one write, for at least 4KbyteISE has some problems when instantiating bram with 8bit databus for Spartan3e.g. your CPU is 32bit, so you are tempted to describe the resource as 4x8bitwith four byte_enable control bits in the load/store stage.supportingload{8,16,32}bit <-- { byte3_en,byte2_en,byte1_en,byte0_en }(size)={ (0,0,0,1), (0,0,1,1), (1,1,1,1) }store{8,16,32}bit <-- { byte3_en,byte2_en,byte1_en,byte0_en }(size)={ (0,0,0,1), (0,0,1,1), (1,1,1,1) }Good idea, from the design point of view, but it's not efficient on synthesisI found it works much better when instantiating bram with 16 databus.This is because physically the SP3 bram resource is made exactly like this: with 16bit databus!* * *In order to make portable projectsI think, at worst I can describe the "dualport-ram" as a generic entityand then write a specific VHDL module for each physical FPGAso, with some tricks for Spartan3, etc...

author: laugensalm
author_rank: Regular Contributor
timestamp: September 02, 2024, 12:12:35 pm
content: I believe I did get some useful result out of more recent yosys releases with the mem_v2 API on the Gatemate primitives from Verilog models, so basically, there are constellations of TDP with the properties you describe that synthesize via yosys above v0.13, if I'm right. I haven't got the entire test suite up to par with the latest releases, but some default ISE-digesteable VHDL RAM descriptions should work as well.The 8 bit issues with Spartan3 and 6 are rather due to the 'broken' architecture than the tools, I'd say.

author: zapta
author_rank: Super Contributor
timestamp: September 04, 2024, 01:03:38 am
content: Working on my first FPGA project and am having very good experience with Apio. It's a platformio like command line wrapper around the open source tool chain, including yosys, which provides comprehensive and intuitive commands and easy installation.Here is the top level usage infoCode:$ apioUsage: apio  COMMAND ...Work with FPGAs with ease. For more information seehttps://github.com/FPGAwars/apio/wiki/ApioOptions:--version Show the version and exit.-h, --help Show this message and exit.Project commands:build Synthesize the bitstream.clean Clean the previous generated files.graph Generate a a visual graph of the verilog code.lint Lint the verilog code.sim Simulate a single module.test Test all or a single verilog testbench module.time Analyze and design and report timing.upload Upload the bitstream to the FPGA.verify Verify project's verilog code.Setup commands:drivers Manage FPGA boards drivers.init Manage apio projects.install Install apio packages.uninstall Uninstall packages.Utility commands:boards Manage FPGA boards.config Apio configuration.examples Manage verilog examples.raw Execute commands directly from the Apio packagessystem System tools.upgrade Check the latest Apio version.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 04, 2024, 03:11:55 am
content: Quote from: DiTBho on September 01, 2024, 12:43:58 pmNot that the board really matters here, but possibly you're looking for dev boards too.I used this kind of boards back then:https://www.aliexpress.com/item/1005006834979763.html(I have one with a -25 and a couple with a -45).The boards have 8 MB SDRAM, which isn't a lot and not ultra fast, but is relatively easy to control (compared to DDR RAM).

author: DiTBho
author_rank: Super Contributor
timestamp: September 04, 2024, 04:11:38 am
content: Quote from: SiliconWizard on September 04, 2024, 03:11:55 amIt's the most important question instead.I need a reliable eval board.With experimental tools like YoSys&C, it's not good idea playing with random hw.

author: laugensalm
author_rank: Regular Contributor
timestamp: September 04, 2024, 07:56:29 am
content: WRT boards, I've got these spinning without hassle:* LF-EVDK1-EVN* LFE5UM5G-45F-VERSA-EVNGPrice tag is somewhat higher, esp. since you need to get another board for the EVDK to have Ethernet. But what you get is a pretty cool stereo cam...Then there appeared to be a community board called ULX3S, which may get you started faster with open source stuff, but wasn't for me, due to the lack of 1G networking.

author: zapta
author_rank: Super Contributor
timestamp: September 07, 2024, 04:23:10 am
content: Quote from: DiTBho on September 04, 2024, 04:11:38 amThese are the boards that are supported by apio out of the box. I am using upduino31, its an inexpensive small DIP module that fits in a solderless board.Code:$ apio boards -l────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────Board (FPGA, Arch, Type, Size, Pack)────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────• Alchitry-Cu (FPGA:iCE40-HX8K-CB132, ice40, hx, 8k, cb132)• Butterstick-r10-2g-85k (FPGA:ECP5-LFE5UM5G-85F-CABGA381, ecp5, um5g-85k, 85k, CABGA381)• Butterstick-r10-2g-85k_(FT2232H) (FPGA:ECP5-LFE5UM5G-85F-CABGA381, ecp5, um5g-85k, 85k, CABGA381)• Butterstick-r10-2g-85k_(FT232H) (FPGA:ECP5-LFE5UM5G-85F-CABGA381, ecp5, um5g-85k, 85k, CABGA381)• Cat-board (FPGA:iCE40-HX8K-CT256, ice40, hx, 8k, ct256)• ColorLight-5A-75B-V61 (FPGA:ECP5-LFE5U-25F-CABGA381, ecp5, 25k, 25k, CABGA381)• ColorLight-5A-75B-V7 (FPGA:ECP5-LFE5U-25F-CABGA256, ecp5, 25k, 25k, CABGA256)• ColorLight-5A-75B-V8 (FPGA:ECP5-LFE5U-25F-CABGA256, ecp5, 25k, 25k, CABGA256)• ColorLight-5A-75E-V6 (FPGA:ECP5-LFE5U-25F-CABGA256, ecp5, 25k, 25k, CABGA256)• ColorLight-5A-75E-V71_(FT2232H) (FPGA:ECP5-LFE5U-25F-CABGA256, ecp5, 25k, 25k, CABGA256)• ColorLight-5A-75E-V71_(FT232H) (FPGA:ECP5-LFE5U-25F-CABGA256, ecp5, 25k, 25k, CABGA256)• ColorLight-5A-75E-V71_(USB-Blaster) (FPGA:ECP5-LFE5U-25F-CABGA256, ecp5, 25k, 25k, CABGA256)• ColorLight-i5-v7.0_(FT2232H) (FPGA:ECP5-LFE5U-25F-CABGA381, ecp5, 25k, 25k, CABGA381)• ColorLight-i5-v7.0_(FT232H) (FPGA:ECP5-LFE5U-25F-CABGA381, ecp5, 25k, 25k, CABGA381)• ColorLight-i5-v7.0_(USB-Blaster) (FPGA:ECP5-LFE5U-25F-CABGA381, ecp5, 25k, 25k, CABGA381)• ColorLight-i9-v7.2_(FT2232H) (FPGA:ECP5-LFE5U-45F-CABGA381, ecp5, 45k, 45k, CABGA381)• ColorLight-i9-v7.2_(FT232H) (FPGA:ECP5-LFE5U-45F-CABGA381, ecp5, 45k, 45k, CABGA381)• ColorLight-i9-v7.2_(USB-Blaster) (FPGA:ECP5-LFE5U-45F-CABGA381, ecp5, 45k, 45k, CABGA381)• ECP5-Evaluation-Board (FPGA:ECP5-LFE5UM5G-85F-CABGA381, ecp5, um5g-85k, 85k, CABGA381)• ECP5-Mini-12 (FPGA:ECP5-LFE5U-12F-CABGA256, ecp5, 12k, 12k, CABGA256)• ECP5-Mini-25 (FPGA:ECP5-LFE5U-25F-CABGA256, ecp5, 25k, 25k, CABGA256)• FleaFPGA-Ohm_(FT2232H) (FPGA:ECP5-LFE5U-25F-CABGA381, ecp5, 25k, 25k, CABGA381)• FleaFPGA-Ohm_(FT232H) (FPGA:ECP5-LFE5U-25F-CABGA381, ecp5, 25k, 25k, CABGA381)• FleaFPGA-Ohm_(USB-Blaster) (FPGA:ECP5-LFE5U-25F-CABGA381, ecp5, 25k, 25k, CABGA381)• ODT_IcyBlue_Feather (FPGA:iCE40-U4K-SG48, ice40, u, 4k, sg48)• ODT_RPGA_Feather (FPGA:iCE40-U4K-SG48, ice40, u, 4k, sg48)• OK-iCE40Pro (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• Sipeed-Tang-Nano-20k (FPGA:GW2AR-LV18QN88C8/I7, gowin, gw2a-18c, 20k, QN88)• ThetaMachines-ETH4K (FPGA:iCE40-HX4K-TQ144, ice40, hx, 8k, tq144:4k)• TinyFPGA-B2 (FPGA:iCE40-LP8K-CM81, ice40, lp, 8k, cm81)• TinyFPGA-BX (FPGA:iCE40-LP8K-CM81, ice40, lp, 8k, cm81)• TinyFPGA-EX-rev1 (FPGA:ECP5-LFE5U-85F-CSFBGA285, ecp5, 85k, 85k, CSFBGA285)• TinyFPGA-EX-rev2 (FPGA:ECP5-LFE5UM5G-85F-CSFBGA285, ecp5, um5g-85k, 85k, CSFBGA285)• alhambra-ii (FPGA:iCE40-HX4K-TQ144, ice40, hx, 8k, tq144:4k)• arice1 (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• blackice (FPGA:iCE40-HX4K-TQ144, ice40, hx, 8k, tq144:4k)• blackice-ii (FPGA:iCE40-HX4K-TQ144, ice40, hx, 8k, tq144:4k)• blackice-mx (FPGA:iCE40-HX4K-TQ144, ice40, hx, 8k, tq144:4k)• edu-ciaa-fpga (FPGA:iCE40-HX4K-TQ144, ice40, hx, 8k, tq144:4k)• fomu (FPGA:iCE40-UP5K-UWG30, ice40, up, 5k, uwg30)• fpga101 (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• go-board (FPGA:iCE40-HX1K-VQ100, ice40, hx, 1k, vq100)• iCE40-HX1K-EVB (FPGA:iCE40-HX1K-VQ100, ice40, hx, 1k, vq100)• iCE40-HX8K (FPGA:iCE40-HX8K-CT256, ice40, hx, 8k, ct256)• iCE40-HX8K-EVB (FPGA:iCE40-HX8K-CT256, ice40, hx, 8k, ct256)• iCE40-UL1K-Breakout (FPGA:iCE40-UL1K-CM36A, ice40, ul, 1k, cm36a)• iCE40-UP5K (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• iCEBreaker (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• iCEBreaker-bitsy0 (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• iCEBreaker-bitsy1 (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• iCESugar-Pro_(FT2232H) (FPGA:ECP5-LFE5U-25F-CABGA256, ecp5, 25k, 25k, CABGA256)• iCESugar-Pro_(FT232H) (FPGA:ECP5-LFE5U-25F-CABGA256, ecp5, 25k, 25k, CABGA256)• iCESugar-Pro_(USB-Blaster) (FPGA:ECP5-LFE5U-25F-CABGA256, ecp5, 25k, 25k, CABGA256)• iCESugar-nano (FPGA:iCE40-LP1K-CM36, ice40, lp, 1k, cm36)• iCESugar_1_5 (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• iceWerx (FPGA:iCE40-HX8K-CB132, ice40, hx, 8k, cb132)• iceblink40-hx1k (FPGA:iCE40-HX1K-VQ100, ice40, hx, 1k, vq100)• icefun (FPGA:iCE40-HX8K-CB132, ice40, hx, 8k, cb132)• icestick (FPGA:iCE40-HX1K-TQ144, ice40, hx, 1k, tq144)• icezum (FPGA:iCE40-HX1K-TQ144, ice40, hx, 1k, tq144)• icoboard (FPGA:iCE40-HX8K-CT256, ice40, hx, 8k, ct256)• kefir (FPGA:iCE40-HX4K-TQ144, ice40, hx, 8k, tq144:4k)• orangecrab-r02-25f (FPGA:ECP5-LFE5U-25F-CSFBGA285, ecp5, 25k, 25k, CSFBGA285)• orangecrab-r02-85f (FPGA:ECP5-LFE5U-85F-CSFBGA285, ecp5, 85k, 85k, CSFBGA285)• pico-ice (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• ulx3s-12f (FPGA:ECP5-LFE5U-12F-CABGA381, ecp5, 12k, 12k, CABGA381)• ulx3s-25f (FPGA:ECP5-LFE5U-25F-CABGA381, ecp5, 25k, 25k, CABGA381)• ulx3s-45f (FPGA:ECP5-LFE5U-45F-CABGA381, ecp5, 45k, 45k, CABGA381)• ulx3s-85f (FPGA:ECP5-LFE5U-85F-CABGA381, ecp5, 85k, 85k, CABGA381)• upduino (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• upduino2 (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• upduino21 (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• upduino3 (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• upduino31 (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)• versa (FPGA:ECP5-LFE5UM-45F-CABGA381, ecp5, um-45k, 45k, CABGA381)────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────Total: 75 boardsAnd these are the supported FPGAs, in case you want to use a custom board. I designed a custom board that is based on the upduino31 that is optimized for fast data USB data link (FT2232, 8 bit FIFO mode) and am using a custom board definition.Code:apio boards --fpga────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────FPGA Arch Type Size Pack────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────• ECP5-LFE5U-12F-CABGA256 ecp5 12k 12k CABGA256• ECP5-LFE5U-12F-CABGA381 ecp5 12k 12k CABGA381• ECP5-LFE5U-12F-CSFBGA285 ecp5 12k 12k CSFBGA285• ECP5-LFE5U-25F-CABGA256 ecp5 25k 25k CABGA256• ECP5-LFE5U-25F-CABGA381 ecp5 25k 25k CABGA381• ECP5-LFE5U-25F-CSFBGA285 ecp5 25k 25k CSFBGA285• ECP5-LFE5U-45F-CABGA256 ecp5 45k 45k CABGA256• ECP5-LFE5U-45F-CABGA381 ecp5 45k 45k CABGA381• ECP5-LFE5U-45F-CABGA554 ecp5 45k 45k CABGA554• ECP5-LFE5U-45F-CSFBGA285 ecp5 45k 45k CSFBGA285• ECP5-LFE5U-85F-CABGA381 ecp5 85k 85k CABGA381• ECP5-LFE5U-85F-CABGA554 ecp5 85k 85k CABGA554• ECP5-LFE5U-85F-CABGA756 ecp5 85k 85k CABGA756• ECP5-LFE5U-85F-CSFBGA285 ecp5 85k 85k CSFBGA285• ECP5-LFE5UM-25F-CABGA256 ecp5 um-25k 25k CABGA256• ECP5-LFE5UM-25F-CABGA381 ecp5 um-25k 25k CABGA381• ECP5-LFE5UM-25F-CSFBGA285 ecp5 um-25k 25k CSFBGA285• ECP5-LFE5UM-45F-CABGA256 ecp5 um-45k 45k CABGA256• ECP5-LFE5UM-45F-CABGA381 ecp5 um-45k 45k CABGA381• ECP5-LFE5UM-45F-CABGA554 ecp5 um-45k 45k CABGA554• ECP5-LFE5UM-45F-CSFBGA285 ecp5 um-45k 45k CSFBGA285• ECP5-LFE5UM-85F-CABGA381 ecp5 um-85k 85k CABGA381• ECP5-LFE5UM-85F-CABGA554 ecp5 um-85k 85k CABGA554• ECP5-LFE5UM-85F-CABGA756 ecp5 um-85k 85k CABGA756• ECP5-LFE5UM-85F-CSFBGA285 ecp5 um-85k 85k CSFBGA285• ECP5-LFE5UM5G-25F-CABGA256 ecp5 um5g-25k 25k CABGA256• ECP5-LFE5UM5G-25F-CABGA381 ecp5 um5g-25k 25k CABGA381• ECP5-LFE5UM5G-25F-CSFBGA285 ecp5 um5g-25k 25k CSFBGA285• ECP5-LFE5UM5G-45F-CABGA256 ecp5 um5g-45k 45k CABGA256• ECP5-LFE5UM5G-45F-CABGA381 ecp5 um5g-45k 45k CABGA381• ECP5-LFE5UM5G-45F-CABGA554 ecp5 um5g-45k 45k CABGA554• ECP5-LFE5UM5G-45F-CSFBGA285 ecp5 um5g-45k 45k CSFBGA285• ECP5-LFE5UM5G-85F-CABGA381 ecp5 um5g-85k 85k CABGA381• ECP5-LFE5UM5G-85F-CABGA554 ecp5 um5g-85k 85k CABGA554• ECP5-LFE5UM5G-85F-CABGA756 ecp5 um5g-85k 85k CABGA756• ECP5-LFE5UM5G-85F-CSFBGA285 ecp5 um5g-85k 85k CSFBGA285• GW2AR-LV18QN88C8/I7 gowin gw2a-18c 20k QN88• iCE40-HX1K-CB132 ice40 hx 1k cb132• iCE40-HX1K-TQ144 ice40 hx 1k tq144• iCE40-HX1K-VQ100 ice40 hx 1k vq100• iCE40-HX4K-BG121 ice40 hx 8k bg121:4k• iCE40-HX4K-CB132 ice40 hx 8k cb132:4k• iCE40-HX4K-TQ144 ice40 hx 8k tq144:4k• iCE40-HX8K-BG121 ice40 hx 8k bg121• iCE40-HX8K-CB132 ice40 hx 8k cb132• iCE40-HX8K-CM225 ice40 hx 8k cm225• iCE40-HX8K-CT256 ice40 hx 8k ct256• iCE40-LP1K-CB121 ice40 lp 1k cb121• iCE40-LP1K-CB81 ice40 lp 1k cb81• iCE40-LP1K-CM121 ice40 lp 1k cm121• iCE40-LP1K-CM36 ice40 lp 1k cm36• iCE40-LP1K-CM49 ice40 lp 1k cm49• iCE40-LP1K-CM81 ice40 lp 1k cm81• iCE40-LP1K-QN84 ice40 lp 1k qn84• iCE40-LP1K-SWG16TR ice40 lp 1k swg16tr• iCE40-LP384-CM36 ice40 lp 384 cm36• iCE40-LP384-CM49 ice40 lp 384 cm49• iCE40-LP384-QN32 ice40 lp 384 qn32• iCE40-LP4K-CM121 ice40 lp 8k cm121:4k• iCE40-LP4K-CM225 ice40 lp 8k cm225:4k• iCE40-LP4K-CM81 ice40 lp 8k cm81:4k• iCE40-LP8K-CM121 ice40 lp 8k cm121• iCE40-LP8K-CM225 ice40 lp 8k cm225• iCE40-LP8K-CM81 ice40 lp 8k cm81• iCE40-U4K-SG48 ice40 u 4k sg48• iCE40-U4K-UWG30 ice40 u 4k uwg30• iCE40-UL1K-CM36A ice40 ul 1k cm36a• iCE40-UP5K-SG48 ice40 up 5k sg48• iCE40-UP5K-UWG30 ice40 up 5k uwg30────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────Total: 69 fpgas

author: DiTBho
author_rank: Super Contributor
timestamp: September 09, 2024, 06:21:47 am
content: The pipeline employs the following tools:YoSys- logic synthesis of { Verilog code, VHDL(via GHDL-plug-in), ... }-> the output is a netlist describing how all cells are connected together in BLIF formatArachne-pnr- placement and routing of the netlist.-> the output is a textual bitstreamfpga-IceStorm- preparing the bitstream for the Lattice'FPGA-> the output is a binary bitstreamA few lines in its repo say that "Arachne-pnr" is not maintained anymore, and suggest to use "nextpnr" instead, which should be a complete functional replacement, 5x faster and with major improvementsShould I follow this advice?

author: DiTBho
author_rank: Super Contributor
timestamp: September 09, 2024, 06:29:35 am
content: Meanwhile, only to develop my Gentoo Overlay and test YoSys&C on HPPA GNU/Linux, I boughtthisboard.upduino-v3.1, Lattice ICE40, ~30 euroI will not make any other use of it, except to test the tools directly on the workstation.

author: zapta
author_rank: Super Contributor
timestamp: September 09, 2024, 06:50:39 am
content: Quote from: DiTBho on September 09, 2024, 06:21:47 amThis is what happens when I run 'apio build'. Never seen or used Arachne-pnr.```yosys -p "synth_ice40 -top main -json hardware.json" -q ftdi_tx.v i2s_rx.v i2s_test_pattern.v i2s_timing.v lcd_i2c.v lcd_i2c_io.v leds.v main.v queue.v queue_pusher.v register.v reset_gen.vnextpnr-ice40 --up5k --package sg48 --json hardware.json --asc hardware.asc --pcf main.pcf -qicepack hardware.asc hardware.bin```

author: djsb
author_rank: Super Contributor
timestamp: September 09, 2024, 09:56:12 am
content: Zapta,Would the PICO-ICE from the same company as the upduino 3.1 work just as well?https://tinyvision.ai/products/pico-ice?pr_prod_strat=jac&pr_rec_id=3d4c2476b&pr_rec_pid=6766758821991&pr_ref_pid=4634414547047&pr_seq=uniformI have IceStudio 0.12 installed. UPDuino 3.1 and PICO-ICE are listed as being supported. Thanks.

author: zapta
author_rank: Super Contributor
timestamp: September 09, 2024, 01:11:47 pm
content: Quote from: djsb on September 09, 2024, 09:56:12 am@djsb, I see it in the apio list so should work but never tried it.```$ apio boards -l | grep -i pico• pico-ice (FPGA:iCE40-UP5K-SG48, ice40, up, 5k, sg48)```Personally I prefer the upduino because it's simpler an I can plug it into a solderless breadboard.BTW, icestudio and apio are from the same open source group FPGAwars, and icestudio (graphical, schematic oriented) uses apio internally (command line, text oriented). For curiosity, try typing the system commandapioto see if it's on your path.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 09, 2024, 09:36:30 pm
content: I have an Upduino 2.0 board and two Upduino 3.1. I have only used Lattice Radiant with them though and not Yosys/nextpnr, which I've only tested on the ECP5.But for "flashing" the Upduino boards, I use iceprog, which is part of icestorm:https://github.com/YosysHQ/icestorm/tree/master/iceprog

author: zapta
author_rank: Super Contributor
timestamp: September 09, 2024, 10:54:36 pm
content: Apio and icestudio also use the included iceprog to progoram the upduinos which are FTDI based.https://github.com/FPGAwars/apio/blob/cb991fe1ff69bc9ba651c0aff1d806c278bef3b5/apio/resources/boards.json#L224The ice pico however uses an RP2040 instead of a FTDI chip and is programed using a DFU utility.https://github.com/FPGAwars/apio/blob/cb991fe1ff69bc9ba651c0aff1d806c278bef3b5/apio/resources/boards.json#L602

author: cfbsoftware
author_rank: Regular Contributor
timestamp: September 09, 2025, 12:15:39 am
content: Quote from: pcprogrammer on September 02, 2024, 10:12:06 amFYI Yosys is adding support for GateMate:https://github.com/YosysHQ/nextpnr/releasesand CologneChip is now stating (my italics):Quotehttps://www.colognechip.com/programmable-logic/gatemate/#tab-313424However, this has not yet been reflected in the chart you referred to, the latest version of which is dated March 2025.