Explore evolving SLR/Zlup into a Rust-native QEC HDL

[qciaran]

Summary

Explore an HDL-inspired user model and common schema for describing QEC artifacts across multiple abstraction levels.

Parent: #509
Architectural discussion: #508

Motivation

Hardware-description languages capture hierarchy, parameterization, multiple implementations of an interface, structural composition, constraints, assertions, testbenches, and progressive refinement. These concepts map naturally onto QEC codes, protocols, circuits, mappings, and target schedules.

The goal is to determine which HDL ideas PECOS should adopt without prematurely committing to Verilog syntax or building a parser before the internal semantic model is understood.

Questions to explore

• Should the user-facing form be:
  • a dedicated textual QEC HDL;
  • a Python/Rust builder DSL;
  • a declarative serialized schema;
  • multiple front ends over shared typed IRs?
• How should a module distinguish an abstract interface from one of several implementations?
• How should parameterized code families and generate-style construction work?
• How should constraints, assertions, testbenches, and refinement certificates be represented?
• How should logical programs, adaptive protocols, decoders, and Pauli-frame updates compose?
• At what point should artifacts lower into HUGR or existing circuit representations?
• Which representation should be the stable interchange format?

Candidate HDL analogies

HDL concept	QEC analogue
Module interface	Abstract code or logical operation
Architecture/implementation	QEC or syndrome-extraction protocol
Netlist	Physical circuit
Place and route	Qubit mapping and routing
Timing closure	Native schedule and feedback latency
Testbench	Code-capacity, phenomenological, or circuit-level experiment
Assertion	Code validity, logical action, or fault-tolerance property
Cell library	Native gates and target capabilities

Deliverables

• Compare at least three frontend approaches against representative use cases.
• Write example descriptions for:
  • a parameterized repetition or surface-code family;
  • the Steane code with two syndrome-extraction implementations;
  • an adaptive protocol with decoder feedback;
  • a target mapping with timing constraints.
• Identify the common semantic model required beneath all candidate syntaxes.
• Prototype only enough syntax/builders to validate the model.
• Recommend whether to proceed with a dedicated HDL and, if so, propose follow-up implementation issues.

Acceptance criteria

• A design note records the evaluated options and recommendation.
• Examples demonstrate hierarchy, parameterization, alternate implementations, constraints, and testbench/experiment attachment.
• The proposed frontend has an explicit lowering path into the IRs agreed in [RFC] Layered abstractions and an HDL-style design model for QEC #508.
• The exploration does not duplicate HUGR or existing circuit IR responsibilities without a documented reason.

[qciaran]

Leading design option: evolve SLR and Zlup into a Rust-native QEC HDL stack

SLR is currently the strongest foundation for the HDL rather than merely another output format. It already provides an embedded DSL, hierarchy, control flow, parallel operations, an AST, validation/analysis/optimization, serialization, and multiple code-generation targets. Zlup independently explores a Rust-native textual language and currently mirrors/generates SLR-AST. These efforts should be evaluated as candidates for convergence.

Proposed ownership and frontend model

• Rust owns the canonical typed AST/IRs, schemas, validation, transformations, and stable serialization.
• Python SLR remains an ergonomic embedded builder over the Rust implementation.
• A textual syntax descended from Zlup provides files, modules, tooling, formatting, diagnostics, and editor support.
• Zluppy becomes thin Python bindings to the shared compiler rather than a parallel semantic model.
• Guppy/HUGR remain important higher-level and executable hybrid paths; this proposal should define their lowering/interchange boundary rather than duplicate them.

The current Python SLR AST should not simply be enlarged into one union containing every abstraction level. Prefer related typed dialects/artifacts with explicit lowering contracts, for example:

• code/logical declarations;
• protocols and alternative implementations;
• executable circuit/control flow;
• hierarchical space-time design and constraints;
• flattened target schedules.

HDL concepts to add explicitly

• interface/contract versus implementation;
• typed quantum and classical ports;
• parameterized/generate-time construction;
• hierarchical cells or space-time volumes;
• target constraints and alternative implementation selection;
• assertions, testbenches, and refinement certificates;
• source/provenance maps across all lowering steps.

Prototype milestone

Use the Steane code to test this direction before committing to a complete grammar:

1. Declare the abstract code and logical interface.
2. Define bare-ancilla and flagged syndrome-extraction implementations.
3. Represent each implementation as hierarchical space-time volumes.
4. Lower one implementation through the existing circuit/DAG and tick paths.
5. Generate at least two existing targets such as Stim, HUGR/Guppy, or QASM.
6. Verify that check, detector, observable, logical-action, hierarchy, and source provenance survive lowering.
7. Exercise both a Python builder and a minimal textual form over the same Rust-owned semantic representation.

Naming

If SLR becomes the umbrella representation, standardize its expansion as Structured Language Representation. That name accommodates multiple abstraction levels better than the currently documented alternative, “Simple Logical Representation.”

This should be treated as the leading option to evaluate, not a decision to freeze surface syntax prematurely.