NexusSilicon

A physics-native, evidence-first open-source chip-design flow.

NexusSilicon is building a new kind of EDA platform: one where the physical-design engine is explainable by design, and where AI investigates structured engineering evidence instead of guessing from thousands of lines of tool logs.

At its heart is the Metric Field Engine (MFE)—a custom physical-design core for placement, thermal co-design, clock-tree infrastructure, and routing topology. Around MFE, NexusSilicon connects proven open-source tools for synthesis, parasitic extraction, timing analysis, and verification through open industry formats.

Build chips with physics. Debug them with evidence.

Why NexusSilicon?

Chip design is one of the most powerful engineering disciplines in the world, but modern RTL-to-layout flows remain difficult to inspect, difficult to automate, and difficult for new engineers to learn. A failure can begin in RTL, appear as timing loss after placement, and become buried under reports across multiple tools.

NexusSilicon is designed to make that chain visible.

• Physical decisions are owned by MFE, not hidden behind a black-box orchestration script.
• Every important artifact becomes evidence: RTL symbol → synthesized cell → placed instance → net → route → RC → timing path → finding.
• AI starts from the evidence graph, so it can answer what failed, where, why, what is safe to try, and what will be affected.
• PDK configuration is manifest-driven, creating a clean path to support multiple technology definitions without hard-coding one node into the engine.
• Open formats stay central: SystemVerilog, LEF, Liberty, DEF, SPEF, SDC, GDSII, and OASIS.

This is not another wrapper that simply calls an existing place-and-route tool. NexusSilicon uses external projects where they are mature specialists, while MFE remains the physical-intelligence core.

The MFE core

The Metric Field Engine is the reason NexusSilicon exists. It is a custom C++20 engine built around geometry, fields, and structured physical evidence.

MFE capability	Purpose
Metric-field / optimal-transport placement	Move cells using geometry-aware physical objectives.
Thermal co-design	Keep thermal state available alongside placement and routing evidence.
DME clock-tree infrastructure	Provide a deterministic foundation for clock skew balancing.
LEF-pin-aware routing	Route from real cell-pin access geometry rather than generic cell centers.
Rectilinear Steiner topology	Build compact multi-pin route trees instead of simple serial route chains.
Evidence graph	Trace design intent and physical consequences across every stage.
Reviewed ECO planning	Turn actual timing failures into explicit, safe-to-review experiments.

The current Sky130 demonstration uses MFE routes, then validates the exported DEF through real OpenRCX extraction and OpenSTA timing analysis.

Evidence-first AI

Most “AI for EDA” ideas give an LLM raw logs and hope for the best. NexusSilicon takes a different route.

The flow produces a compact JSON evidence graph. An agent can navigate deterministic relationships instead of rediscovering them from text:

RTL symbol
  → synthesized standard cell
    → physical instance
      → net
        → route
          → extracted parasitics
            → timing path
              → finding
                → reviewed ECO proposal

The included AI CLI is intentionally read-only. It can explain results, expose the relevant path, and recommend a next experiment. It never silently edits RTL, constraints, placement, routing, or layout.

# Deterministic local explanation: no model call, no data leaves your machine.
.\tools\mfe.ps1 ask -Project .\projects\gcd_demo\project.yaml `
  -Question "Why did timing fail?" -Offline

It can also use any OpenAI-compatible endpoint, including a local model server:

$env:MFE_LLM_BASE_URL = "http://localhost:11434/v1"
$env:MFE_LLM_MODEL = "your-local-model"
.\tools\mfe.ps1 ask -Project .\projects\gcd_demo\project.yaml `
  -Question "What is the safest next timing experiment?"

Architecture

flowchart LR
  RTL["RTL / SystemVerilog"] --> YOSYS["Yosys\nlogic synthesis"]
  YOSYS --> NETLIST["Mapped netlist\n+ source links"]
  NETLIST --> MFE["Metric Field Engine\nfloorplan · placement · thermal\nCTS infrastructure · Steiner routing"]
  MFE --> DEF["Routed DEF"]
  DEF --> RCX["OpenROAD + OpenRCX\nRC extraction host"]
  RCX --> SPEF["SPEF parasitics"]
  SPEF --> STA["OpenSTA\nstatic timing"]
  STA --> EVIDENCE["Evidence graph\nfindings · ECO plan"]
  MFE --> EVIDENCE
  EVIDENCE --> AI["NexusSilicon AI CLI\nread-only reasoning"]
  MFE --> LAYOUT["GDSII / OASIS\nstream artifacts"]

