Circuit Optimization Documentation¶
This site is the maintained documentation for Circuit Optimization. It is organized for three audiences:
- Users who want to install the project, run an existing circuit, and create circuit JSON files.
- PDK integrators who need to understand model bindings, external toolchains, process corners, and backend limitations.
- Developers who need the solver architecture, extension points, tests, and release checks.
Start Here¶
- Getting Started: install with
uvorvenv, run the passive smoke test, and choose optional dependencies. - CLI Reference: analysis, exploration, corners, mismatch, ADC, plotting, dataset, and service commands.
- Circuit JSON Format: the maintained field-level reference for circuit descriptions.
- Signoff Campaigns: multi-testbench PVT execution and strict worst-case aggregation.
- PDK Support Matrix: model keys, prerequisites, supported analyses, corner names, and accuracy boundaries.
Learn the Internals¶
- Core Solver Overview: data flow, model abstraction, MNA/Newton solvers, transient integration, periodic analyses, optimization, and service layers.
- Developer Handoff Guide: repository map, test strategy, extension workflow, and documentation maintenance rules.
- Local Service API: FastAPI endpoints, background jobs, serialization, and CLI equivalence.
- MCP Server: LLM tools, resources, background signoff jobs, client configuration, and workspace security.
- ngspice Oracle Helpers: explicit external-reference paths used by FreePDK45 and TSMC regression workflows.
PDK Guides¶
Foundry model payloads are local inputs. They are not part of the repository, must remain Git-ignored, and remain subject to their original license terms.
Design Records¶
Design Cases and Validation Status separates reproducible examples from incomplete campaigns and historical engineering notes. A design record documents one experiment; it is not automatically a release-wide accuracy guarantee.
Reference Documents¶
| Document | Purpose | Maintenance status |
|---|---|---|
| Getting Started | Installation and first run | Maintained |
| CLI Reference | Current command-line interface | Maintained |
| Circuit JSON Format | Circuit schema and examples | Maintained |
| Signoff Campaigns | Multi-testbench PVT signoff manifests and output | Maintained |
| PDK Support Matrix | Backend and process capability boundaries | Maintained |
| Core Solver Overview | Implementation architecture | Maintained |
| Local Service API | HTTP and job API | Maintained |
| MCP Server | LLM tool and resource protocol | Maintained |
| TSMC28HPC+ Adapter | Licensed local model integration | Maintained |
| Licenses and Third-Party Software | MIT scope, BSIM4 attribution, and vendored-code terms | Maintained |
| Environment and Performance Notes | Dated benchmark snapshots and tuning notes | Reference snapshot |
| Design Cases | Design-specific derivations and results | Per-case status |
The release history is maintained in the repository CHANGELOG. Licensing and attribution details are maintained in Licenses and Third-Party Software.
Documentation Policy¶
- Commands in maintained guides must correspond to current
--helpoutput. - Capability claims must distinguish the local solver, an external oracle, and sign-off tooling.
- Result tables must identify their source file and coverage. Partial PVT data must not be described as a completed campaign.
- Roadmaps and completed implementation plans do not belong in the user-facing documentation. Durable implementation details are folded into architecture or PDK guides.
- The JSON schema in
schemas/circuit.schema.jsonand the loader are the source of truth when prose and code disagree.