Description
The dt duration unit in OpenQASM 3 is backend-dependent — it represents the duration of one waveform sample on the target hardware. It cannot be converted to SI units (ns, us, ms, s) without knowing the backend's sample rate.
However, pyqasm currently treats dt as equivalent to ns during unrolling, producing incorrect duration values.
Reproduction
from pyqasm import loads
import openqasm3.ast as ast
qasm = """
OPENQASM 3.0;
include "stdgates.inc";
qubit[1] q;
delay[100dt] q[0];
"""
m = loads(qasm)
m.unroll()
for s in m.unrolled_ast.statements:
if isinstance(s, ast.DelayInstruction):
print(f"value={s.duration.value}, unit={s.duration.unit.name}")
# Output: value=100.0, unit=ns
Expected Behavior
delay[100dt] should either:
- Preserve
dt as the unit in the unrolled AST (value=100.0, unit=dt), or
- Raise an error/warning that
dt cannot be converted to SI units
Actual Behavior
The duration is reported as value=100.0, unit=ns — treating 1 dt = 1 ns, which is incorrect. The TIME_UNITS_MAP in src/pyqasm/maps/expressions.py does not include a dt entry, so the unit appears to fall through without proper handling.
Reference
From the OpenQASM 3 spec:
The duration type is used for timing of operations. SI units of time (ns, µs, ms, s) are supported. There is also a backend-dependent unit dt, equivalent to the duration of one waveform sample on the backend.
Description
The
dtduration unit in OpenQASM 3 is backend-dependent — it represents the duration of one waveform sample on the target hardware. It cannot be converted to SI units (ns, us, ms, s) without knowing the backend's sample rate.However, pyqasm currently treats
dtas equivalent tonsduring unrolling, producing incorrect duration values.Reproduction
Expected Behavior
delay[100dt]should either:dtas the unit in the unrolled AST (value=100.0, unit=dt), ordtcannot be converted to SI unitsActual Behavior
The duration is reported as
value=100.0, unit=ns— treating 1 dt = 1 ns, which is incorrect. TheTIME_UNITS_MAPinsrc/pyqasm/maps/expressions.pydoes not include adtentry, so the unit appears to fall through without proper handling.Reference
From the OpenQASM 3 spec: