YosysHQ

yosys

C++2015–2025

YosysHQ / yosys

yosys

Yosys Open SYnthesis Suite

Explore on GitHub Read Hacker News discussions

9Distinct people

10Mentions

0Explicit recommenders

4.9KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Yosys Open SYnthesis Suite

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year10 dated mentions

Observed mentions: 2015-04-16 22:04:15 UTC to 2025-09-29 11:57:36 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	2	2
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	0	0
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	2	2
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	2	2
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	1
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	2	2
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	1

What Hacker News says

10 sources

IshKebab·Sep 29, 2025

When I looked into Yosys it very much seemed like a tool from the 80s that you pretty much had to be a Yosys developer to use. It still uses TCL scripting (which I know is standard in EDA but it shouldn't be). https://github.com/YosysHQ/yosys?tab=readme-ov-file#getting-... I wish we had a modern easy-to-use solution.

In Zero ASIC releases Wildebeest, the highest performance FPGA synthesis tool

fargle·Sep 7, 2024

yosys [1] is the the open-source synthesis tool and also supports formal verification and other analysis. however, it's Verilog front-end is basically Verilog-2005 with a hodge-podge of newer features added on but it is unfortunately very buggy and incomplete. Mike Poploski's slang [2] is an absolutely top-notch System Verilog parser and elaborator that already supports nearly all System-Verilog 2023 features already. why not adapt the slang front-end to yosys so we can have a proper modern System Verilog HDL entry with yosys's excellent synthesis and analysis engines? Martin Povišer just did it! Thank you Martin. [1] https://github.com/YosysHQ/yosys [2] https://github.com/MikePopoloski/slang

In Yosys and slang: A match made in heaven

retrac·Apr 23, 2024

Iverilog is a Verilog simulator. [1] Yosys [2] can synthesize Verilog to a variety of things, including simplified Verilog, cell netlists for ASICs and FPGAs (requiring further conversion), and also directly to the bytestream, for some Lattice FPGAs. Both are fully open source tools. Not as sophisticated as the commercial tools, and the Verilog dialect that is common between the two, is quite minimal, almost painfully so. But it works! A couple years ago I tested yosys with some code a little simpler than yours - a Verilog PDP-8 processor. Yosys turned it into a network of about 100 flip-flops and 800 NAND gates that, in principle, could be wired up out of TTL chips or made into an IC. [1] https://github.com/steveicarus/iverilog [2] https://github.com/YosysHQ/yosys

In OpenCores: A-Z80 CPU

mathisfun123·Sep 27, 2023

> Reading your answers, I've noticed that there appear to be some major misconceptions about Yosys and how it works Indeed I opted to go with vivado instead of yosys (so i'm not an expert) but you're being a little disingenuous; there are absolutely places where yosys is explicitly, manifestly, being used as a scripting harness - you literally have ScriptPass https://github.com/YosysHQ/yosys/blob/076c5ceb714bc8f20136a8... and it is indeed used extensively for all of the flows: https://github.com/search?q=repo%3AYosysHQ%2Fyosys%20ScriptP... and so in particular, wanting to do synthesis for Xilinx, I was stuck basically commenting various lines in SynthXilinxPass::script https://github.com/YosysHQ/yosys/blob/076c5ceb714bc8f20136a8... to experiment with various flows. Now maybe you have/had a better way to do this but I couldn't find it.

In Verilog to Routing

pdq·Aug 4, 2021

Nice project. FYI, this is using the Yosys Verilog synthesizer for the real magic. https://github.com/YosysHQ/yosys

In Verilog2Factorio: Web Demo

ohazi·Jan 3, 2021

For decades, the FPGA vendors have had this fever dream of "an FPGA in every PC" -- either as an add-on card, or as part of the chipset on a motherboard -- that would enable a compiler or operating system to seamlessly accelerate arbitrary tasks on demand. In my opinion, the problem has always been their software: the FPGA vendor tools are slow, bloated monstrosities. The core of these tools are written by the big three EDA vendors (Cadence, Synopsys, and Mentor Graphics) rather than the FPGA vendors themselves. The licenses include ridiculous, paranoid restrictions [1] and force the FPGA vendors to keep their bitstream formats and timing databases secret [2] in order to prevent competition from other tool vendors. Most FPGA vendors didn't see this as a problem, but even the ones that did didn't have much of a choice, because the tool mar

Read the rest

ket is a cartel. Thankfully, we now have an open source toolchain [3] with support for a growing number of FPGA architectures [4], and using it vs. the vendor tools is like using gcc or llvm vs. a '90s era, non-compliant C++ compiler. It even has a real IR that isn't Verilog, which has made it easier to design new HDLs [5]. I don't see how a dynamic FPGA accelerator platform can be even remotely viable without this. It's the difference between a developer getting to choose between one of a few dozen pre-baked designs that lock up the entire FPGA (and needing to learn how to shovel data into it), vs. a compiler flag that can give you the option of unrolling any loop directly into any inactive region of FPGA fabric. It would be quite the cherry on top to see AMD build something interesting in this space. But unless they're willing to fully unencumber at least this one design, I think the effort is likely to fail. The open source guys are chomping at the bit to make this work, and have been making real progress lately. Meanwhile, the EDA vendors have been making promises, failing, and throwing tantrums for the last 20 years. It's time to write them off. [1] https://twitter.com/OlofKindgren/status/1052822081652617221?... [2] Imagine trying to write an assembler without being allowed to see the manual that tells you how instructions are encoded. It's like that, but the state-space is hundreds to thousands of bytes in multiple configurations rather than a few dozen bits. [3] https://github.com/YosysHQ/yosys [4] https://symbiflow.github.io/ [5] https://github.com/m-labs/nmigen

