Keep the host solver stack
TDSE™ SDK is built to enter an existing simulation program without displacing it. The host solver still owns time stepping, acceptance policy, nonlinear updates, and the surrounding system assembly.
TDSE™ SDK
A reusable operator layer forexisting simulation platforms.
TDSE™ SDK is for teams that refuse to keep re-solving the same reusable subsystem inside an already mature simulation stack. It does not ask the customer to abandon the host simulator. It turns reusable subsystem dynamics into a controlled product surface, with named SDK components and explicit ownership rules, so evaluation can focus on runtime control, deployment fit, and long-term operational confidence.
Why Teams Evaluate It
Can this change the runtime model without forcing a rewrite?
That is the real threshold question. TDSE™ SDK matters because it does not require a new simulator, a new domain solver, or a hidden runtime model surface. It offers a bounded path from reusable subsystem data to runtime execution inside the stack the customer already trusts.
Evaluate one bounded subsystem first
A first pilot can focus on one reusable subsystem with a clear interface, rather than demanding a platform-wide migration. That keeps the evaluation ambitious in effect but bounded in scope.
Own the runtime behavior explicitly
The SDK exposes a runtime contract that can be inspected, tested, and logged. That is a much stronger posture than adopting an opaque extension and hoping its runtime behavior will stay explainable under pressure.
What The SDK Includes
TDSE Adapter Circuit, TDSE Builder, and TDSE Runtime form one deliberate boundary.
These names are not branding decoration. They define the real product boundary. Customers should be able to say, without ambiguity, where domain preprocessing ends, where pack construction happens, and where runtime execution begins.
The domain-facing layer for netlist input, region definition, port and probe resolution, circuit solves, and validated Y / Z / VOC / ISC artifacts.
The pack-construction layer that converts spectra into H, attaches optional IR, applies Builder-side conditioning, and writes the runtime pack.
The execution layer that loads the runtime pack, exposes stable per-step semantics, and evaluates operator content inside the host simulation loop.
Core Advantages
The strongest advantages are about control, supportability, and deployment confidence.
A serious technical evaluation does not stop at raw capability. It asks whether the integration will stay stable to own, understandable to debug, and practical to deploy at scale. Those are the dimensions where the SDK is strongest.
Pack InputRuntime Pack
Host Solver Loop
BeginEvaluateCommit
Time stepping, acceptance, and surrounding system assembly stay with the host.
Runtime RoleOperator Evaluation
Reusable subsystem dynamics are evaluated inside the loop, not outside it.
Explicit runtime contract
TDSE Runtime follows a clear begin, evaluate, and commit pattern. Trial-side evaluate calls are side-effect-free, and commit is the only state-advancing operation. That makes host-side retry, rejection, and step ownership easier to reason about when the runtime is under real production pressure.
Operationally stable execution model
The repository hardens runtime behavior with CI-gated contracts such as single large history-operator execution per step, no per-step dynamic allocation, strict IR ingestion boundaries, and pack compatibility gates. That is a stronger statement than a generic claim of runtime stability because the behavior is locked, observed, and continuously checked.
Supportable diagnostics surface
The SDK exposes create-time diagnostics, model info, state info, last-error snapshots, and step-aligned failure reporting. For procurement and long-term support, that matters because the integration can be audited, explained, and defended rather than merely exercised.
Clear ownership under concurrency
The runtime contract makes same-handle concurrency rules explicit. One live runtime handle belongs to one execution lane at a time unless the host adds synchronization on purpose. That keeps thread-safety decisions visible instead of accidental, which is exactly what serious infrastructure teams want.
Performance And Deployment Foundations
Performance claims matter only when the execution and packaging story is real.
The right way to present performance-related advantages is not as a vague promise of speed. It is to show that the execution model, dependency stack, and deployment artifacts are already productized in a way teams can evaluate concretely.
Parallel-ready architecture
The runtime distinguishes handle-level ownership from internal execution strategy. One handle per execution lane remains the contract, while local threaded execution and backend selection remain internal execution choices rather than hidden API behavior.
CPU, sparse, and CUDA paths
The repository already productizes multiple execution and solve paths, including CPU-oriented targets, optional SuiteSparse/KLU-backed sparse adapter solves, and optional CUDA-backed paths where the environment supports them. That gives evaluation teams a real performance roadmap instead of a hand-waved future promise.
Established third-party foundations
The build and packaging system explicitly supports OpenBLAS, optional SuiteSparse/KLU, and optional CUDA runtime dependencies. That is a more credible foundation than hand-written bespoke numerics with no packaging story.
Release-grade evidence
The SDK already carries install smokes, release-blocker evidence, variant manifests, provenance JSON, signing receipts, and bundle metadata. That matters to organizations that care about controlled deployment rather than just source availability.
What A First Pilot Looks Like
Evaluation work is real, but it is bounded.
A useful pilot is usually not a full product rewrite. It is a staged exercise that proves artifact preparation, pack construction, and host-loop execution on one representative case.
Existing StackHost Solver + Models
Keep the established simulation environment in place.
Pilot ScopeOne Reusable Subsystem
Define one clear interface and prove one end-to-end handoff path.
Evaluation OutputsPack + Diagnostics
Validate artifact correctness, runtime execution, and supportability together.
Choose one reusable subsystem
The best first case is usually not the biggest model. It is a subsystem with a clear interface, a trusted surrounding solver loop, and obvious reuse value across repeated studies. That is where the SDK can make its value unmistakable fastest.
Validate the artifact path first
Customers usually get better signal by proving the Adapter-to-Builder handoff and pack correctness before moving into broader runtime optimization or portfolio-scale deployment. If that path is solid, the rest of the evaluation becomes much easier to trust.
Decide who owns the integration boundary
A pilot moves faster when one team clearly owns region definition, port conventions, pack I/O, diagnostics capture, and runtime-handle ownership instead of distributing those decisions across several groups.
Use diagnostics as part of the evaluation
Because the SDK already exposes diagnostics and state snapshots, a serious pilot should evaluate supportability from day one rather than waiting until after the first runtime success case.
Who Should Evaluate First
The SDK is most relevant to teams that already own simulation infrastructure.
The first serious evaluators are usually not general end users. They are the teams responsible for model ingestion, solver extension, runtime ownership, and reusable simulation assets.
Simulation platform teams
Platform teams can use TDSE™ SDK as a reusable subsystem primitive with explicit ports, retained history, pack metadata, and a stable runtime contract that does not force a new core solver architecture or a clean-sheet simulator rewrite.
EDA infrastructure groups
Infrastructure owners can move from extracted or measured response data to transient-ready runtime assets without forcing one internal model structure across every SPICE, SI, or PI workflow. That is exactly the kind of leverage large EDA organizations look for.
Real-time integration teams
Teams working on deterministic execution can prepare reusable subsystem dynamics offline, then keep the online surface focused on pack load, operator evaluation, and host-step ownership instead of carrying the full subsystem online.
Solver extension projects
TDSE™ SDK fits programs that want response-based boundary elements inside an existing stack. The extension surface stays narrow: adapter-side artifact generation, Builder handoff, and runtime execution inside the host loop rather than a replacement runtime.