Newsletter
The open silicon toolchain changed hands, and most plans have not noticed
Efabless closed in March. The flow it hosted now lives at the FOSSi Foundation under a different name, and the shuttle you were going to book is run by somebody else. If you scoped anything on open silicon in 2024, the ground moved underneath it.
One drawing
Picture the open RTL-to-GDSII flow as two halves that are usually drawn as one.
The tools half is Yosys for synthesis, OpenROAD for implementation, Magic and netgen and KLayout for signoff, OpenSTA for timing. That half is healthy. It is maintained, it is used in production, and nothing that happened this year threatened it.
The infrastructure half is the orchestrator that drives those tools, the PDK, and the shuttle that turns a GDSII into parts in a tray. That half is where the weight sits, and it is the half that moved.
Most flow diagrams, including the one I drew last year, show these as a single pipeline. They are not. The tools are a commons. The infrastructure was, until recently, substantially one company.
One decision worth revisiting
If you scoped an open-silicon project any time in 2024, you almost certainly wrote down three things that are no longer true.
Efabless closed in March 2025. It ran chipIgnite, which was the accessible shuttle for SKY130 and GF180MCU, and it hosted OpenLane. The closure was abrupt enough that it caught projects mid-flight.
OpenLane 2 is now LibreLane, taken up by the FOSSi Foundation and released in July 2025. The flow steps are the same. The invocation is not, and neither is the documentation you bookmarked.
chipIgnite has a successor at ChipFoundry, on a thinner schedule than the old quarterly cadence. Tiny Tapeout and the IHP programs are still running.
None of this means open silicon got worse. The tools are fine and the community moved fast. But a plan that said "tape out on chipIgnite in Q2 using OpenLane" now has two dead references and a schedule assumption that needs re-checking, and plans like that do not usually re-check themselves.
The decision I would revisit: how much of your route to silicon rests on one organization? Not as a criticism of anyone, but as a question you can answer before it is answered for you. The tools survived because many people maintain them. The infrastructure wobbled because fewer did.
One tool, used in anger
PulseView, with sigrok underneath it.
Not a chip tool. A bench tool, and the one I reach for when a board is doing something that makes no sense. It drives cheap FX2 logic analyzers and most modern SCPI oscilloscopes, and it decodes I2C, SPI, UART and CAN inline so you read transactions rather than edges.
The reason it earns a place in a newsletter about silicon: at some point the simulation agrees with you and the hardware does not, and the only way through is to look at what the pins are actually doing. A twenty dollar logic analyzer and a free decoder have resolved more arguments for me than any amount of staring at RTL.
The trap is sample rate. Capture fast enough for the bit and you see the protocol. Capture fast enough for the edge and you see the glitch that is causing the problem. Those are not the same setting, and the first one makes you confident about the wrong thing.
What I am seeing
A pattern worth naming, because it is not only a silicon story.
Open-source tooling is now good enough that teams plan around it, which is new and genuinely good. But "open source" gets treated as a single risk category when it is at least two. A tool with dozens of maintainers and a decade of use is a different proposition from a service with one company behind it, even when both are Apache-licensed and both live on GitHub.
The question I have started asking in architecture reviews is not "is this open source" but "how many organizations would have to fail before this stops being available to us?" For Yosys the answer is comfortable. For anything that is really a hosted service wearing an open-source license, it is often one, and the license does not help you on the day it closes.
That question applies well outside silicon. Most teams have at least one dependency that is technically open and practically singular.
Issue 1. Written for people who are not buying anything. Replies reach me directly; there is no list, no form and no tracking on any of this.