How do I use a local SemiKong LLM to drive DRC sign-off?

A semiconductor LLM can reason about DRC. It can't run it. Vyges is the layer that lets it — locally, against your own layout, with the deterministic engine as ground truth. This walkthrough drives real DRC with a locally-hosted SemiKong, end to end, on your own hardware.

July 9, 2026 • By Shivaram Mysore

A model that reasons about DRC still can't run it

Semiconductor-specific LLMs — SemiKong being one of the first openly available ones — are beginning to move from research into engineering organizations. They know the vocabulary: DRC, LVS, timing, floorplanning. But a model that can talk about a design-rule check cannot run one, and it does not know your layout or your PDK. The moment it needs your real data, it hits a wall: that data cannot leave the building.

Vyges is the layer below the model. Models reason; Vyges executes. A model — SemiKong, Claude, or any other — drives the deterministic Loom engines through the open Model Context Protocol (vyges mcp), on your own hardware. This post walks a complete, end-to-end DRC execution loop running locally — a local SemiKong driving your DRC.

New to vyges mcp? Start with Point Your AI IDE at Your Own Silicon Tools — Locally, No Cloud — this post builds on it, swapping a general-purpose AI assistant for a local semiconductor LLM.

What you'll build

Everything runs on your machine. Your GDS never leaves it. The model proposes the tool call; the deterministic vyges-drc engine is the ground truth. Our worked example checks spi_host_lite — the SPI macro (vyges-spi-lite) from our taped-out Edge Sensor SoC.

Inputs (both public):

• The layout — spi_host_lite.gds, from the vyges-edge-sensor-soc repo (/gds/).
• The sky130 DRC deck — the rule deck that encodes the foundry's design rules (widths, spacings, densities…) in vyges-drc's grammar, from the Vyges pdk-catalog. Pass it with --rules.

1. Get SemiKong running locally

SemiKong is an open, semiconductor-specialized model (a Llama-family fine-tune). Pull it into a local runtime — Ollama or llama.cpp both work — so it serves on localhost. It runs on commodity CPU (a GPU is the upgrade); an 8B model is plenty for driving tool calls.

(See the SemiKong project for the weights and a local-run recipe.)

2. Install the Loom engines

vyges install loom          # fetches the open sign-off engines into ~/.vyges/bin

vyges-drc is one of them — a geometric design-rule checker that reads GDS or OASIS against a rule deck.

3. Register the model with vyges model

Point Vyges at your local SemiKong. The registry stores a thin, swappable descriptor — the model is a choice, not a lock-in:

vyges model add semikong \
    --backend openai-compat \
    --endpoint http://127.0.0.1:11434/v1 \
    --model semikong \
    --tool-calling json \
    --local

vyges model list            # semikong (local) …

--local keeps it on your hardware. --tool-calling json matters: local 8B models are most reliable emitting structured JSON rather than a provider-specific function-calling API, so Vyges drives them with JSON tool calls directly.

4. Run the DRC loop

Now let the model drive — one command:

vyges model run semikong \
  "Run a DRC check on spi_host_lite.gds against the sky130 deck (top cell spi_host_lite),
   then report whether it's DRC-clean or the number of violations."

vyges model run runs a reason → tool-call → observe loop over the vyges mcp tools. The transcript below is from an actual execution of vyges model run against a locally-hosted SemiKong-8B: the model emitted the tool call, vyges mcp invoked the real vyges-drc engine, and the final line is the engine's result. (File paths shortened for readability.)

── step 1 ──
{"tool": "drc", "args": ["check", "spi_host_lite.gds", "--rules", "sky130-core.drc", "--top", "spi_host_lite"]}

── step 2 ──
{"done": "The layout is DRC-clean with 0 violations."}

The layout is DRC-clean with 0 violations.

In step 1, SemiKong emits a structured call to the drc tool; Vyges invokes the real vyges-drc engine with exactly those arguments. In step 2, having observed the engine's verdict, the model reports it. The engine decides; the model explains.

The AI proposes. The sign-off engine verifies.

Execution environment (this run):

Model:    SemiKong-8B (Q4_K_M)
Runtime:  llama.cpp (CPU-only)
Host:     2× Xeon E5-2699 v4 · 251 GB RAM · no GPU
Engine:   vyges-drc  (Vyges Loom)
PDK:      sky130
Layout:   spi_host_lite.gds  (Edge Sensor SoC)

What you get — and why you can trust it

The verdict is the deterministic engine's, produced on your own hardware. Cross-check it directly and you get the same answer:

vyges loom drc check spi_host_lite.gds --rules sky130-core.drc --top spi_host_lite
# vyges-drc — CLEAN ✓  (no violations)

Because the deterministic engine produces the verdict, the equivalent CLI command yields the identical result — invoked by an AI model or straight from CI, the sign-off engine behaves exactly the same.

A real, taped-out IP, checked by an 8B model you host yourself, matching the engine's ground truth exactly. An 8B can meander on harder, multi-step tasks — which is precisely why the design works the way it does: the deterministic engine is the ground truth, and the loop makes the model's final answer the engine's answer, not the model's guess. The model proposes; the engine verifies.

One honest caveat: this walkthrough uses a representative sky130 rule deck — enough to demonstrate the loop, not a full foundry sign-off.

Why this is different

Most AI demos for chip design stop at reasoning over text or generating RTL. This one runs a complete execution loop: a local semiconductor LLM reasons about the task, emits a structured tool call, invokes a deterministic DRC engine through vyges mcp, observes the engine's output, and reports the engine's verdict. The model doesn't simulate sign-off — it drives the real sign-off engine.

Can SemiKong run real DRC checks?

Yes. When connected to vyges mcp, a locally-hosted SemiKong can invoke the real vyges-drc engine and report the engine's verdict — the walkthrough above is exactly that.

Why this matters

• Local-first. Your layout and the model both stay on your machine. Nothing leaves the building.
• Model independence. You're never tied to one AI provider — swap SemiKong for another model with a single vyges model entry, and your silicon flow doesn't change. AI models are replaceable; your silicon flow isn't.
• Deterministic ground truth. The AI proposes; vyges-drc decides. Pull the AI out and the same check runs headless in CI.

This lets a semiconductor organization adopt new AI models as they appear — without rewriting its verification flow or exposing proprietary RTL to an external service.

What's next

DRC is only the first execution loop. The same architecture — reason → run → read against a deterministic engine — extends naturally to LVS, timing closure, extraction, power integrity, ECO optimization, and ultimately complete tape-out flows. The model may change over time; the execution layer stays the same.

This isn't a prompt-engineering demo. It's a model-agnostic execution framework for semiconductor engineering. Replace the model, keep the execution layer, and the workflow stays the same.

Explore the Loom engines, the vyges mcp interface, and why AI-native silicon engineering changes the economics of getting to tape-out.

Built something with this — or just exploring? Swap in a different model, point it at another engine, chain a repair, or wire the loop into CI. And whatever you try, we'd love to hear your experiences automating silicon with LLMs and Vyges — share what you built and we'll feature the best. → Share it on GitHub Discussions