Time-Domain System EquivalentLinear dynamics, solved faster.Discuss IntegrationTechnology
TDSE converts a reusable linear time-invariant subsystem into runtime operator terms, then lets the host solver integrate those terms inside its own time-stepping loop. The host still owns the trial solve, commit sequence, lifecycle policy, and shutdown behavior. TDSE supplies operator data and step-loop terms; it does not take over the host integrator.
What TDSE Does
TDSE is most useful when a model can be partitioned into a reusable linear time-invariant subsystem and a host-solved nonlinear or time-varying remainder. In that setting, the live step loop stops reopening the reusable subsystem and starts consuming precomputed operator terms instead.
When the host keeps reopening the same linear subsystem every accepted step, repeated factorization or solve work can dominate runtime. The exact cost depends on solver structure, sparsity, and coupling, but the reusable part is still being revisited inside the live step loop.
TDSE moves that reusable subsystem behavior into precomputed response data and runtime operator terms. At each step, the host queries `op`, `hr`, and `ir`, solves its own equations as usual, and commits the accepted state without reopening the reusable subsystem.
How It Works
The SDK path has four distinct stages. What matters is not just the math, but the ownership boundary: partitioning happens upstream, Builder prepares reusable operator content, Runtime exposes step-loop terms, and the host remains responsible for integration policy.
Decide which portion of the coupled model is linear, time-invariant, and worth reusing across accepted steps. This partition is a modeling decision made upstream of the SDK; TDSE assumes that boundary is already defined when response data enters the toolchain.
Generate the independent-response and impulse-response content that describes the reusable subsystem at its interface ports. Builder accepts time-domain or frequency-domain response inputs, and Adapter Circuit can supply that data directly for supported circuit-domain workflows.
Builder turns those response artifacts into a causal runtime representation and writes a pack file. The pack preserves the operator content, response-history support, and metadata the Runtime layer needs at create time.
Runtime exposes the step-loop terms `op`, `hr`, and `ir`. The host still owns time stepping, trial versus commit sequencing, and shutdown policy. TDSE contributes reusable operator terms; it does not replace the host solver.
Equation Form
At runtime the host does not re-open the reusable linear subsystem. Instead it evaluates an equivalent relation built from an independent-response term, a retained-history term, and an instantaneous coupling term. Those are the pieces surfaced by the Runtime API and consumed by the host step loop.
Precomputed free-response content carried into the current accepted step.
Convolution over retained port history accumulated from previously committed steps.
Instantaneous coupling term aligned with the host solver's current trial state.
The New Scaling Law
Once reusable subsystem dynamics move into operator form, the dominant runtime work shifts toward interface dimension, retained history, and host-solver coupling. That does not erase the host solve, but it changes what portion of the total work remains inside the live loop.
In simplified form, the reusable-subsystem contribution scales like
Np is the number of exchanged port or interface variables. Runtime work grows with interface dimension rather than with the full internal size of the reusable linear subsystem.
Nh is the retained response-history length. Truncation, history retention, and host integration policy directly affect convolution workload and therefore the amount of reusable-subsystem work performed each step.
The scaling expression describes the reusable-subsystem portion of the step loop, not the entire simulation stack. Realized gains still depend on the host solver, memory traffic, scheduling, backend selection, and how the integration boundary is chosen.
What Makes It Practical
The theory is only useful if the response source, reconstruction path, and host integration behavior still hold up under real runtime conditions. These are the constraints that decide whether the method remains trustworthy once it leaves the derivation and enters product code.
Response Sources
Builder can start from time-domain or frequency-domain response data and normalize it into the same runtime operator form. For supported circuit workflows, Adapter Circuit can provide that response content directly from imported netlists or RAW-based inputs.
Causality
Frequency-domain characterization can produce response sequences that look acceptable offline but misbehave inside a live integrator. TDSE applies causality-aware reconstruction and correction before the pack reaches Runtime, so the host consumes a runtime-ready operator rather than raw sampled data.
Host Compatibility
Runtime can serve fixed-step and variable-step hosts, but the host still owns trial, commit, and lifecycle sequencing. The practical requirement is not just mathematical correctness; it is that the operator terms remain well-behaved inside the host's accepted integration pattern and step-size policy.