In AMD Patent Reveals Hybrid CPU-FPGA Design That Could Be Enabled by Xilinx Tech

xvilka·May 22, 2019

Hopefully, it will not only boost RISC-V adoption, but also the FOSS EDA[1][2][3] tools, FPGA[4][5] and ASIC[6][7][8] design tools, various high-level languages, and toolkits to work with hardware designs. You can also follow my idea[9] and initiative to create low-level hardware IR instead of al tools parsing or producing Verilog/VHDL. Apparently, both are a pretty bad fit for chip design, thus many high-level languages[10] were created. [1] KiCAD http://kicad-pcb.org/ [2] Qucs https://github.com/Qucs/qucs [3] gEDA http://www.geda-project.org/ [4] Yosys https://github.com/YosysHQ/yosys [5] SymbiFlow https://symbiflow.github.io [6] The OpenROAD https://theopenroadproject.org [7] The OpenROAD https://github.com/The-OpenROAD-Project [8] Chisel3 https://github.com/freechipsproject/chisel3 [9] https://github.com/SymbiFlow/ideas/issues/19 [10]

Read the rest

https://github.com/drom/awesome-hdl

In ARM memo tells staff to stop working with Huawei

teabee89·Mar 20, 2019

There is a link in https://github.com/YosysHQ/yosys/wiki/VHDL-frontend-efforts

In Show HN: H2 Forth CPU

pdq·Sep 22, 2015

Note this is the same Clifford Wolf who has built a Verilog synthesizer [1] and reverse engineered the Lattice FPGA bitstream format [2]. On a slightly different topic, the RISC-V group has built an impressive Javascript RISC-V emulator that boots Linux in your browser: http://riscv.org/angel/ [1] https://github.com/cliffordwolf/yosys [2] http://www.clifford.at/icestorm/

In PicoRV32 – A Size-Optimized RISC-V CPU

diamondman·Apr 16, 2015

PART 1/3 The lack of open tools is a huge problem. My friends on IRC are working on reverse engineering multiple chips enough that full compilation tool chains can work. My part of the project is working to make a highly generic method of loading the compiled files onto the actual chips no matter the programmer or chip used. I will expand on the steps of compiling for an FPGA, loading a program onto an FPGA, the difficulties we face in making our own tools, and then talk about my project a little (which cgag was kind enough to name drop). As you can see from the post size this will be very long but should be very educational. First thing is there are more parts to the bitstream generation, as well as other tools of the toolchain required after bitstream generation is done. The compilation is split into the following parts. HDL SYNTHESIS H

Read the rest

DLs can work for both ASIC design, FPGA design, and more general work like some mathematical proofs that never intend to run on real hardware. This step takes in a HDL program and calculates all the gates required. The output is called a netlist is more of a mathematical construct of connections over perfect wires (everything is ideal i.e. not realistic). This step should also detect repeated gate mpatterns in the netlist and de-duplicate them (This is crazy important since it can shrink a netlist substantially). Commonly tools that implement this step will produce everything in one gate type (like NAND http://en.wikipedia.org/wiki/NAND_logic). There are two major open source tools: Icarus Verilog (http://iverilog.icarus.com/) used more for the math proofs and simulation but not intended to generate information for real chips. Yosys (https://github.com/cliffordwolf/yosys) A much newer tool that is made to be part of a real life FPGA toolchain once the next tools are available. Only works with Verilog (more popular in industry). TECHNOLOGY MAPPING The link OP posted shows how the FPGA has specialty hardware peppered in with the general gates to speed up certain operations. The link briefly talks about the truth tables in the LUTs which means that each LUT is not really just A gate, they are each a box that can be configured to implement one of many common sequences of gates to save space and speed. Each FPGA can be implemented differently, and since the synthesis step outputs a netlist usually in a specific gate type, the gates of the netlist often do not match the gates that can be efficiently implemented in the LUTs. This tool is the first one that has to have deep knowledge of the FPGA's underlying technology (often called the Fabric) so we can convert the netlist into something that could in theory be put on the target FPGA. Synthesis tools do not implement this step since it is FPGA specific. PLACE AND ROUTE After we generate a netlist of realistic gates we have to find out how to fit them into them onto the physical chip with enough room to connect to each other. This by itself is a VERY hard problem and takes most of the time of the full compilation. It is made more difficult by the fact that this requires extremely specific information about the FPGA's fabric to know not only what paths are available, but also make sure that the paths between LUTs are not too slow so we can send signals around the chip fast enough (programs for FPGAs are not like programs for CPUs where each instruction happens one after the other. In an FPGA all the gates are running at the same time so we have to time the electricity running at the speed of light to give the circuits time to execute, and move LUT's around if our timing is not met. This timing happens in a CPU too, but the CPU designer got this working so our instructions run in a predictable way). BITSTREAM GENERATION The final step of the compilation toolchain is to take the LUT configuration and routing information from place-and-route and convert it to a binary file the FPGA can actually 'run'. Like Place-and-route this step is highly FPGA dependent. We already know the configuration of the fpga we want from the last step so this step is just converting that configuration into the binary file format for the FPGA. This format is also kept secret.

In How FPGAs work, and why you'll buy one (2013)