Loading

What each external tool does

NexusSilicon does not use OpenROAD for MFE’s placement or routing. The tool boundary is deliberate.

Component	Role inside the flow
Yosys	Translates RTL into a standard-cell mapped netlist.
Verible	SystemVerilog parsing, linting, AST/LSP integration target.
MFE	Owns physical compilation: placement, thermal data, routing topology, physical evidence.
OpenROAD/OpenRCX	Hosts OpenDB and extracts RC parasitics from the MFE DEF.
OpenSTA	Calculates timing using Liberty, SDC, mapped netlist, and SPEF.
KLayout / Magic	Verification integration boundary.

What happens in a run

1. Understand RTL — parse/lint SystemVerilog and synthesize it to mapped gates.
2. Create a physical database — import LEF cell geometry, net connections, and source links into MFE.
3. Compile the physical design — floorplan, place, legalize, calculate thermal context, prepare CTS, and create pin-aware Steiner routes.
4. Export interoperable artifacts — write DEF, stream-layout artifacts, and MFE evidence.
5. Extract reality from geometry — OpenRCX converts routed shapes into resistance/capacitance parasitics in SPEF.
6. Measure timing — OpenSTA reports setup/hold paths and slack.
7. Reason safely — MFE produces timing findings and reviewed ECO proposals; the AI CLI makes the chain understandable.

RTL → mapped netlist → MFE physical flow → DEF → RCX/SPEF → STA → evidence → AI explanation

Quick start

Build the portable core

Requirements:

• CMake 3.20 or newer
• C++20 compiler
• Eigen3
• Python 3.10 or newer (for the AI CLI test and assistant)

git clone https://github.com/mkrishna793/NexusSilicon.git
cd NexusSilicon

cmake -S . -B build
cmake --build build --parallel
ctest --test-dir build --output-on-failure

The unified Nexus CLI

tools/nexus.ps1 is the product-facing command surface. It makes setup and investigation repeatable instead of requiring users to know the internal adapter scripts.

# Check compilers, Python, WSL, and PDK collateral.
.\tools\nexus.ps1 doctor sky130

# See registered PDK manifests or validate one.
.\tools\nexus.ps1 pdk -Action list
.\tools\nexus.ps1 pdk sky130 -Action validate

# Create a new project skeleton.
.\tools\nexus.ps1 init .\projects\blink

# Run, inspect, report, and ask questions.
.\tools\nexus.ps1 run .\projects\gcd_demo\project.yaml
.\tools\nexus.ps1 status .\projects\gcd_demo\project.yaml
.\tools\nexus.ps1 report .\projects\gcd_demo\project.yaml
.\tools\nexus.ps1 ask .\projects\gcd_demo\project.yaml -Question "What failed?" -Offline

Review an ECO safely

mfe run_eco now writes timing/eco-candidates.json. Every resize or buffer candidate is selected only from cells declared in the active PDK LEF. A candidate is never applied by the AI or CLI.

MFE also exports physical/power-analysis.json: Liberty-characterized static cell power feeds a DC resistive PDN mesh and the steady-state thermal solver. These are documented MFE engineering-model metrics. Dynamic power needs real activity data, and none of these results are a replacement for foundry EM/IR or thermal signoff.

The ECO review command requires a separately measured sandbox result. It will only rank a candidate when timing, power, IR drop, thermal, routability, and DRC metrics all carry mode: "real" provenance. The command blocks missing or estimated data; an approval record is then explicit and attributable.

# Collect what this run can prove. Missing power/IR evidence remains visible.
python .\tools\eco\collect_metrics.py `
  --project .\projects\gcd_demo\project.yaml `
  --output .\projects\gcd_demo\results\eco\baseline-metrics.json

# Compare a separately executed sandbox result. It writes evaluation.json.
.\tools\nexus.ps1 eco .\projects\gcd_demo\project.yaml -Action evaluate `
  -Baseline .\projects\gcd_demo\results\eco\baseline-metrics.json `
  -CandidateMetrics .\projects\gcd_demo\results\eco\candidate-metrics.json

