ASIC workflow orchestration

The problem

An RTL-to-implementation workflow involves several tools and distinct verdicts. A command succeeding at one stage can be mistaken for overall success unless inputs, failures, and artifacts are carried forward explicitly.

What I built

I built a Python orchestrator that calls ASIC-oriented MCP tools and collects stage results into structured reports. Its tests exercise client contracts, stage behavior, and fixture flows.

Usable tool

Who it is for: Hardware engineers combining several EDA stages into one repeatable workflow.

First task: Install the CLI from the checkout, run asic doctor, then inspect the counter demo.

What you can produce: Per-stage results and a report tying review, verification, synthesis, and implementation together.

Current scope: An orchestrator over the MCP servers. Results apply to the selected design, constraints, tools, and PDK; a successful run does not establish manufacturing qualification.

Start with the example Source and documentation Step-by-step tutorials

A first useful result

Read the example specification and use asic doctor to inspect command availability before attempting a full flow. Complete the tutorial counter review/simulation/synthesis first so the individual gates are understandable.

Evidence and limits

Golden transcripts document example outcomes. A software gate summary is not manufacturing qualification. Physical stages need clock constraints, technology files, and fresh checks; successful orchestration does not establish a production-ready chip.