lumiculelight does the math

Co-design agents

Agents that design.
Engines that prove.

Most AI in EDA is a language model bolted onto a legacy tool — it can answer questions, but it cannot design and it cannot prove. Lumicule splits the two jobs: specialized agents explore and propose, then deterministic engines decide whether a proposal survives.

Watch them workHow signoff works

Adversarial by design

A proposal has to survive an argument

When a design decision matters, the platform can put it in front of three roles that are not allowed to agree politely: a proposer, a critic, and a judge. They argue through real evidence — a linter, a synthesis run, a simulation — and the result is scored rather than asserted.

Proposer
Critic

Oracle evidence

lint · synth · sim

DRC · LVS · formal

Judge

score / 10

Debate, not a single opinion. The judge's verdict cites the evidence that produced it, so a disagreement is about a result rather than a preference.

The roster

One agent per domain, not one agent for everything

Each agent carries the context of a single discipline. They share one project tree, so a thermal finding is visible to the layout agent instead of being retyped into a ticket. The roster below is a selection — ask us for the current full set.

Photonic

pic-designer
Photonic layout from the PDK catalogue — rings, crossbars, MZIs, grating couplers — with DRC in the loop and GDS as the output.
em-sim
Mode solving, FDTD and S-parameter extraction for the structures the layout agent just placed.

Electronic

eic-designer
The driver ASIC under the photonics: RTL and analogue cells through synthesis, placement and routing, with SPICE where it matters.
power-integrity
Power-grid analysis and IR-drop across a large channel count, where the supply is usually the thing that breaks first.

Digital & firmware

fpga-engineer
RTL, synthesis, place-and-route and firmware — sequencers, calibration loops and control logic — verified formally rather than only simulated.
pretest
Runs the regression baseline before an iteration is allowed to count as progress, so a change that breaks the bench is caught immediately.

Thermal & packaging

thermal-engineer
Die-level and package-level thermal analysis, calibration against measurement, and the compensation loops that keep a photonic device on wavelength as it warms.
chiplet-engineer
2.5D and 3D assembly: boundary manifests, bump maps, package thermal, PDN and mechanical clearance checks.

Board

pcb-designer
The carrier board: stackup, impedance, differential pairs, BGA fanout and routing, with IR-drop and eye-diagram analysis rather than a rule of thumb.
esd-engineer
Pad ring and clamp checks, for the failure mode that kills a first article before anyone gets to measure it.

Verification & signoff

verification-judge
Reads simulation, DRC and formal output and gives a verdict with a confidence — a fail decision comes with a root cause, not just a red mark.
tapeout-engineer
GDS signoff, waiver management and MPW submission — what leaves the building, and the record of why each waiver was granted.

Photonic surrogate models

The models that make exploration cheap

A full EM solve is accurate and slow. For the inner loop — thousands of candidate layouts — Lumicule uses learned surrogates, and it is explicit about which is which.

Crosstalk
An image-to-image network that predicts optical crosstalk between adjacent structures from their geometry, so a candidate can be screened before it is solved properly.
Thermal coupling
The same shape of network with attention, predicting how heat from one device reaches its neighbours — the effect that decides whether a ring bank stays on wavelength.
S-parameters
A Kolmogorov–Arnold network that maps device parameters to their spectral response, for the fast sweep in the middle of a design-space search.
A surrogate is not a signoff. Learned models are used to explore and rank. The result that gets signed is the one produced by a deterministic solver. Where a surrogate disagrees with a solve, the solve wins and the model gets corrected.

The model, not just the agents

We are building our own model for this domain

Most AI in this industry is a general-purpose language model wearing an EDA hat: fluent about hardware, and not trustworthy with it. We are training our own model instead — and what makes it ours is not the architecture. It is how it is taught.

01 · How it is rewarded

By verification, not by preference
A general model is tuned to sound right to a person. In silicon there is no “sounds right”. Every training signal we use comes from a deterministic engine — the same checks that gate a real design. A candidate that does not compile, does not pass its testbench, or does not survive formal equivalence is scored as a failure, and the model learns from that rather than from an opinion.

02 · What it is taught on

The artefacts this industry actually produces
RTL, netlists, testbenches and the design-rule, equivalence and simulation reports that come back from them — not prose about hardware. It is trained on the material a design team generates and has to act on, which is why its answers arrive as something a flow can run.

03 · What it is for

The hard half: debugging
Writing RTL is the part that is already getting easy. Finding out why a design fails is where a project actually loses its schedule. Our model is trained on that half — failures, the families they fall into, and the evidence that localises them. It is built to hand a team a cause, not a patch that happens to make a test pass.

04 · Why it compounds

The training signal is our own stack
The engines that score the model are the engines that sign off a design. Every improvement to verification is therefore an improvement to the model — and every model that is better at designing makes the engines work on harder cases. That loop belongs to the platform, not to whoever supplied the base model.

Where it stands. The model is in training, on our own compute, and it is not a shipped product yet. We publish no benchmark for it until we have one we measured ourselves — and when we do, it will be on failures found and re-spins avoided, not on lines of code generated.

Guardrails

What the agents are not allowed to do

They cannot sign off
No agent approves its own work, and none of them can mark a design ready. Approval is a human action, recorded, with a name and a timestamp.
They cannot act without a record
Every tool call an agent makes is a typed, allowlisted operation with the path and inputs written down. There is no shell, so there is no unrecorded step.
They cannot quietly change something
Edits are tracked like any other change, with the diff, so a design review can see what the agent did and disagree with it line by line.
They cannot hide a failure
A failed gate is reported as a failed gate, including the ones that could not be applied — the platform would rather show a gap than a clean-looking pass.

See it

Watch an agent run a stage

Open a project, pick a stage, and watch the proposal-to-evidence loop do the work.

Open the workbenchTalk to Lumicule