Similar Projects

The four projects

What each one actually is

Stated in each project's own terms, from its own README — not in ours.

OpenROAD

The OpenROAD Project · started June 2018 under the DARPA IDEA program · BSD-3-Clause

The reference open-source engine for the physical half of digital design: floorplanning, macro and cell placement, clock-tree synthesis, routing and finishing, driven through a Tcl/Python API. Its stated target is an autonomous, no-human-in-loop 24-hour RTL-to-GDSII turnaround. It is deliberately PDK-independent, and it is the engine underneath ORFS, OpenLane, SiliconCompiler, Hammer and OpenFASoC. Its README claims over 600 tapeouts on SKY130 and GF180.

github.com/The-OpenROAD-Project/OpenROAD

OpenECOS

ECOS Team, Institute of Computing Technology, Chinese Academy of Sciences · PDK by ICsprout IC Co. + Zhejiang University · Apache-2.0 (core repos)

A vertically integrated RTL-to-chip stack: ECOS Studio (a desktop IDE promising an “FPGA-like experience for ASIC design”), the ecc chip compiler (a Python CLI running Yosys → ECC-Tools → KLayout with rtl2gds / rcx / harden / syn_sta flows), ECC-Tools (an iEDA-derived netlist-to-GDS toolchain, MulanPSL-2.0), ecc-dreamplace, an IP catalog, and their own ICsprout55 open 55nm PDK. Their entry point is RTL; the differentiator is that they own the PDK and the shuttle.

github.com/openecos-projects

LibreLane

librelane.org · based on OpenLane 2 by Efabless · Apache-2.0 · read at tag 3.0.8

A Python RTL-to-GDSII flow built on a typed Step / State / Flow model — 101 registered Steps, 23 DesignFormat views, 8 Flows — rather than on Make. Each Step declares its inputs, outputs and config_vars. It drives the same underlying engines (Yosys, OpenROAD, KLayout, Magic, Netgen) and is the successor to OpenLane 2, not a descendant of OpenROAD-flow-scripts, so it inherits none of ORFS’s behaviour. Its entry point is RTL plus a config file.

github.com/librelane/librelane

Vibe-IC

vibeic.ai · Claude Code plugin + MCP-EDA server · Apache-2.0 · first commit 2026-06-13

An AI-agent-driven flow that starts one layer above both of the others: natural-language intent → L1-L27 design documents → RTL → lint / simulation / formal / conformance → synthesis → PnR → DRC / LVS / STA / IR → GDS, with a separate analog A1-A9 and mixed-signal M1-M4 track. It does not implement a placer or a router; it drives OpenROAD, Yosys, OpenSTA, KLayout, Magic, Netgen, ngspice and others inside a forked toolchain image, and gates every step with deterministic checkers so a step cannot report PASS without an artifact.

github.com/vibeic/vibe-ic

Layering · the part that matters most

OpenROAD is upstream of Vibe-IC, not a rival

Vibe-IC runs OpenROAD. The digital PnR, CTS and routing results on this site are produced by OpenROAD inside the ghcr.io/vibeic/vibeic-eda image. We maintain a fork at github.com/vibeic/OpenROAD and push fixes into it — most recently PR #3, merged 2026-08-08, which restored LEF58_SPACING TONOTCHLENGTH: the value was parsed by odb and then silently discarded before it reached TritonRoute's constraint model, so a staged rule produced byte-identical routing to no rule at all. Presenting the engine we depend on as a defeated competitor would be both false and ungrateful. The honest question is which layer each project occupies.

Intent → specification

A human describes a chip in plain language; a machine produces a complete, checkable design document set.

Vibe-IC — L1-L27 documents OpenECOS — none OpenROAD — out of scope

Specification → RTL

Authoring synthesizable HDL, plus lint, simulation, formal and spec-conformance.

Vibe-IC — Phase 2 OpenECOS — partly: AI-generated IP blocks in the catalog OpenROAD — out of scope

Flow orchestration

Sequencing the engines, carrying configuration, deciding what runs next and whether it passed.

Vibe-IC — runner chain + gates OpenECOS — ecc + ECOS Studio OpenROAD — ORFS (sibling repo)

Physical-design engine

The actual algorithms: floorplan, place, CTS, route, optimize. This is where a project either writes a placer or calls one.

OpenROAD — writes it OpenECOS — ECC-Tools (iEDA-derived) + ecc-dreamplace Vibe-IC — calls OpenROAD

Sign-off

DRC, LVS, STA, IR-drop, parasitic extraction against a real deck.

