Review circuit simulation

Review Circuit Simulation

Use OpenADA's shared circuit-simulation operation as the execution boundary. Reason about the engineering question above that boundary, without teaching the workflow a simulator-specific CLI or log grammar.

Frame the decision

State the exact question before running anything. Keep these claims separate:

1. Execution: Did the selected simulator run to completion?
2. Evidence validity: Did the run produce fresh, structurally valid, finite evidence for the requested analysis under the shared operation profile?
3. Series extraction: Were exact native vectors bound to a canonical real series through openada.operation/result.series.extract/v1alpha1?
4. Derived simulation result: What supported scalar can be derived from that series?
5. Specification: Does that derived result meet an explicit limit?

The simulation profile can establish the first two claims. Compose the separate typed extraction, scalar-result, and specification operations only when their exact profiles are available. Require explicit selectors, scalar-result definitions, limits, units, corners, and model context before judging a design specification. Never upgrade valid simulation evidence into “the circuit works.”

Check applicability

openada.operation/circuit.simulate/v1alpha2 is the only simulation operation and covers every form the request can arrive in: a bare deck or a published Simra artifact, a model-free deck or one bound to an installed PDK by name, one declared analysis or several. Require openada.feature/simulation.analysis.<type>/v1alpha1 from the selected driver; Xyce does not advertise OP.

A model-free deck must still be self-contained: one top-level OP, DC, AC, or transient analysis with parseable closed parameters and no includes, native .measure directives, print directives, control blocks, or additional analyses. Model collateral is supplied as configuration - --pdk for an installed PDK, --models for a flattened card file - and never pasted into the deck. Never fall back to a raw native command while claiming comparable OpenADA evidence.

Identify the exact netlist and a fresh task-local evidence directory. Treat design files, models, and PDK collateral as read-only. Do not substitute a model, corner, library, or testbench to obtain a passing run.

Select the backend explicitly

Honor a backend named by the user. Otherwise inspect available capabilities, select a supported open-source backend deterministically, and state the choice. Do not retry through a second backend merely because the first produced an engineering failure. A comparison across backends is a separate, explicit request.

Run the same semantic operation through the selected backend:

openada simulate /absolute/path/to/testbench.cir \
  --backend ngspice \
  --output-dir /absolute/path/to/evidence

The target may equally be a published schematic.artifact.json; add --pdk <id> --pdk-root <dir> when the deck names devices rather than carrying model cards. Use --backend xyce with the same shape when Xyce is the selected capability. Resolve the openada executable through the plugin's OpenADA execution skill. If OpenADA or the requested backend is unavailable, report it as unavailable; do not manufacture an engineering conclusion from an alternate tool.

Interpret normalized evidence first

Read these result fields before opening native logs:

• execution.status for invocation and process completion;
• engineering.status for the fixed simulation-evidence assertion;
• data.protocol, data.analysis, and data.evidence for normalized facts;
• diagnostics for bounded failure or uncertainty routing;
• inputs, artifacts, and provenance for source and evidence identity.

Route the result as follows:

Result	Engineering interpretation	Next action
execution completed, engineering pass	Fresh finite requested-analysis evidence is valid	Bind exact requested native vectors through result.series.extract, then invoke only a supported result-operation profile
execution completed, engineering fail	Valid evidence supports the profile's engineering failure	Diagnose the reported convergence or waveform condition; do not switch tools automatically
engineering unknown	Evidence is absent, stale, malformed, incomplete, or uninterpretable	Resolve the cited evidence or provenance gap and rerun into a fresh directory
invalid request	The target is outside the shared profile or malformed	Correct the request without weakening the intended assertion
backend unavailable, timeout, or invocation failure	No engineering conclusion is supported	Repair capability or execution state, then rerun the same intent

Treat native logs as drill-down evidence, not as a second source of contract semantics. Preserve a normalized unknown even if a log line appears optimistic.

Compare backends only when asked

For an explicit backend comparison:

1. Hold the exact input bytes and operation profile fixed.
2. Use separate fresh evidence directories.
3. Record each backend identity and version.
4. Compare normalized assertion status, analysis kind, vector names, finite sample validity, diagnostics, and provenance limitations.
5. Report native artifact differences separately.

Do not require byte-identical waveform files, point counts, or logs. Those are backend representations, not the shared semantic assertion. A disagreement in normalized status is a conformance investigation, not evidence that the more favorable result is correct.

Report the engineering decision

Return a compact review containing:

1. the question evaluated and the strongest supported conclusion;
2. execution status and engineering status as separate facts;
3. selected backend, native tool version, operation profile, and target;
4. material diagnostics plus artifact paths and hashes;
5. assumptions and provenance limitations;
6. one smallest justified next engineering action.

Label derived-result or specification satisfaction as not evaluated unless a separate explicit contract and its required evidence were actually applied.