Control output and resource checks

ControlElectronics schedules physical events after the TCU triggers a time point. Its resource checker reserves the complete future interval for each event, including events whose output delay means they have not started yet.

Connections

• Input: validated TCU TriggeredEvents values with resolved event specifications.

• Output: physical starts and ends, active pulse drives, backend operations and measurement completions.

• Scheduling: the SystemC barrier calls process() at the next physical boundary after all clocked work due at that tick has finished.

Reserving and executing intervals

accept() calculates start = fire_tick + delay and end = start + duration for every event. It checks all intervals against one another and existing reservations before installing them.

Intervals use [start, end), so adjacent operations can share an endpoint. Overlaps on one output port are forbidden. Intervals on different ports conflict when they share a resource and either use is exclusive. Except for discriminator arms, events sharing a target may overlap only when both are pulses or are the two configured outputs of one gate with identical intervals.

For a GateOutput, resolve() checks the source core, local port and codeword against the gate definition and reserves its targets and resources. At the start tick, process() requires both configured outputs before any backend mutation. It commits one ideal gate and emits one GateApplied record. Each output retains its own OperationStart and OperationEnd records.

The device event order defines when process() commits evolution, samples acquisitions, starts new operations and publishes results. BackendExecution controls when those committed operations execute on the backend.

Objects and state

Object or member	Representation	Role
reservations_	ResourceReservations	Future half-open physical reservations and event identities.
boundaries_	map<Tick, Boundary>	Scheduled starts, ends and result-ready IDs.
active_	map<Id, ScheduledEvent>	Operations currently occupying physical intervals.
last_tick_, processed_tick_	global ticks	Last evolution point and guard against repeated physical processing.

C++ API.

Reset and errors

All event durations must be positive. Exclusive-resource conflicts and unsupported same-target sampling collisions fail before quantum state changes. A backend failure stops the run; already performed numerical work is not rolled back or retried.

Reset aborts active and future events, discards pending backend operations, clears reservations, and initializes the backend for the new epoch. Global time continues from the reset tick.

Implementation and tests

Source: control_electronics.cpp, device.hpp and gates.cpp.

CTest: protocol.resources, protocol.sample_collision, protocol.reset, device.two_qubit.

The tests check overlapping resource intervals, unsupported sampling collisions and cancellation of active device work during reset. Paired-gate tests check single application, delay compensation, missing inputs, conflicts and reset.

Native reset assumption

An ideal gate action with operation: "reset" applies the local reset channel at its start tick and reserves its port, target and resources for duration ticks, using the same timing convention as other ideal operations. This models control electronics with a predefined reset sequence: any internal measurement and feedback require no CPU instructions. Internal pulses, collapse outcomes and feedback latency are not individually modeled. Reset emits no measurement reference or completion, and does not change measurement registers, execution flags, or the simulation epoch.

Stim and Aer support this ideal channel; Mock provides control-only execution. QuTiP rejects ideal reset as it rejects other unsupported ideal gates. A reset on part of an entangled state must preserve the other targets’ reduced state; it is not a backend-wide reinitialization. The optional python.backend_semantics CTest checks native reset on excited, superposed and entangled inputs.