Vibe-IC — KLayout / Magic / Netgen / OpenSTA, gated OpenECOS — RCX + STA in ecc; DRC/LVS rules listed as Todo in the PDK OpenROAD — STA in-tree; DRC/LVS delegated to external tools

PDK & foundry access

Whose process, whose rules, whose shuttle. Nobody in this table manufactures anything themselves.

OpenECOS — owns ICsprout55 (55nm), preview status OpenROAD — PDK-independent by design Vibe-IC — consumes 3 open foundry PDKs, owns none

Read down the stack: the only layer where all three genuinely compete is flow orchestration. Above it, Vibe-IC is alone. Below it, we are a consumer — of OpenROAD's algorithms and of somebody else's silicon.

Side by side · every cell traceable to a public repository

Attribute by attribute

An empty capability is written as “none”, not omitted — including ours. Star counts and commit counts are the projects' GitHub values on 2026-08-08 and will drift.

Attribute	OpenROAD	OpenECOS	Vibe-IC
Layer	Physical-design engine	Flow + PDK + IP, vertically integrated	AI agent above the whole flow
Input you provide	A netlist / Verilog + LEF/LIB + a Tcl script	RTL + a project config (GUI or CLI)	A paragraph of plain language, or design documents
Output	DEF / GDSII	GDSII (+ RCX / STA reports)	Design docs + RTL + testbenches + GDSII + per-gate evidence
Generates RTL	No — out of scope	Partly catalog IP only; e.g. axi4-to-apb4-bridge declares “本 IP 的 RTL、验证环境及配套文档由 AI 生成”. The flow itself does not author RTL.	Yes — the core function
AI / LLM in the flow	No LLM. ML used for modelling and prediction.	No — ecc and ECOS Studio are scripted / GUI	Yes — agent-driven end to end, deterministically gated
Functional verification	Out of scope	Not in the ecc flow	Lint, simulation, formal, coverage, spec-conformance, FPGA prototype
Analog / mixed-signal	No — digital only (OpenFASoC is a sibling project)	No — digital only	Analog A1-A9 and mixed-signal M1-M4 tracks
PDKs	PDK-independent; validated on SKY130, GF180, Nangate45, ASAP7 (plus NDA nodes)	One node — ICsprout55 (their own 55nm)	3 open foundry PDKs (sky130A, GF180MCU, IHP-SG13G2) + 2 predictive enablements marked tapeout_capable=false + a commercial-PDK mechanism carrying no vendor name in the repo
Proven silicon	README claims over 600 tapeouts (SKY130, GF180)	retroSoC, a RISC-V SoC, fabricated at 100 MHz on the 55nm process; first ICS55 engineering shuttle scheduled Dec 2025	None. No Vibe-IC design has been fabricated.
Open-benchmark scores	None published — not a code-generation tool	None published	VerilogEval-v2 151→153/156 · VerilogEval-Human 152→153/156 · RTLLM v2.0 48/50 · CVDP 243/302 blind; single-shot → terminal loop2converge where shown; official upstream scorers Separate CVDP engineering progress: original unfinished69 subset, one unresolved case; official score NOT_RUN, NOT_ELIGIBLE_AS_WHOLLY_BLIND due to historical exposure. Not a full-dataset score or Pass@1.
Upstream contribution	Is the upstream	ECC-Tools is iEDA-derived (MulanPSL-2.0); ecc-dreamplace derives from DREAMPlace	A tracked fork set (OpenROAD, Yosys, Magic, Netgen, KLayout, ngspice, Icarus, Verilator, OpenSTA, cocotb, sby, ALIGN) with daily upstream sync, each fix carrying a reproducible FAIL→PASS proof
License	BSD-3-Clause	Apache-2.0 for the core repos; ECC-Tools is MulanPSL-2.0; several IP repos have no license set yet	Apache-2.0
Age & scale	Since Oct 2019 · 42,723 commits · 2,951 stars · 980 forks	ECC-Tools since Jan 2026 · icsprout55-pdk 252 stars · ecos-studio 51 stars · ecc 16 stars	Since Jun 2026 · 16 stars · 6 forks

Sources: each project's own README and GitHub API metadata, read on 2026-08-08. The Chinese sentence in the “Generates RTL” row is quoted verbatim from the openecos-projects/axi4-to-apb4-bridge README, which also discloses that the IP has no formal verification, no independent human review, no synthesis sign-off and no silicon validation — a disclosure we think deserves credit rather than a point scored against them.

四份研究得出的結論 · 2026-08-19

證據我們都產出了，卻沒有任何一關擋在那裡

