Simulation

Simulation evaluates a model of a circuit under specified conditions. A completed run or visible curve is an observation, not universal engineering approval.

Before You Start

Open the intended schematic and save the intended design. Check the active project, sheet hierarchy, and fitted variant. Resolve known ERC/connectivity issues separately; ERC and simulation answer different questions.

Define actual supply voltages, stimulus, loading, analysis range, and any acceptance limits. A rail label or decoupling capacitor is not a supply source. Missing conditions must remain a named gap, not be filled with guessed voltages.

Supported models must match the exact component, package/unit association, and pin mapping. A manufacturer model can remain provisional even after its source and pins are checked; it is not automatically qualified for every analysis or operating condition.

Choose the Right Model

Start with what the saved design already defines:

• Passive primitives: resistors, capacitors, and inductors use their specified values; they do not need a vendor-model search merely to run.
• Generic transistor-level models: compatible native builds can run supported diode, BJT, MOSFET, and JFET models defined in the symbol's simulation properties. These are useful for teaching and explicit generic experiments, not exact-MPN qualification.
• Project-library models: a part already referencing a usable Sim.Library and Sim.Name can be inspected and run without installing a second model.
• Vendor or user models: inspect the exact model, its declared terminals, and current symbol association before installing. A download or cache hit is not installation success.

For generic MOSFETs, use explicit, justified parameters rather than an empty Sim.Params field. Default level-1 parameters can produce unrealistic thresholds and switching. Do not apply guessed values to a real part and then present the result as manufacturer behavior.

Inspection can report built-in or project-library models as runnable while still listing their behavior as not evaluated against a qualified compatibility row. This is a model-evidence limitation, not necessarily a missing-model error.

Install a User-Supplied SPICE Model

In a compatible native schematic session, use a chat model attachment, a project file, an artifact, or pasted model text.

1. Save the intended schematic and identify the exact component, package, source, and model name if known.
2. Ask Trace to inspect the supplied source. If it contains several models, choose the intended declaration; check its ordered terminal list.
3. In Agent, request installation for the current symbol. Review the pin map, multi-unit/power-unit association, and any required include files.
4. Wait for the installation outcome, then reinspect the saved design and the same intended experiment.
5. Keep the result identified as user-supplied and provisional. Do not hand-edit installer-managed model records to bypass a refusal.

A ZIP must contain the required supported model graph, not merely one file that refers to missing dependencies. Installing a supplied model does not modify it into universally qualified evidence.

Vendor Compatibility and Translation

Supported plain-text .MODEL and .SUBCKT declarations can describe diodes, transistors, and macro-models. Terminal identifiers and package pin numbers are different: inspect both before binding.

Trace can translate supported PSpice/LTspice constructs to ngspice-compatible text and report the changes. Read that report before interpreting results. A translated switch, for example, can use abrupt threshold switching rather than the original smooth resistance transition; a documented temperature-input wrapper can impose a stated temperature assumption.

Translation is limited, not full vendor-simulator compatibility. Encrypted models, IBIS files, unsafe directives/archives, missing dependencies, and unsupported behavioral constructs can be refused. Some frequency-domain or integration/delay constructs are unsupported; a crystal can require its documented RLC equivalent. Read the named reason rather than finding another copy of the same incompatible model or substituting a different part.

Model syntax acceptance and a completed run do not establish startup, protection, noise, thermal, or all-condition accuracy. Noise and FFT are not available in this workflow.

Request and Follow a Run

1. In the schematic chat, state the behavior and conditions to evaluate, such as “Inspect this saved filter for AC response from 10 Hz to 100 kHz with the specified supplies, load, and 1 V small-signal input.”
2. Review the inspection's nets, models, stimulus, operating conditions, and readiness findings. Provide missing information before running.
3. Run the same inspected experiment, without silently changing its conditions or acceptance limits.
4. Follow progress to a terminal outcome. A run identifier or queued status means the request started, not that results are available.
5. Open the saved result and read the numeric observations, plots, warnings, and any evaluated assertions.
6. Compare the observations with the stated requirement and save/export evidence only through the supported controls.

With Automatic simulation review On, Trace considers model feasibility early and performs one grounded near-completion review when possible. It does not run after every edit. Explicit Off leaves this reactive; a direct simulation request still works. Older clients that omit the preferences retain legacy near-completion review, but not the On-only early feasibility guidance. See AI Workflows for global Preferences checkboxes and project chat overrides.

Open Saved Results

The native Simulation button opens the project's saved-run shelf, including when no run is selected. Use Refresh runs to update the list and select a saved run. Opening the shelf or viewer does not start a solver.

An assistant deep link must name an admitted run belonging to the current project. A missing, unavailable, or foreign run cannot be treated as an opened result.

For plots, use Expand plot, zoom/pan, Zoom out, and Reset zoom. Reset returns to the full plot; these controls change the view, not the saved samples or verdict. Use Show phase for supported AC traces.

Read the Analysis and Units

Operating Point (OP)

OP displays numeric node observations for steady-state conditions, not a time waveform. Check the actual DC sources and model assumptions. A result containing only solver constants does not evaluate the circuit.

