Characterize analog block

Characterize an Analog Block

Act as the characterization coordinator. Turn the application and specifications into the smallest justified sequence of OpenADA intents, then delegate focused reviews to the other engineering skills. Use $openada:openada for capability discovery, invocation, and result interpretation. Keep native design data, testbenches, PDKs, models, and artifacts authoritative.

Preserve the contract ladder

Keep these conclusions separate at every step:

Layer	Exact semantic boundary	Strongest allowed conclusion
Analysis evidence	openada.operation/circuit.simulate/v1alpha2 with openada.assertion/simulation.evidence.valid/v1alpha1	The requested OP, DC, AC, or transient analysis produced valid evidence, or conclusively did not converge
Series extraction	openada.operation/result.series.extract/v1alpha1 with openada.assertion/series.extraction.valid/v1alpha1	Exact native vectors were bound to a canonical real series with verified artifact lineage
Scalar simulation result	openada.operation/result.measure/v1alpha2 with openada.assertion/measurement.valid/v1alpha1	The declared metric was validly extracted from identified source evidence
Spectral simulation result	openada.operation/result.spectral.measure/v1alpha1 with openada.assertion/spectral.measurement.valid/v1alpha1	One declared coherent SNR, SINAD, THD, or SFDR ratio was validly derived
AC transfer simulation result	openada.operation/result.transfer.measure/v1alpha2 with openada.assertion/transfer.measurement.valid/v1alpha1	One declared gain, driving-point impedance, bandwidth, unity-frequency, or negative-feedback phase-margin scalar was validly derived, over single-ended or differential operands
Oscillator simulation result	Experimental openada.operation/result.osc.measure/v1alpha1 with openada.assertion/oscillator.measurement.valid/v1alpha1	One declared same-window oscillator transient has a typed sustained/non-result verdict, or complete transient receipts were validly composed into local Kvco, span, or perturbation shift
Specification	openada.operation/specification.evaluate/v1alpha1 with openada.assertion/specification.satisfied/v1alpha1	The declared simulation result satisfies or violates the explicit limit under its recorded conditions
Signoff	Outside these assertions	Only a separately qualified flow and accountable reviewer may make a signoff claim

Never promote a lower layer into a higher one. In particular, simulation engineering.status: pass is not a performance pass, and simulation engineering.status: fail is the profile's defined solver failure rather than a failed design specification.

Freeze the design context

Create or update a compact context ledger before selecting analyses:

• Decision: application class, block role, design phase, topology, loop or sampled-data structure, and the immediate engineering question.
• Technology: exact PDK/model identity, process or device family, supply and body domains, temperature range, and pre-layout or extracted representation.
• Conditions: stimulus, source impedance, common mode, load, clocking, startup state, corner, and any enabled modes or paths.
• Specifications: metric, limit or interval, units, condition, priority, tolerance, and source of authority. Keep goals distinct from approved limits.
• Evidence: target and configuration identities, prior request/result IDs, artifact hashes, simulation-result definitions, and known provenance gaps.
• Unknowns: assumptions whose resolution could change the testbench, analysis, simulation result, or conclusion.

Do not fill missing values with conventional numbers or substitute collateral. Ask one narrow blocking question when multiple authoritative choices remain.

Resolve the engineering question before selecting a tool

Read references/qualitative-reasoning.md when the question depends on a schematic, switched phases, parameter scaling, or a device-sizing tradeoff. Use its topology, interval, dependency, and limiting-case checks to produce one explicit qualitative claim before planning an analysis.

Classify the claim as one of:

• source-derived: follows from the supplied topology, stated assumptions, and symbolic device relationships;
• evidence-testable: an authoritative target, models, conditions, and a supported OpenADA operation can test the same claim;
• not evaluable: missing topology, state, model, condition, or semantic capability could change the conclusion.

Do not create a netlist, choose device parameters, or invoke a simulator only to make a qualitative question executable. If the claim is source-derived but not evidence-testable, answer at that level and identify the missing evidence boundary. Do not describe algebra, visual inspection, or a hypothetical testbench as OpenADA evidence.