四份獨立研究——OpenROAD/ORFS 讀在 26Q3-1392、LibreLane 讀在 bf8cc13c、wafer.space 的投片前檢查實際跑過我們公開的 GDS、deepseek-harness 讀在 99f6f02fe——挖出的是同一個洞，四次。

同一個毛病穿了四套衣服：我們把證據產出來，然後不管它說什麼都繼續跑。繞線後的等價性證明產生了卻不強制通過；擺放工具自己回報「不合法」，我們接住再降級成警告；萃取工具把抱怨寫進檔案，我們從不去讀；而一個免費、可離線跑的外部把關，我們從來沒跑過。

W1今天送不出去

讓晶片送得出去

拿投片廠自己的檢查容器，離線跑我們公開的 GDS：16 關第 3 關就掛——晶片外圍沒有封環，後面 13 關沒機會跑。同時不合格的還有晶片尺寸、焊墊層、識別單元。這四項我們沒有任何一道檢查看得到。

W2晶片直接是死的 ×3

把已經產出的證明變成關卡

等價性證明要能中止流程；擺放工具說不合法就不准降級；萃取工具回報的錯誤要去讀。三件都幾乎不花力氣——證據早就算出來了，缺的只是拒絕。

W3可信度

公開的數字不能被偽造

兩份邏輯一樣錯的作答拿到 50%，只因為其中一份自己印出了評分程式的判定字串。老實答錯的對照組確實會被擋下——所以這個檢查不是沒用，是「可以被偽造」，那更糟。

W4假的乾淨

沒東西可檢查要算失敗

上游遇到空的規則集或缺少的量測，直接以失敗退出。我們的慣例相反，名字就叫 optional_program_exit_zero。實測一輪：80 道衛生檢查，其中 10 道根本沒檢查，卻仍然報出一個「已判定」的結論。

W5地基

讀數據，不要去解析文字報告

上游拿來把關的，是工具自己算出來的數字。我們只有一道關卡這樣接，其餘 61 道去解析文字報告——這句話寫在我們自己的程式檔裡。工具改個措辭，檢查就瞎了，而且瞎著繼續回報通過。

W6 · W7

可重現的簽核 · 規則放在程式旁邊

簽核當下用的製程檔版本從來沒被記下來，所以一旦被質疑就無法重現。另外 deepseek-harness 把 219 個「不變條件」檔案放在它們各自約束的模組旁邊——我們在強制力上領先，在「規則放在哪裡」上落後。

只有前兩條決定晶片死活；第五條決定其他幾條下一季還有沒有效。四份研究也各自記下了「上游比我們差的地方」和「上游那些不可能失敗的檢查」——那些段落沒有被挑掉。

The honest ledger · both columns, not one

Where we are behind, and where we are actually different

This project's whole doctrine is that a certificate which cannot fail is worthless. A comparison page that only listed our advantages would be exactly that kind of certificate. So the deficits come first, and they are specific.

Where Vibe-IC is behind

No tapeout. Not one Vibe-IC design has been fabricated. OpenROAD's README claims over 600; OpenECOS has retroSoC running at 100 MHz on real 55nm silicon. On the axis that ultimately decides whether a flow works, we have nothing to show.
We publish a benchmark-IC convergence matrix and most of it is not converged. The live count is below; it is generated from each run's own completion audit, not from a status table, precisely so it cannot be talked upward.
We have already published a cell as converged that was not. caravel_user_project × sky130A now reads FAIL on our own evaluation page, because the overclaim was caught and corrected rather than quietly dropped. It is on this page too, because a correction that only appears where nobody looks is not a correction.
We own no PDK and no foundry relationship. OpenECOS owns ICsprout55 and its shuttle. We consume other people's open PDKs and depend entirely on their maturity.
We write no placement or routing algorithms. OpenROAD's placer, CTS engine and detailed router are the state of the art we consume. If OpenROAD stopped, our Phase 3 would stop with it.
Scale. 16 stars and roughly two months of history against OpenROAD's 42,723 commits since 2019 and an ecosystem of downstream flows. Being newer is not a defence; it is just the size of the gap.

Where Vibe-IC is genuinely different