# Only an eligible evaluation can be approved; approval itself does not edit a design.
.\tools\nexus.ps1 eco .\projects\gcd_demo\project.yaml -Action approve `
  -CandidateId "resize:u0:sky130_fd_sc_hd__inv_2" -ApprovedBy "your-name"

Run a candidate in an isolated directory before evaluating it. The sandbox copies the mapped netlist, applies one PDK-legal resize or one LEF-pin-checked single-output buffer insertion, and executes MFE physical compilation, OpenRCX/SPEF, OpenSTA/report_power, the MFE power/IR/thermal feedback pass, and KLayout DRC. A rejected experiment never modifies the baseline project.

.\tools\nexus.ps1 eco .\projects\gcd_demo\project.yaml -Action sandbox `
  -CandidateId "buffer:_229_:sky130_fd_sc_hd__buf_1"

Promote a distribution bundle

Promotion is intentionally stricter than ECO approval. The selected sandbox must have non-negative WNS/TNS, zero KLayout DRC findings, zero routing overflow, and pass the IR/thermal policy. A successful command copies the complete measured artifact set into an immutable results/eco/releases/ bundle with hashes and an approval record.

.\tools\nexus.ps1 eco .\projects\my_chip\project.yaml -Action promote `
  -CandidateId "resize:u42:sky130_fd_sc_hd__nand2_2"

This produces a reproducible engineering release bundle. It is still distinct from foundry signoff, which requires foundry-qualified PDK collateral and signoff tools.

The core test suite includes physical-flow, evidence-graph, manifest, PDK-legal timing-ECO, ECO-review, and AI-CLI tests.

Ask the project about itself

.\tools\mfe.ps1 ask -Project .\projects\gcd_demo\project.yaml `
  -Question "Show the current timing findings" -Offline

Run the full Sky130 demonstration

The complete demonstration needs optional open-source tool sources and PDK assets. They are not committed into the repository; this keeps the project lightweight and respects each dependency’s license.

# Fetch third-party source repositories declared in the toolchain manifest.
.\tools\bootstrap-third-party.ps1

# Build/install optional tools as described under tools/.
# Set this only when your WSL OpenROAD build is not at the documented default:
$env:MFE_OPENROAD_WSL = "/home/<user>/openroad/build/bin/openroad"

.\tools\mfe.ps1 flow -Project .\projects\gcd_demo\project.yaml

The output directory contains mapped RTL, routed DEF, SPEF, timing reports, evidence graphs, and reviewed ECO plans:

projects/gcd_demo/results/
├── frontend/
│   └── mapped_netlist.v
├── physical/
│   ├── routed.def
│   ├── design.spef
│   └── evidence-graph.json
└── timing/
    ├── timing.rpt
    ├── timing-evidence.json
    └── eco-plan.json

Validation and benchmark evidence

NexusSilicon has two useful kinds of evidence: deterministic engine tests and an end-to-end Sky130 integration run. They answer different questions.

What MFE is already validated to do well

Area	Evidence	What it demonstrates
Metric-aware routing	Unit test routes directly across a flat mesh, then detours around an inflated congestion/thermal region.	The FMM router responds to the metric field instead of using a fixed Manhattan path.
Thermal coupling	Unit test solves a hotspot and verifies that thermal coupling pushes placement away from the hot region.	The thermal field can influence MFE placement objectives.
PDK-aware route export	Sky130 demo emits pin-aware routes, PDK track snapping, and legal li1-to-met1 via transitions.	MFE reads declared LEF layers and vias rather than using a hard-coded technology.
Power / IR / thermal analysis	Liberty and OpenSTA power feed the MFE DC-PDN and thermal solvers; dedicated tests verify non-zero current and IR drop.	The backend has a working engineering-model analysis loop.
ECO safety	A real Sky130 buffer ECO was isolated, routed, RC-extracted, timed, power-analysed, and DRC-checked before being rejected.	Candidate changes are measured and reversible; they do not silently alter the baseline.

Current Sky130 gcd_demo integration run

This is a small demonstration design, not a competitive PPA benchmark and not a tapeout claim. It is useful proof that the interfaces work together on real Sky130 collateral.

Result	Current measured value
MFE physical runtime	0.83 s
Standard-cell instances	142
Routed nets	145
Multi-pin Steiner routes	71
PDK-legal vias emitted	512
Track-snapped route segments	145
OpenRCX extraction	143 nets, 870 RC segments, 957 coupling capacitors
OpenSTA vectorless power	10.9591 mW
MFE modeled peak IR drop	2.9454 mV
OpenSTA WNS	-6.3789 ns
KLayout DRC findings	1712

