Implementation Workspace — automated design review
Video transcript
00:08 — The review sits on the product
Most design reviews happen in a meeting room, with a printed schematic and whatever the reviewers remember of the requirements. In Creopus, the review sits on the board’s own place in the product, beside its requirements and its DFMEA. You upload the whole KiCad project, exactly as your team keeps it. The worker runs KiCad itself: its electrical and design rule checks, the netlist, and a 3D model of the board.
00:39 — Rules first, then judgement
Then the platform’s own checks run: rules that either fire or they don’t, and the patterns experienced engineers look for by habit. Only then does the AI review run, grounded in this board’s requirements and its DFMEA. Each finding names the check that raised it, and the requirement or DFMEA row it concerns. Here, the boost converter draws its power through the 5 volt regulator: the very load the DFMEA warns could overheat it. And a finding is settled like a review comment: accepted, rejected or deferred, with the reason, the name and the date kept on record.
01:23 — Findings, on the board
Open the board, and the findings are drawn where they are, beside the parts they name. Zoom in, and each marker shows the finding it stands for. And KiCad’s own 3D model of the board is a click away.
01:44 — Heat, against the requirement
Next, the heat. For each part that warms the board, declare the power it dissipates, and a junction to board resistance where the datasheet gives one, and the worker models the board in Elmer, a finite element solver. Back comes the temperature under every loaded part, and the heat map lies over the board layers. Bind the run to the board’s temperature requirement, and it becomes evidence: within its limit.
02:18 — The enclosure
Then the enclosure. Upload its STEP model, and the worker measures it and checks the board’s mounting holes against it. One hole is a millimetre out, and the finding names both holes it could be, before a single part is made.
02:37 — Signed off, with the evidence
Back at the requirements, the temperature limit now reads checked, for the four parts that carry heat, and it waits for a person to sign it off. Accept it, and it counts as verified, with the engineer’s name and the date on record. And the whole review exports as a controlled document. A design review in minutes, with the evidence attached.
What it does
Every other tool in Creopus helps you produce a document. The Implementation Workspace does the opposite: you upload the design you have actually built — schematic netlist, PCB layout, SPICE deck — and it reviews it, producing structured findings against your own requirements and DFMEA.
It is a second pair of eyes that has read your requirements, at three in the morning, without getting bored on page forty.
Why it matters
Design review is where hardware teams lose the most time and catch the fewest problems. A senior engineer reads a schematic for an hour, spots six things, and misses the missing decoupling cap on page four because nobody can hold a whole board in their head.
The reviews that scale are the boring, deterministic ones — is every net driven, is the annular ring above the fab's floor, does the .tran window actually cover the RC time constant. Those should never have needed a human. What a human is genuinely good at is judgement, and judgement is what is left once the mechanical checks are done.
This is also the part of Creopus that no requirements tool does. Requirements platforms manage text about your design; layout tools work on the design but have never read your requirements. The Implementation Workspace sits in between.
What it reads
It takes the files you already have rather than asking you to export something special:
- Schematic — KiCad (schematic sheet, netlist export, legacy EESchema netlist), Altium
.SchDoc, Protel / Altium ASCII netlist, OrCAD Net List Report, Qucs, LTspice, QSpice — or a schematic PDF or image - Layout — KiCad
.kicad_pcbor a whole KiCad project, Gerber (RS-274X, zipped), Excellon drill, ODB++, IPC-2581, Altium.PcbDoc - Simulation — SPICE decks (which can also be run in ngspice), Cadence Spectre
- Firmware — Arduino-ESP32 / ESP-IDF source, checked for the pins it configures against the board, plus the bring-up self-test log
- Mechanical — a STEP model (up to 20 MB) of the enclosure, to check the board fits
Format is auto-detected; an LTspice .asc is recognised by its records even without its version line. A Gerber package carries copper and outline but no footprints or nets, so it is not compared with the schematic part by part, and the review says so: upload the board file for those checks. If a file is misread you can override what it was read as, but the server checks the file again and refuses an override that disagrees with its contents. Large files go to object storage rather than into the document.
How the review works
Three layers, each doing what it is actually good at:
Layer 1 — deterministic rules. 34 schematic rules, 15 layout rules, 12 simulation rules. Floating nets, multi-driver conflicts, outputs tied to power rails, trace width below the floor, annular ring, copper-to-edge clearance, unrouted nets, model references that do not exist, transient analyses with no transient source. These either fire or they do not — reproducible, explainable, no model involved.
Layer 2 — curated patterns. 33 schematic, 26 layout and 8 simulation patterns encoding the things experienced engineers check by habit: LDO bypass caps, I²C pull-ups, crystal load caps, MOSFET gate resistors, decap proximity, via-in-pad, thermal-pad vias, mounting-hole isolation, real DRC clearance backed by spatial indexing, and copper pour imbalance computed from actual flood-fill area rather than an estimate.
Layer 3 — grounded LLM review. Only here does a model get involved. It needs the workspace linked to a hierarchy node, and it grounds in that node's requirements, DFMEA, block diagram and BOM when they exist; without them it reviews against general best practice. It is asked to judge whether the implementation actually realises what those documents promised — the question a deterministic rule cannot ask.
There is also a cross-artifact pass that checks the schematic, simulation and layout against each other: do the references match, does the sim exercise the circuit that was drawn, does the layout implement the schematic.
On a board, the workspace also runs board-level checks:
- Impedance is judged against the stackup the board file states (IPC-2581, ODB++, or Allegro fabrication notes), or against the node's designed stackup from PCB Layer Stackup when the file states none.
- Net assumptions — declare currents, voltages, and which nets are reset or enable lines, so the checks judge each net by what it actually carries.
- Thermal — a modelled, steady-state heat map shown on the board layers.
- Mechanical fit — the board and its mounting holes checked against the enclosure's STEP model.
What you get back
Findings, each with a severity (critical / major / minor / editorial), a category, the layer that produced it, a location, a recommendation, and a discipline tag (electrical / layout / mechanical) so the right person sees the right subset.
A real run against an 11-component, 14-net flight-computer schematic: 19 findings in a few seconds, 12 from deterministic rules and 7 from curated patterns. F-8 caught a resistor with one pad floating; F-14 caught an I²C net with no pull-up — an open-drain bus that would simply never communicate. Filter by discipline so layout engineers are not reading electrical findings, and dispose of each one like a review comment.
Findings are dispositioned like review comments — open → accepted / rejected / deferred / noted, with reason and audit fields — and each carries its own comment thread, so the EE-to-layout conversation lives with the finding instead of in a chat log. Findings can link to the specific requirement or DFMEA failure mode they relate to.
Re-uploading a design reconciles its findings into resolved, still open and new, so you can see what a revision fixed. Results can also be bound as evidence to a requirement or a DVP analysis test.
You can add findings by hand too. A manual finding is marked as human-authored, and that provenance survives editing, so "did a person or the machine flag this?" always has an answer.
Getting started
Create an Implementation Workspace on the hierarchy node whose design you are reviewing — the node context is what makes Layer 3 useful. Upload a schematic first; Layers 1 and 2 run immediately. Then run the AI review from the workspace (a layout review takes about 5–15 seconds). Add the layout, simulation, firmware and mechanical model as they exist, and the cross-artifact checks become available once you have more than one.