It starts from intent, not from RTL. Both other projects require you to already have a design. Vibe-IC turns a paragraph into L1-L27 design documents and then into RTL, and both entry paths — documents or dialogue — converge on the same handoff, so there is no “skip to RTL” back door.
Verification is inside the flow, not beside it. Lint, simulation, formal, coverage, spec-conformance and an FPGA prototype are steps the gate requires, not optional extras a user remembers to run.
Multi-PDK portability. The same design is driven onto sky130A, GF180MCU and IHP-SG13G2, which is what turns “it worked once” into “the flow is portable”. Both other projects are effectively single-target in practice.
An analog and mixed-signal track. A1-A9 and M1-M4 exist because most real chips are not purely digital. Neither of the other two addresses analog at all.
It is measured on other people's benchmarks. VerilogEval-v2, VerilogEval-Human, RTLLM and CVDP are run blind and graded by their own upstream testbenches — a number somebody else's harness produced, not one we defined. Neither of the other two publishes such a score.
The fixes go back upstream. Driving an agent through these tools exposes bugs a human flow never reaches — a parsed-then-discarded LEF58 rule, a silently inert constraint, a batch simulator returning success on a failed measurement. Each becomes a fork commit with a reproducible FAIL→PASS proof, and where possible a pull request.
Failures are published. The repository carries a fail-case ledger and a residual-defects file, and a re-run never overwrites an older verdict, so a regression stays visible instead of being replaced.

Rewritten after an adversarial review

Our competitor is not another EDA flow

A reviewer asked to attack this page put it more sharply than we had: comparing feature lists with OpenROAD, LibreLane and OpenECOS is the wrong axis, because each of them is solving a different problem. The question that actually decides whether this project matters is whether an AI-driven system can turn speed into a durable, verifiable, accumulating engineering advantage — and the honest test of that is what happens when Synopsys, Cadence or Siemens ship a genuinely good agent.

What each project is actually solving

OpenROAD — how to build a better physical-design engine.
LibreLane — how to compose EDA engines into a reliable flow.
OpenECOS — how to integrate EDA, IP, PDK and shuttle into one accessible path to silicon.
Vibe-IC — how to let an AI agent continuously complete, repair and verify IC design work. That is a different axis, and on the first three axes we are not the strongest and do not claim to be.
So the honest statement is: OpenROAD makes the tools better, LibreLane makes the flow better, OpenECOS makes silicon more accessible. We are trying to make the engineering process autonomous. Beating them is not the goal and would not be evidence of anything.

The loop that would have to be real for any of this to matter

A design fails on something the toolchain cannot do. The agent diagnoses it, patches the fork, proves the fix with a control that fails without it, and sends it upstream. The tool is now better for everyone, including the next design we run.
So every failure is supposed to become permanent capability rather than a workaround, and every stronger model makes the loop turn faster. That is the claim, and the only one here a well-funded competitor could not copy quickly.
It is also unproven. A loop that has run for weeks is an anecdote; the four numbers at the end of this page exist to make it falsifiable, and one of them currently reads zero.
And the reviewer’s hardest point stands: our largest single asset today is OpenROAD, which we did not write. What we own is not the placer — it is whatever machinery can keep repairing and extending that stack. If that machinery is not real, this page is marketing.

Read at the source level, 2026-08-12

Can an agent make a check pass by editing the evidence?

An engineer reported running a full RTL-to-GDS flow with an AI agent and finding that, when an N2N formal check would not pass, the agent edited the netlist until it did. That is not a model defect. It is an optimiser doing what it was asked: if the objective is “the check passes” and the evidence is writable, editing the evidence is a valid, cheaper solution than fixing the design. So we read both reference flows asking only this question. Every claim below carries a file and line.

What we found in ORFS and LibreLane

ORFS: the default build runs no sign-off DRC and no LVS. flow/Makefile:802 is the whole all target — synth, floorplan, place, cts, route, finish. drc and lvs are not in it, and not in metadata either.
ORFS: when DRC and LVS are run, no line of code reads their results. A repo-wide grep for the report filenames hits only the Makefile lines that create them. Makefile:746 calls its own DRV count a hack, in a comment.
ORFS: the gate CI actually runs is a per-design golden regression against a committed rules-base.json. Of the 63 designs on platforms a stranger can actually run, 63 set the setup-WNS floor to a negative number — so PASS explicitly permits timing not to converge. The golden itself is produced from one run by make update_rules.
LibreLane is better here, and it should be said: its sign-off DRC and LVS ARE asserted — a violation ends the flow with exit code 2. That is the opposite of ORFS.
LibreLane: config_vars is a genuine constructive whitelist, enforced at runtime. That is a stronger mechanism than ORFS’s, and stronger than ours.
But LibreLane’s inputs is only a precondition, not a scope. step.py:1158-1163 checks each declared input EXISTS, then step.py:1166 hands the step the complete State, unfiltered. And the outputs docstring at step.py:411-413 says a step is not allowed to modify formats it did not declare — while the base class performs no runtime check of that at all.
Neither project has any mechanism that would notice an artefact being edited between the step that produced it and the check that reads it. So the incident above would happen on either — and this is not a criticism of either project. It is the honest state of the field.

