跳转至

12 Lowering Rules

Purpose

This chapter defines the lowering rules from UQCI abstractions to compatibility and backend-oriented forms.

Governing Principles

Lowering must follow two rules:

  1. logical semantics take priority over physical detail
  2. device-specific information should live in DeviceSpec, CalSet, and backend modules rather than being hard-coded into the main QASM file

These rules are consistent with the reference Word drafts and with the repository OpenQASM bridge doctrine. Lowering is not license to move semantic ownership away from the canonical layer.

Three Forms of Representation

For clarity, the repository should distinguish among three forms:

  • canonical semantics: UQCI-side meaning expressed by canonical models
  • export semantics: profile-shaped OpenQASM compatibility output
  • backend-facing forms: internal plans, scheduled representations, or target-native compiled artifacts

Lowering may transform one form into another, but it should preserve semantic intent across that transformation.

Representative Lowering Mapping

  • GateOp -> standard gate syntax or custom gate form
  • timing intent -> duration, delay, box, stretch, barrier, or equivalent constructs
  • single-qubit pulse intent -> defcal or OpenPulse-aligned forms in higher profiles
  • entangler pulse intent -> calibration-aware forms plus sidecar references
  • classified measurement -> measure -> bit or equivalent
  • raw measurement intent -> profile-aware capture hints and backend-specific handling
  • routing or shot policy -> namespaced pragmas

The reference drafts also call out related constructs such as virtual phase updates, resource locks, calibration bindings, and additional execution hints. These belong in namespaced annotations, pragmas, sidecar references, or backend-native forms depending on profile and target.

Intent-Preserving Rule

Lowering should preserve the execution intent of the canonical program as far as the selected target form allows. In practice, this means:

  • preserving logical gate meaning before introducing target-specific detail
  • preserving timing intent when exporting to timing-aware profiles
  • preserving calibration references through sidecars or profile-compatible constructs
  • preserving execution hints without falsely promoting them to canonical semantics

When a target form cannot carry the full detail of the canonical program, the lowering boundary should make that limitation explicit rather than silently degrading meaning.

The recommended lowering flow is:

  1. validate the UQCI program against the DeviceSpec capability envelope
  2. select the export profile OQ-0, OQ-1, OQ-2, or OQ-X
  3. lower gate-level semantics to portable OpenQASM
  4. lower timing semantics to delay-like constructs as required
  5. attach calibration-aware content when the chosen profile allows it
  6. emit UQCI namespaced annotations and pragmas for OS-level hints
  7. package the exported program together with manifest, devicespec, calset, and optional pulseir

Canonical Versus Backend-Facing Lowering

Compatibility export is only one lowering path. A backend may also lower directly from canonical UQCI semantics to:

  • scheduled internal plans
  • resource-annotated execution plans
  • target-native pulse or control sequences
  • mock execution plans used for testing

Those backend-facing forms remain downstream of canonical semantics and sidecars even when no OpenQASM export is emitted.

Profile Sensitivity

Lowering is profile-sensitive by design:

  • OQ-0 favors maximum portability
  • OQ-1 preserves timing intent where possible
  • OQ-2 allows calibration-aware export
  • OQ-X carries the richest compatibility surface for QOS-oriented execution

The chosen profile should therefore be treated as an export policy, not as a redefinition of the canonical program.

Practical Rule

Lowering should remain practical and modular. A full general-purpose parser or universal pulse compiler is not required for conformance to this repository's v0.1 reference scope.

Implementations should prefer explicit, auditable lowering steps over opaque target-specific shortcuts that would blur the distinction between canonical semantics, compatibility export, and backend-native realization.