1. Introduction
In standard hardware workflows, layout verification is often integrated directly into the layout router or schematic capture tool. When a system proposes routes, it queries its own design rules database. This tight coupling introduces risk: if a generative model is tasked with routing, it can silently relax clearances, modify board properties, or override rules in order to achieve a completed connection.
To bypass this vulnerability, OmeraCode introduces ClaimGuard. ClaimGuard is a sandboxed, isolated audit engine designed to run independently from generative layout models. It evaluates proposals from a purely critical perspective, checking design calculations and trace spacing against strict physical models.
2. Core Principles
- Isolation of Concerns: The validation rules, math equations, and check logic must run in a process separate from the co-design routing loop.
- Declarative Rules: Rules must map directly to explicit, documented parameters (e.g. IPC tables) rather than neural network weights.
- No Silent Bypasses: Any constraint violation must result in a build blockage. Bypasses are only permitted through human reviewer escalation.
3. Verification & Execution Pipeline
Requirement PDFs (e.g. TPS563200)
│
▼
[Constraint Extraction (NLP)] ──► Mapped Parameters (specs.json)
│
▼
[Isolated Math Solvers] ────────► Target Clearance & Width Limits
│
▼
[Design Rule Checks (DRC)] ─────► clearance, loops, & spacing checks
│
▼
[Human Review Escalation] ──────► Overrides & Sign-offs (reviews.json)
│
▼
[Evidence Pack Compiler] ───────► Signed Release Bundle (.epk)Step 3.1: Constraint Extraction
The system parses natural language specification sheets (such as datasheet PDFs and customer product requirements). It isolates numerical targets, tolerancing bands, and thermal boundaries, compiling them into specs.json.
Step 3.2: Solver Execution
Before checking layout tracks, ClaimGuard invokes deterministic solvers to verify that proposed trace widths, copper weights, and spacing parameters are mathematically viable.
For instance, if high-power nets are detected, ClaimGuard runs internal IPC-2152 solvers to establish minimum copper widths required for targeted currents under maximum thermal caps.
Step 3.3: Design Rule Checker (DRC)
Once mathematical compliance is verified, ClaimGuard imports layout files (Gerbers, netlists) to perform geometric checks:
- Trace Clearance: Validating trace-to-trace spacing against voltage clearances.
- Annular Rings: Auditing drill aspect ratios.
- Loop Areas: Reviewing power return paths to prevent electromagnetic coupling.
Step 3.4: Review Escalation & Override Handling
If a check fails (e.g., an island plane creates a small copper loop), ClaimGuard pauses. It writes a warning into the review log. The layout build remains locked until an engineer:
- Audits the finding in the review board.
- Formally override or mitigates the warning.
- Records the justification inside
reviews.json(such as adding thermal vias or modifying trace widths).
4. Known Limitations
ClaimGuard enforces strict technical bounds. It is not an omnipotent hardware validator, and we explicitly document its limits:
- No Replacement for Lab Testing: ClaimGuard audits parametric compliance on schematic and layout data. It cannot simulate manufacturer tolerance drift, component aging degradation, or physical lab stress testing (such as ESD or drop tests).
- Dependency on Requirements: If an engineering input is missing (e.g. current target is left undefined), ClaimGuard cannot infer the target. It will default to standard safety margins or flag the net as unconstrained.
- Supported Standards Bounds: Out-of-the-box checks are mapped to IPC-2152, IPC-2221, and standard IPC-6012 guidelines. Compliance checks for specialized automotive or military standards require team configuration.