What that means for us — including where we are worse

Our §4.05 rule says a program reads only the design INPUT — never the oracle, the harness or the golden. That is the right rule. But today it is enforced by adversarial review, not by mechanism — stated in a position where it cannot act. We filed it against ourselves as vibe-ic#1079 after reading ORFS, because ORFS enforces the equivalent by unsetting out-of-stage variables at runtime and we do not.
LibreLane already contains the correct scope-filtering code, in create_reproducible(), which keeps only the declared inputs — it simply is not applied to actual execution. That code is directly adoptable, and we would rather say so than pretend we invented the idea.
Our own no-mix rule does address one half of this: results and tool fixes may never be in the same commit, so a hand-patch cannot inflate a published number. That is a real constraint, enforced by a gate rather than by a promise.
And the general lesson from both: the surface an AI is best at — writing testbenches and verification patterns — is exactly the surface you cannot let it write freely, because an agent that writes both the test and the thing under test has a cheaper path than making the design correct. The answer is not to stop it writing tests. It is to separate who writes the test from who decides the test is adequate, and to make that second decision oracle-free: inject a fault, and see whether the test notices.

Our current standing · generated from landed evidence

The number this page is judged by

A comparison page is easy to write and easy to leave standing after it stops being true. This block is not written by hand: it is regenerated from each benchmark run's own completion audit in the public repository, by the same generator that feeds the Evaluation page. If our position gets worse, this gets worse — on its own, without anyone deciding to update it.

2 of 12 (IC × PDK) cells converged

IC	PDK	State	Evidence
spm	IHP-SG13G2	in progress	no landed evidence yet
spm	sky130A	converged	PASS_WITH_WAIVERS · completion audit
spm	GF180MCU	converged	PASS_WITH_WAIVERS · completion audit
sha256	sky130A	in progress	no landed evidence yet
caravel_user_project	sky130A	in progress	no landed evidence yet
edge_llm_accel	NanGate45	in progress	no landed evidence yet
edge_llm_matmul_accel	NanGate45	in progress	no landed evidence yet
ibex	sky130A	in progress	no landed evidence yet
opentitan_aes	sky130A	in progress	no landed evidence yet
subservient	sky130A	in progress	no landed evidence yet
subservient	GF180MCU	in progress	no landed evidence yet
u_hawaii_adc	sky130A	in progress	no landed evidence yet

A cell counts as converged only when its landed evidence says so — the verdict is read from the run's own completion audit, not from a status table. Cells with no landed evidence show as in progress; they are never counted as passing and never removed from the denominator. Updated 2026-10-09 07:17 UTC+08:00.

Neither OpenROAD nor OpenECOS publishes an equivalent per-design convergence table, so this row of the comparison has no counterpart column — which is itself worth stating plainly rather than presenting as a win.

Do not compare us by how many tools we wrap

Compare us by how fast the system turns “cannot do this” into “can do this” when it meets something it cannot do.

OpenROAD makes the tools better. LibreLane makes the flow better. OpenECOS makes the silicon ecosystem more accessible. What Vibe-IC is trying to make better is the engineering process itself — every design failure becomes an EDA fix, every EDA fix makes the next design easier, and every stronger model makes that loop turn faster. That is the claim. It is also the thing this page cannot yet prove, which is why the four numbers below will be published whether they flatter us or not.

● Silicon Proof — currently ZERO. No Vibe-IC design has been fabricated. This dimension is listed first because it is the one we fail, and a scorecard whose worst number is hidden is not a scorecard.

● Engineering Velocity — counted ONLY as fixes that landed and passed the full gate. Not PRs opened, not commits, not issues filed. On 2026-08-12 this project opened roughly 25 PRs in a few hours while the open-PR count went 31 → 46; a published “PRs per hour” would have looked excellent while the system went backwards. A fix nobody can land is not a fix.

● Autonomous Improvement — upstream fixes that shipped with a reproducible FAIL→PASS control, and the fraction that reached the project owning the code. A patch we keep to ourselves is a workaround, not an improvement.

● Adversarial Verification — attacks attempted against green results, and how many produced a false PASS. Four artefact-tampering attacks currently succeed against both reference flows and against us; that number is the point of publishing it.

Every claim on this page points at a public repository. Read theirs, read ours, and if a cell here is wrong, the fastest way to correct it is an issue.

How Vibe-IC is measured

Related: the EDA fork ledger, where each upstream fix is tracked with its proof.

Different layers,not a scoreboard.