Transient (TRAN)

Transient plots show signal versus time. Check the stimulus level, delay, duration, sample coverage, and units. A displayed curve may be reduced for presentation, so do not use the plot alone to prove that no narrow glitch exists.

AC Response

AC plots show frequency response to the specified small-signal stimulus. Voltage plotted as dB re 1 V (dBV) is not automatically transfer gain:

• 1 V magnitude is 0 dBV.
• 0.1 V magnitude is −20 dBV.
• Transfer gain requires a corresponding output/input ratio from the same run.

Magnitude is not phase; phase is undefined at zero magnitude. Use native numeric observations at the requested frequencies where available rather than manually pairing separate pages or rescaling units.

Digital and Mixed-Signal

Compatible native installations with qualified digital support can model supported logic behavior and propagation delays alongside an analog circuit. Check the session's simulation capabilities first; an unavailable or unqualified engine is not evaluated, not a reason to assume a digital result.

For an unmodeled logic part, ask the Agent to author a structured model from its exact pinout, function table, supply, and documented timing. Trace generates and checks that model before installation. Existing vendor or project models should be used when appropriate; a missing model is not permission to replace the user's symbol.

Describe the whole multi-unit package, even when only some gates are placed. The generated installation can omit unplaced units per component; review what was included. A function check evaluates the stated model claim, not the physical part under every condition.

Run a transient experiment with explicit supplies, input/clock pulse or piecewise-linear sources, duration, and sampling expectations. Digital results include transitions and step plots with logic units. U means unknown or uninitialized; it is not automatically a failure. Compare expected and observed levels and edge times, and name the parts using assistant-authored models.

These behavioral models do not establish drive strength, setup/hold timing, power behavior, or full threshold accuracy. MCU/FPGA pin stimuli represent only the assumed behavior you specify; they do not execute firmware or an HDL design. A waveform without evaluated assertions is not a verified design.

Review Warnings Before Running

Inspection can warn about an undriven supply, a floating net with no DC path to ground, or default-parameter MOSFETs even when the bench is otherwise runnable.

Check the intended circuit and bench before continuing. Provide actual external rails and inputs through bench sources when appropriate; any proposed CAD resistor, bias change, or model-property edit is a separate design decision. Do not add hardware just to silence a warning without checking the functional requirement.

After a convergence failure, follow its specific finding, such as a singular matrix or excessively small timestep. Repeating an unchanged failed bench is not a repair, and a source-less near-zero output is not proof that the intended powered circuit works.

Current, Historical, and Unknown Evidence

• Current: the saved design and relevant model/experiment identity still match the run. Currentness alone does not mean the requirement passed.
• Historical: the run belongs to an earlier design, variant, or branch. It remains useful history but cannot certify the current circuit.
• Unknown: currentness or required provenance could not be checked. This is not proof that the circuit changed, and it is not current certification.

Read provisional-model warnings separately from missing models or conditions. Not evaluated means there was insufficient evidence for a requirement. With no evaluated assertions, numeric results remain observations, not an asserted pass.

Engineering pass/fail assertions can be refused for provisional vendor, generic, or project-library models. Keep their limitations visible and use numeric observations without claiming a pass. When evaluated assertions are supported, use the original requirement's limits; never change a limit to fit the result.

Partial, cancelled, timed-out, failed, or worker-lost runs cannot be used as completed certification. A completed process with unusable or missing analysis vectors is not a successful behavioral evaluation.

Model Associations After Edits

Saved model bindings can outlive deleted, replaced, or newly self-modeled parts. Inspection can list them as skipped stale bindings; they do not necessarily block another model or affect the current run. A new part using an old reference is still a new part, not permission to reuse its predecessor's association.

A changed binding on a retained part is different. Reinspect the saved design and follow the reported recovery action: cached-model rebind, explicit reassociation, or reinstalling the same user/authored model for the current parts. A rewire alone need not reacquire model bytes.

Check the confirmed outcome and reinspect before running. Missing or corrupt assets, changed pin identity, editor/disk mismatch, and unknown installation delivery are different failures; reopening the project or downloading a different model does not resolve them automatically.

If It Cannot Run or Finish

• Missing model: identify the exact unsupported device. Use the supported lookup/install flow when available; do not remove it or substitute an unrelated model to force a run.
• Missing operating conditions: supply the actual rails, stimulus, and load. Independent subcircuits may be evaluated only when their isolation is established.
• Changed model association: reinspect the saved design and use the supported cached-model reassociation flow. Do not hand-edit model records or redownload a different part by default.
• Changed/unsynchronized design: reconcile the intended editor and saved files, then inspect the same experiment again. Do not overwrite newer files with a stale buffer.
• Resource or solver failure: read the specific time, data, point-limit, parse, or numerical finding. Budget exhaustion is not evidence of a slow macro-model or bad circuit by itself.
• Unknown delivery: inspect the original run/task status before retrying; do not assume an absent plot means no run started.

Finish with a bounded summary of what ran, what was observed, and what remains unevaluated. Simulation does not authorize physical hardware actions or prove fitted-board safety, thermal performance, EMC, or manufacturability.