Inspect capabilities before planning execution

Inspect the selected driver's complete operation, assertion, and feature IDs. For circuit simulation, require the exact advertised analysis feature:

• openada.feature/simulation.analysis.op/v1alpha1
• openada.feature/simulation.analysis.dc/v1alpha1
• openada.feature/simulation.analysis.ac/v1alpha1
• openada.feature/simulation.analysis.tran/v1alpha1

Run openada capabilities, then use openada profile show OPERATION_PROFILE_ID to inspect the installed parameter schema before constructing result-operation or specification requests. Use semantic metric names in the characterization plan, but do not invent result-operation parameter names, backend expressions, or feature IDs that the installed profile does not define.

If an operation, feature, locator, or transport is unavailable, mark that row not evaluated — capability unavailable. Do not bypass OpenADA with a native command and then describe the result as contract evidence. A native executable being installed does not itself make a semantic capability available.

Build the characterization matrix

Read references/application-recipes.md after identifying the application class. Adapt a recipe to the actual circuit; do not force an unfamiliar block into the nearest label. Then read references/intent-routing.md and map only rows whose required primitives are actually implemented.

For every proposed metric, record:

Field	Required content
Question	The design decision this metric informs
Testbench	Exact authoritative target and mode
Conditions	Supply, stimulus, load, clock, corner, and temperature
Analysis intent	One supported circuit.simulate analysis feature
Simulation result	Semantic metric and source signals, units, interval, and method
Specification	Explicit bound and condition, or not supplied
Dependencies	Earlier gate or specialist skill that must complete first
State	planned, pass, fail, unknown, unavailable, or not evaluated at the appropriate layer

Compile each row into an immutable intent ledger before execution:

Ledger field	Required content
Row identity	Stable characterization-row ID and immediate engineering question
Semantic request	Exact operation, assertion, required feature, target, configuration, parameters, and evidence destination
Prerequisites	Authoritative choices and prior row/result identities required before dispatch
Evidence binding	Request ID, result ID, native artifact path/hash, canonical series hash, and operating conditions as each becomes available
Layer status	Separate analysis, extraction, simulation-result, and specification state; never one blended pass
Blocker	One missing authority or capability and the smallest action that resolves it

Do not rewrite an executed row in place. If a target, model, condition, method, or limit changes, append a new row revision and preserve comparability.

Order the matrix by dependency, not by convenience:

1. Prove target, configuration, and baseline identity.
2. Run nominal OP evidence first and use a supported result operation to derive the simulated bias/headroom facts needed by the topology.
3. Run DC sweeps needed to establish range, transfer, or regulation behavior.
4. Run application-specific AC or transient analyses only after their gates are meaningful.
5. Expand into specialist reviews and then PVT/statistical coverage only after nominal behavior is plausible.

Invoke one primary assertion per operation. Use fresh evidence destinations and preserve lineage from analysis artifacts to simulation results and specifications. Retain the passing extraction envelope beside downstream results: the extraction assertion verifies the native binding, while the immutable result-operation profiles continue to label embedded native lineage as unverified.

Execute one ready intent

Select the first dependency-ready ledger row, not the easiest metric. Execute only its next unproven layer:

circuit.simulate
  -> result.series.extract when a native vector is needed
  -> result.measure, result.spectral.measure, or result.transfer.measure
  -> specification.evaluate only when an authoritative limit exists

circuit.simulate
  -> result.series.extract
  -> experimental result.osc.measure
     (no specification.evaluate/v1alpha1 oscillator-receipt adapter)

Preferred: a typed experiment against a DUT artifact. When the block is a published Simra DUT schematic (no sources, no ground instance, artifact lifecycle.state: "simulation_candidate"), describe the whole characterization step as one simra.experiment/v1 JSON — DUT bundle digests and port connections; fixture elements with kinds exactly vdc, idc, vpulse, ipulse, vsin, isin, vpwl, ipwl, resistor, capacitor, inductor; analyses with ids; observations; exact typed measurement requests; and "conditions": {"pdk": {"id": "<pdk-id>", "corner": "<corner>"}} — and run the full chain in one command:

openada experiment run experiment.json --pdk <pdk-id> --output-dir <evidence-dir>

It validates the whole document before anything simulates (every refusal names the exact JSON path — fix the named field, never work around it), then simulates each analysis, extracts every observation, runs every measurement, and retains the complete typed chain including the request preimages. Propagation delay is a derivations entry subtracting two same-analysis crossings; there is no primitive delay kind.

Legacy: a drawn testbench artifact. circuit.simulate still takes the block in whatever form it arrived. Hand it a published Simra testbench artifact and it verifies the digests, splits a multi-analysis testbench into one deck per declared analysis and binds an installed PDK; hand it a bare deck and it does the same without the split:

openada simulate <path>/schematic.artifact.json \
  --pdk <pdk-id> --pdk-root <pdk-root> --output-dir <evidence-dir>

Name the technology; never write it into the deck. Devices are canonical roles (nmos.core, .svt / .lvt / .hvt / .io) with SI geometry, and the driver owns the model vocabulary, instance prefix, parameter spelling, geometry units, library prelude, corner and any Verilog-A preload. Run openada simulate --help for the PDKs it can bind, and pass --corner only when the request names one. Do not edit the published deck to suit a PDK: a deck that had to be edited is no longer the artifact whose digests the result binds, and a deck carrying pre_osdi or a PDK .lib is refused with pdk.collateral.hand_bound.

Never hand-write model cards to get past a failed bind. An invented .model line is not the PDK however closely its name matches a real device: it substitutes different physics for the foundry's while still looking like a credible simulation result. Report the bind failure instead.

Record the result before scheduling another intent. A simulation pass advances only to extraction; an extraction pass advances only to its declared result operation; a result-operation pass advances to specification evaluation only if the row already carries a bound. Stop at the first unknown, unavailable capability, or missing authoritative choice and ask one narrow question.

Compose focused skills

• Invoke $openada:analyze-feedback-stability for differential, common-mode, nested, feed-forward, or regulator-loop questions after the DC gate.
• Invoke $openada:analyze-spectral-linearity for FFT, harmonic, SFDR, sampled-data, or waveform-linearity questions after transient evidence is valid.
• Invoke $openada:assess-pvt-and-yield only after nominal analyses, simulation-result definitions, and specification limits are frozen.

Do not duplicate their metric rules inside this coordinating workflow. Accept their blocked or unknown result as a characterization state, not as an excuse to skip the metric.

Route each result honestly

Observed state	Next action
Analysis evidence pass	Request only supported result operations bound to that exact evidence
Series extraction pass	Use only the emitted canonical series and exact selector/condition ledger
Series extraction unknown	Repair native artifact, plot, selector, component, unit, or digest binding
Analysis evidence fail	Retain the conclusive solver evidence and diagnose that failure before interpreting performance
Analysis evidence unknown	Resolve the cited request, provenance, freshness, or structural gap and rerun the same intent
Result-operation pass	Evaluate an explicit specification if one exists
Result-operation fail or unknown	Repair the result-operation definition or evidence; do not classify circuit performance
Specification pass or fail	Record the result only for its exact condition and limit
Any required capability unavailable	Preserve the gap as not evaluated and propose the smallest missing semantic primitive or capable driver

Report the next engineering decision

Return:

1. the immediate engineering claim, its assumptions, and whether it is source-derived, evidence-testable, or not evaluable;
2. the frozen context and unresolved assumptions;
3. the ordered characterization matrix and coverage by contract layer;
4. per-run backend identity, exact profile/feature, result status, diagnostics, and artifact lineage;
5. simulation results and specification results without collapsing their statuses;
6. application-specific open risks and unsupported primitives;
7. one smallest next experiment that can change the decision.

End with signoff: not claimed unless an external, explicitly qualified signoff process has been supplied and reviewed. OpenADA evidence can support that review; these skills do not confer signoff authority.