The first seven rows are the strongest evidence of what works today: MFE can compile a mapped design into routed, PDK-aware geometry that OpenROAD/OpenRCX and OpenSTA can consume. The final two rows are intentionally visible because they show the project is still in active physical-quality development: the demo is not timing closed or DRC clean.

ECO experiment evidence

The current critical-path buffer experiment is a good example of the project doing the right thing. It reduced vectorless power and modeled IR drop, but it made timing and DRC worse, so the approval gate rejected it:

Metric	Baseline	buf_1 sandbox
WNS	-6.3789 ns	-7.1696 ns
OpenSTA power	10.9591 mW	10.7922 mW
MFE modeled peak IR drop	2.9454 mV	2.8658 mV
KLayout DRC findings	1712	1736

This is the intended NexusSilicon behavior: a small power win cannot hide a timing or DRC regression. The candidate remains isolated in its sandbox.

PDK and benchmark scope

• Sky130: real open PDK collateral is used by the demonstrated integrated flow.
• ASAP7: the repository includes LEF/Liberty fixtures and a manifest for parser/flow compatibility checks. It is not a foundry-qualified 7 nm result.
• IBM01 Bookshelf: benchmark input files are included for placement-format support. A published IBM01 quality/runtime comparison has not yet been produced.

To claim that MFE is faster or better than OpenROAD, the project needs a reproducible benchmark suite with the same designs, PDKs, constraints, host, and metrics: runtime, HPWL, congestion, WNS/TNS, DRC, and power. That is the next honest comparison milestone; the current demo cannot prove it.

PDK-driven by design

A PDK is described by config/pdks/<name>/manifest.json. The manifest declares technology LEF, cell LEF, Liberty corners, routing layers, RC extraction rules, and verification references. Paths are resolved relative to the manifest, so projects can move between machines without embedding one developer’s directory structure.

This separation is important: MFE’s logic remains technology-neutral while the rules and assets of a PDK remain explicit, auditable configuration.

Repository guide

NexusSilicon/
├── apps/mfe/                 # MFE C++ command-line application
├── include/mfe/              # engine interfaces
├── src/                      # placement, routing, IO, evidence, ECO implementation
├── config/                   # schemas and PDK manifests
├── projects/gcd_demo/        # runnable SystemVerilog example
├── benchmarks/               # open benchmark fixtures
├── tools/flow/               # flow orchestrator
├── tools/adapters/           # external-tool contracts
├── tools/agent/              # evidence-first AI assistant
├── docs/                     # architecture and release documents
├── tests/                    # unit, integration, flow, and agent tests
└── third_party/toolchain.json# declared optional upstream dependencies

Roadmap

v0.1 — Developer Preview

The current release establishes the stable foundations: MFE core, portable manifests, evidence contracts, a read-only AI interface, reproducible tests, CI, and an open RTL-to-timing demonstration.

v0.2 — Physical correctness and route quality

• PDK-derived legal via insertion for mixed-layer nets.
• Track-grid, spacing-aware detailed routing and congestion feedback.
• Timing/congestion-weighted Steiner refinement.
• DRC finding ingestion and reviewed route-repair proposals.

v0.3 — Closed-loop physical optimization

• PDK-legal gate resizing and buffer candidates.
• Transactional ECO sandbox: modify → place → route → extract → time → validate.
• Automatic comparison of metrics, with human approval before applying a winning change.
• Power, IR-drop, and thermal objectives combined with timing and routability.

v0.4 — Layout and verification maturity

• Standard-cell-reference GDSII/OASIS assembly.
• Correct layer/datatype mapping, vias, pins, and labels.
• DRC-repair and real LVS integration with reproducible evidence.

v1.0 — Open collaboration platform

• Stable plugin interfaces for PDKs, tools, and AI providers.
• Local/web visualization built directly on the same evidence graph.
• Reproducible experiment bundles and team approval workflows.

Current status

NexusSilicon is an open-source developer preview—a serious engineering foundation, not a tapeout claim. It already demonstrates MFE physical routing, real parasitic extraction, real timing analysis, structured evidence, and safe AI investigation. The remaining verification and signoff-grade capabilities are tracked openly in the roadmap rather than hidden behind marketing language.

Contributing

Contributions are welcome. Start with a test, preserve the file-format contracts, and keep every physical or AI action explainable.

ctest --test-dir build --output-on-failure

Please do not commit generated builds, PDK installations, tool binaries, secrets, or model credentials. See NOTICE.md for third-party dependency guidance and LICENSE for the project license.