flowchart TB
Physical["Design, layout, material,<br/>and process declarations"]
Design["Design intent"]
EM["SCGSim<br/>Palace and other EM backends"]
Extract["C, L, and RLGC extraction"]
Circuit["Shared circuit model"]
Classical["SCNSim<br/>classical study"]
Canonical["Circuit-energy and<br/>canonical-coordinate route"]
EMModes["Normalized EM eigenmodes,<br/>energy, and junction mapping"]
Quantum["SCQSim<br/>quantum and control study"]
Intent["Shared study and control intent"]
EMExec["SCGSim-owned backend<br/>lowering and execution"]
ClassicalExec["SCNSim-owned<br/>lowering and execution"]
QuantumExec["SCQSim-owned<br/>lowering and execution"]
Instrument["Future experimental package<br/>instrument lowering, execution,<br/>and acquisition"]
Simulated["Simulated observables<br/>and performance"]
Measured["Measurements and<br/>calibration records"]
Compare["Comparison, model calibration,<br/>and sensitivity analysis"]
Revision["Evidence-backed, versioned<br/>design, model, and control<br/>revision proposals"]
Physical --> EM
Design --> Circuit
EM --> Extract --> Circuit
Circuit --> Classical
Circuit --> Canonical --> Quantum
EM --> EMModes --> Quantum
Intent --> EMExec
Intent --> ClassicalExec
Intent --> QuantumExec
Intent --> Instrument
EM --> EMExec
Classical --> ClassicalExec
Quantum --> QuantumExec
EMExec --> Simulated
ClassicalExec --> Simulated
QuantumExec --> Simulated
Instrument --> Measured
Simulated --> Compare
Measured --> Compare
Compare --> Revision
Revision -. reviewed update .-> Physical
Revision -. reviewed update .-> Design
Revision -. reviewed update .-> Circuit
Revision -. reviewed update .-> Intent
Full-Chip Quantum Analysis and Design Feedback
This page describes a future cross-package architecture, not the capabilities available today. It does not accept an API, schema, physical approximation, or automatic calibration policy. Its draft status keeps unresolved boundaries visible; it is not a gate that blocks independent safe work.
The goal is a reviewable path from physical design to classical and quantum predictions, experimental comparison, and revised inputs. “Full chip” means that the architecture must represent heterogeneous physical subsystems, simultaneous operations, and spectators without imposing a fixed qubit count, connectivity, or one- and two-qubit-gate ceiling. It does not claim that an arbitrary chip is computationally feasible or that one model can predict universal chip fidelity.
Read this architecture through three questions
- Where does the physical model come from? Follow the separate circuit and native EM-mode routes below; neither is automatically interchangeable with the other.
- Who owns the operation and result? Use the package table and conceptual layers to separate model, study intent, execution, and observation.
- What may be inferred or revised? Reduction and uncertainty sections retain assumptions; the six horizons describe future work, not delivered capabilities.
Citation class — proposal/engineering choice. The package boundaries and handoff diagram are target architecture choices. The circuit and measurement literature supplies relevant physical starting points, not acceptance of these package contracts (Vool and Devoret 2017, secs. 2–3; Blais et al. 2021; Clerk et al. 2010, secs. II–IV).
Target feedback architecture
The diagram keeps both source routes visible. On a narrow screen, focus the diagram and scroll horizontally; the sections below explain the same handoffs.
The arrows show intended artifact or data handoffs, not sibling-package runtime imports. Exact contracts, schemas, and owners remain pending wherever this page marks them as unselected. Shared intent enters each package-owned simulation path; it does not feed a common cross-package executor. Layout-to-performance claims must carry the fabrication, material, control, and environment assumptions that make the chain meaningful. A revision proposal never mutates the result, receipt, raw acquisition, or Knowledge page from which it was inferred. A responsible owner reviews and versions the corresponding input instead.
The two routes into SCQSim are both target capabilities:
- The circuit route starts from a circuit representation. Distributed telegrapher or multiconductor RLGC data become circuit data when lowered to a finite transmission-line or pi-section representation, even when the coefficients originated in EM extraction.
- The native EM-mode route starts from normalized EM eigenmodes, energy information, and an explicit junction map. It must not be forced through SCNSim when that detour would change its authority.
Supporting both routes does not define their fusion. A mixed-source assembly must prevent silent overlap and double counting and would require its own future contract. It cannot be inferred from whichever inputs happen to be available.
Package and ownership boundaries
| Surface | Architectural responsibility |
|---|---|
| OrPen SC PDK | Public fabrication facts, material and layer semantics, layout components, and stable physical design intent. |
| SCGSim | Electromagnetic model preparation, backend adapters, lowering and execution, C/L/RLGC and mode/energy extraction, and solver-specific result provenance. Native Palace and other solver repositories remain with their own maintainers; SCGSim owns its backend boundary and result consumption, not their solver source. |
| Proposed shared circuit-modeling boundary | Stable circuit declarations and reusable physical bindings shared above a particular classical solver. This is a proposed extraction from current SCNSim authoring—not an existing package, repository, API, owner, or package named scqmodel. |
| SCNSim | Classical circuit compilation, response, nonlinear analysis, optimization, and classical results. Its existing Q2D/RLGC/pi use remains authoritative while the proposed shared boundary is unsettled. |
| SCQSim | Simulation-only quantum realization: Hilbert representations, Hamiltonians, pulse/control simulation, and simulated gate metrics. It does not own laboratory instruments, hardware execution, acquisition, or experimental automatic calibration. |
| Future experimental package | Instrument-specific lowering, timing and interlocks, hardware execution, acquisition, raw records, and experimental calibration. Its name, repository, API, schema, and owner are intentionally unselected. |
| Root Design and Evidence | Cross-domain comparison, revision intent, protected evidence navigation, and architecture prose. The producer continues to own every original result; root owns neither package schemas nor solver behavior. |
| Legacy Circuit Workbench | Existing explicitly selected consumers retain its current authority. This target architecture does not silently migrate or supersede them. |
Package-owned capability documentation remains the authority for implemented APIs and result meaning. Repository links above identify those owners without claiming that a local documentation candidate has already been published. Package resources are external links, not child sites or a merged search index under this root publication. Private project documentation stays with its actual source owner and is not served by this public architecture page.
Conceptual layers
The architecture keeps the following layers explicit rather than treating a single backend object as “the chip”:
| Layer | Durable meaning | Boundary |
|---|---|---|
| Physical sources and subsystem identity | Layout, process, material, circuit elements, ports, junctions, and stable subsystem identity. | A representation may refer to this identity but must not redefine it by index or backend ordering. |
| Quantum and Hilbert representation | Quantization coordinates, basis and truncation choices, tensor hierarchy, dressed-state lineage, and logical encoding. | A representation is versioned with its parent physical model and approximations. |
| Study question | Static spectrum, effective interaction, dynamic control, sensitivity, or calibration question and requested observables. | A static study needs no dummy gate or pulse. |
| Control intent | Abstract channel, coordinate, timing, envelope, and sweep meaning. | Solver pulses and instrument waveforms are separate lowerings of this intent. |
| Environment | Baths, loss channels, correlations, temperatures, spectra, and approximation regime. | An environment is not automatically a measurement. |
| Measurement | Requested simulated observable or declared acquisition process. | Predicted observables, simulated samples, raw acquired records, and inferred estimates remain different data types. |
| Backend execution | Solver or instrument objects, memory, queues, and process-local state. | Backend objects are process-local and are never durable cross-package contracts. |
| Typed result and provenance | Parent model, study, resolved parameters, approximation chain, execution identity, units, status, and artifacts. | A comparison links results; it does not merge their provenance or transfer producer ownership. |
The durable model and the runtime remain separate. A physical or quantum model may support multiple studies, while each solver or instrument lowering owns its own execution state and failure behavior.
Realization and reduction
A full-chip study may use a direct finite realization, hierarchical assembly, or a reduced/effective model. Each result must retain:
- the parent physical and quantum model identities;
- the selected subsystem partition, basis, truncation, and reduction;
- every approximation and validity domain;
- the transform relating retained states, operators, observables, controls, environments, and logical encodings to the parent model; and
- the numerical and backend evidence needed to interpret the reported result.
This lineage permits reduced models without presenting them as the unreduced chip. It also permits simultaneous operations and spectators without implying that every backend can solve every declared model at useful cost.
Fabrication and uncertainty
Fabrication and uncertainty remain future, source-bound architecture scope:
- correlated variations must retain their declared physical source, joint model, and sampled-realization identity rather than becoming unrelated knob changes;
- a geometry-changing realization requires the affected extraction to be run again instead of silently reusing nominal C, L, RLGC, mode, or energy data; and
- every prediction is conditional on its declared material, noise, control, environment, and fabrication inputs. Comparison cannot turn unknown inputs into calibrated facts without a stated inference model and evidence.
This draft selects no distribution, uncertainty propagation method, tolerance, or acceptance threshold.
Long-term capability horizon
The architecture must eventually support six connected capability families. These are review topics, not claims that the current packages implement them.
- Spectra, eigenstates, and operator matrix elements. Track basis, truncation, state assignment, degeneracies, and operator lineage. Relevant starting points are Circuit Lagrangian, Hamiltonian, and Canonical Quantization and the official scqubits custom-circuit guide.
- Coupled and effective Hamiltonians. Preserve the full parent model and transformation when applying RWA, dispersive, Schrieffer–Wolff, normal-mode, or other reductions. See canonical circuit quantization and the Schrieffer–Wolff starting framework (Bravyi et al. 2011).
- Tunable couplers and residual ZZ. Keep exchange cancellation, conditional shifts, leakage channels, control coordinates, and spectator effects distinct. See Tunable-Coupler Zero Exchange and Residual ZZ.
- Driven evolution, gates, and simulation calibration. Represent time-dependent controls, simultaneous operations, leakage, local frame conventions, and simulated calibration without implying experimental instrument control. Dynamics conventions provides a generic symbol bridge; source-owner control parameter resources provide vocabulary, not an accepted cross-package runtime contract.
- Environments and measurement. Distinguish bath models, unconditional evolution, monitored channels, simulated records, acquisition, and inferred estimates. Starting sources include circuit-QED source context (Blais et al. 2021), QuTiP’s official Lindblad master-equation and stochastic-solver guides.
- EM-to-quantum realization. Bind normalized modes, energy conventions, junction mappings, participation, loss assumptions, and Hamiltonian-facing quantities without double counting circuit and field sources. See the root EPR source context and its source-defined normalization and junction assumptions (Minev et al. 2021).
The broader circuit-QED review (Blais et al. 2021) helps relate several categories. A source link means only that the source is relevant; it does not make a claim reviewed, accepted, or applicable to a particular chip.
Scientific and architecture review backlog
Focused review topics for subsequent architecture and package work include the questions below. They are not a new prerequisite gate.
- Which spectrum, eigenstate, and operator identities survive a basis, truncation, hierarchy, or parameter change?
- Which effective-Hamiltonian coefficients are derived from which parent model, transform, approximation, and control point?
- How are tunable-coupler exchange, residual ZZ, leakage, simultaneous control, and spectator observables separated?
- Which pulse/control concepts are truly common, and which belong only to a solver or instrument lowering?
- Which environment models support unconditional, stochastic, or monitored evolution, and what may legitimately be compared with acquired data?
- What normalization, junction mapping, loss model, and source-selection rules make an EM-to-quantum route complete?
- What neutral study, parameter, pulse, observable, provenance, and result vocabulary is useful before choosing a shared schema?
- Which package will eventually own experimental acquisition and automatic calibration, and how will its immutable records and safety responsibilities remain separate from SCQSim?
- What evidence establishes a mapping between simulated and measured observables, and how are versioned revision proposals reviewed?
Current capability boundary
This architecture was drafted against two dated source snapshots:
SCQGate (previous name) 1.0.0.dev0 @ d6d472256a6654f5ed3a444adec1bab0cbad6503provides identity, hierarchy, source validation, and contract models. It does not yet construct a runnable numerical Hamiltonian or execute dynamics. The native SCGSim EM-mode route is also not executable there.SCNSim @ 2d67bc2ff5141a6e74cadcc4adfd1e197a816e0cprovides the inspected Q2D/RLGC/pi authoring path. Its continued use remains package-owned and is not conditioned on extracting the proposed shared circuit-model boundary.
These are historical inspected snapshots, not statements of today’s complete package capability, stable-release claims, or architecture authority. Current SCQSim naming does not rewrite the previous-name revision attribution. Consult the selected package revision’s own documentation before attempting an operation.
Review state
| Field | State |
|---|---|
| Semantic state | CONVERGING |
| Document class | TARGET_ARCHITECTURE_DRAFT |
| Human review | HUMAN_REVIEW_PENDING |
| Implementation | Target cross-package architecture; not a claim about all current package operations. |
| Publication | Publishing this draft does not accept or implement its target contracts. |
| Tests | no_test_writes |
The next step is focused Human, architecture, and scientific review of this page. Review may revise the target without changing current package authority or blocking independent package work.