LINQ-Based Feedback#

Every Q1 sequencer is equipped with an extensive, low-latency feedback system, allowing real-time sharing of information between Q1 sequencers within a Qblox Cluster.

This capability is essential for performing advanced quantum operations. A few examples are:

Repeat-until-success
Conditional-branching of the Q1 core program
Conditional-playback
Real-time qubit calibrations
PID controllers for qubit stabilization

LINQ allows a source sequencer to transmit payloads (thresholded bits (TB), IQ samples, time-tags, TTL counts, and immediates and registers) to one or many receiver sequencers in real-time.

Data Routing#

Every piece of data sent by a sequencer is addressed with a specific id (an 8-bit immediate value in Q1ASM). This id serves multiple purposes:

Routing control: The id value determines the routing mode
- IDs 1–15 are reserved for self-cast, which returns data exclusively to the originating sequencer.
- IDs 16–255 can be set up for either intra-cast or multicast routing (see Routing Configuration section for detailed information).
Selective receiving: On the receiver side, the ids are used to filter queue entries:
- The command fb_pop_data I, R retrieves data associated with the specific id provided in the first argument, I. Note that this command discards all data in the queue that precedes the target data. The targeted value is then stored in register R (see Figure 2 below).
- The command fb_pull_data R0, R1 performs a standard FIFO retrieval. It fetches the next available data in the queue, storing the value in R1 and its corresponding id in R0 (see Figure 3 below).
Disabling Sharing: Setting the id to 0 disables sharing of the respective data type for the next acquisition. This allows users to dynamically enable or disable the sharing of specific data types without changing the sequencer’s program structure.

Routing Configuration#

The routing configuration determines which sequencers receive the data based on the id of the data packet. This allows for flexible communication patterns between sequencers without risking overflowing the feedback queue with irrelevant data.

Figure 1: Click on the Routing type to highlight the Routes.

The sequencer can be configured to transmit data using three different default routes, set by the sequencers’ configuration:

Self-cast: The data is sent only to the originating sequencer.
Intra-cast: The data is sent locally to the selected sequencers within the module.
Multi-cast: The data is sent to the selected sequencers via CMM route, this allows communication between sequencers across modules.

Receiving Data#

Data arrives at the receiving Q1 core in a dedicated feedback queue. This queue has a fixed capacity of 32 entries, each with a 32-bit data width.

There are two main ways to retrieve data from the feedback queue:

Selectively pop the data with a specific id using fb_pop_data id:I8, data:R
Pulling the data in FIFO order using fb_pull_data id:R, data:R

The Q1ASM command to pop the data from the feedback queue is

 fb_pop_data      id:I8,    data:R

The fb_pop_data is a Q1 core command and not a real-time instruction, thus takes 4 ns as Q1 execution time. It is important to note that the id operand is an immediate, thus needs to be user-specified.

In the video below, we see the behavior of the fb_pop_data command, where user specifies id 7. The Q1 core discards the entries in the feedback queue until it finds the entry with id 7, then moves the attributed data into the specified register.

Figure 2: Popping data with a specific id (here e.g. 7).

When the user wants to pull the data in FIFO order without specifying the id, the fb_pull_data command is used instead. This command allows users to retrieve data from the feedback queue in the order they were received.

The video below shows the behavior of the fb_pull_data command, where the Q1 core moves the id and data of the first entry in the feedback queue into the specified registers, in the case below to R0 and R1.

Figure 3: Pulling data in FIFO order.

Since the command fb_pull_data updates two Q1 registers, the Q1 execution time of this command is 8 ns.

Note

Here, we assume that the LINQ data is already in the sequencer queue before calling fb_pop_data or fb_pull_data. If you execute fb_pull_data id:R, data:R when the queue is empty, or fb_pop_data id:I8, data:R when no entry with the requested id is present, the Q1 core will wait until there is an entry in the feedback queue to pop. At the same time, if the RT core tries to pop a real-time instruction from the RT queue and the RT queue is empty, the sequencer will stop and raise an SEQUENCE_PROCESSOR_RT_EXEC_COMMAND_UNDERFLOW error. See the following section for how to avoid this error when data arrival time is unknown.

The recommended way to send and receive LINQ data is to take the Q1 to Q1 latencies into account, and ensure that the RT queue of the receiving sequencer will not run out while the Q1 core of the receiving sequencer waits for the feedback queue to be filled. This is true for data types with deterministic arrival times—such as TB, IQ values, Q1 registers/immediates, TTL counts, and high-resolution time deltas.

However, there are some situations in which one does not know when the LINQ data will arrive. In these cases, it is possible to disable the SEQUENCE_PROCESSOR_RT_EXEC_COMMAND_UNDERFLOW error temporarily by using 0 as the duration argument to a real-time instruction before using fb_pop_data or fb_pull_data.

Note

duration = 0 is a special value that suspends the underflow guard; it is an exception to the general 4 ns minimum described in the sequencer documentation.

If the RT core pops a real-time instruction with 0 duration (e.g. wait 0), it will execute the real-time instruction and 4 ns later try to pop and execute the next RT instruction in the queue. If there is no instruction in the RT queue, the RT core will wait until one arrives, pop and execute it.

When the RT core pops a real-time instruction with a duration that is not 0, then the SEQUENCE_PROCESSOR_RT_EXEC_COMMAND_UNDERFLOW error is enabled again.

Example

Selectively popping the data with id 16:

wait 0                      # wait indefinitely
fb_pop_data 16, R1          # pop data with `id` 16 as soon as it arrives into register `R1`

Popping first data in FIFO order:

wait 0                      # wait indefinitely
fb_pull_data R0, R1          # pull data as soon as it arrives, put id into R0 and data into R1

Important

Using wait 0 before fb_pop_data or fb_pull_data forces synchronization between the Q1 core and the RT core. This means that synchronization of the sequencer depends on the Q1 execution time before the next real time instruction, including that real time instruction itself.

Sharing Data#

Through LINQ-based feedback, sequencers can transmit Q1 immediates and registers, IQ values, TB, time-tags, and TTL counts.

All Q1 commands to either enable/disable sharing or configuring the data format are real-time instructions and thus executed by the RT core. Each of these commands has a duration argument that specifies how long the RT core should wait in the RT timeline before executing the next RT instruction.

The interactive figure below maps several data-types for chosen sequencers that can send various data types via LINQ-based feedback.

Figure 4: Click on the sequencer type to highlight the supported datatypes.

In this section, we provide brief descriptions of the Q1 commands used to send these data-types via LINQ-based feedback.

Readout Sequencer Data Types#

The knowledge of TB and IQ values in real-time experiment is essential for implementing active feedback in quantum circuits, such as an advanced real-time qubit state discrimination and conditional operations based on measurement outcomes.

With the LINQ-based feedback architecture, readout sequencers can share TB and IQ values in real-time to several Q1 Sequencers within the cluster.

Thresholded Bits#

The Q1ASM command to enable sending thresholded bits (TB) from a readout sequencer is

 fb_acq_tb_id      id:I8/R,    duration:I16

This command configures the id that will be attached to the TB when sent via LINQ. The sent data on LINQ are in 2-bit format, where the first bit corresponds to the resulted thresholded bit, and the second bit is a validation bit that is set to 1 by default. The TB are sent at the end of the acquisition window.

When working with large number of qubit measurements, the amount of TB can exceed the feedback queue capacity. To avoid overflow, we can configure multiple sequencers to use a write-combine mode to send TB. In this mode, each sequencer appends its TB to a specific bit position within the same 32-bit data payload - provided that all acquisitions end at the exact same time on the RT core.

To configure the write-combine mode for TB, the following Q1ASM command is used

 fb_acq_tb_cfg  write_combine:I1, bit_pos:I10, length:I7 (in bytes), duration:I16

Here, the write_combine flag enables (1) or disables (0) the write-combine mode. The bit_pos specifies the starting bit position in the data payload where the TB from this sequencer will be written. The length indicates the length of the whole data payload in bytes. After the configuration, the real-time queue waits for duration ns.

Example

We have two readout sequencers, we can configure them to send their TB to id 16, but with different bit positions as follows.

Sequencer 0:

fb_acq_tb_id        16, 8               # set id to 16
fb_acq_tb_cfg       1, 0, 1, 8          # enable write-combine, start at bit position 0, length 1 bytes, wait 8 ns

acquire             0, 0, 200           # acquire for 200 ns

fb_acq_tb_id        0, 8                # set id to 0 to disable sending TB for the next acquisition

Sequencer 1:

fb_acq_tb_id        16, 8               # set id to 16
fb_acq_tb_cfg       1, 2, 1, 8          # enable write-combine, start at bit position 2, length 1 bytes, wait 8 ns

acquire             0, 0, 200           # acquire for 200 ns

fb_acq_tb_id        0, 8                # set id to 0 to disable sending TB for the next acquisition

After the acquisition, both sequencers send their TB to id = 16.

The payload layout is:

Bit position	b7	b6	b5	b4	b3	b2	b1	b0
Meaning	-	-	-	-	valid	data	valid	data
Value	0	0	0	0	1	0	1	0

After executing fb_pop_data 16, R1 on a receiving sequencer, the register contains R1 = 0b00001010.

The default value of the valid bit is 1. However, the user can change it to 0 by using the fb_acq_tb_valid command as follows:

 fb_acq_tb_valid  valid_bit:I1, duration:I16

IQ Values#

The Q1ASM command to enable sending IQ values from a readout sequencer is

 fb_acq_iq_id      id:I8/R,    duration:I16

This command configures the id that will be attached to the IQ values when sent via LINQ. The IQ data is sent in two 32-bit formats, where the first 32 bits correspond to I value and the second 32 bits correspond to the Q value. The IQ values are sent at the end of the acquisition window.

If the user wishes to work with I and Q in lower bit format, the fb_acq_iq_shift command can be used to configure the bit resolution of the IQ values as follows:

 fb_acq_iq_shift  shift:I8, duration:I16

Here, the shift value indicates how many bits the IQ values will be right-shifted before sending. For example, if shift is set to 8, the IQ values will be right-shifted by 8 bits, effectively reducing their resolution from 32 bits to 24 bits.

Example

We have a readout sequencer sending the IQ values of a qubit with id 36, we can configure it as follows.

Readout Sequencer:

fb_acq_iq_id      36, 8       # set id to 36, wait 8 ns
fb_acq_iq_shift    8, 8       # Set right-shift of IQ values to 8 bits, wait 8 ns

acquire            0, 0, 200  # acquire for 200 ns

fb_acq_iq_id       0, 8       # set id to 0 to disable sending IQ values for the next acquisition

To retrieve the IQ values at the receiving sequencer, we can use the following command to pop the data from the feedback queue:

Receiving Sequencer:

...
fb_pop_data  36, R1          # Pop the I value and store it in R1
fb_pop_data  36, R2          # Pop the Q value and store it in R2

Time-tag Sequencer Data types#

For optical addressable qubits, the feedback on photon emission (TTL counts and time-tags) is a key-factor to ensure synchronization between multiple quantum network nodes. In addition, the temporal precision can help to mitigate de-phasing noise in the Bell states.

With the LINQ-based feedback architecture, the time-tag sequencers can share TTL counts and time-tags in real-time to several Q1 Sequencers within the cluster.

There are four variants of data types that can be sent from the time-tag sequencer.

Low-latency Time-tags#

To enable sending low-latency time-tags from the time-tag sequencer, the following command is used:

 fb_llp_tags_id      id:I8/R,    duration:I16

The resolution of the low-latency time-tags is 1ns. Once the acquisition window is open, the detected time-tags will be sent in real-time until the window is closed.

Example

We have a time-tag sequencer sending the low-latency time-tags of a qubit with id 36, we can configure it as follows.

Time-tag Sequencer:

fb_llp_tags_id      36, 8          # set id to 36
acquire_timetags    0, 0, 1, 0, 4  # open the acquisition window
wait                400            # wait for 400 ns 
fb_llp_tags_id      0, 8           # set id to 0 to disable sending low-latency time-tags for the next acquisition

Low-latency TTL Counts#

The Q1ASM command to enable sending TTL (photon-detection events) counts from the time-tag sequencer is

 fb_llp_ttls_id      id:I8/R,    duration:I16

The command sends the number of detected TTL events above the user-defined threshold in real-time with the specified id. The count is sent at the end of the acquisition window.

Example

We have a time-tag sequencer sending the photon counts of a qubit with id 36, we can configure it as follows.

Time-tag Sequencer:

fb_llp_ttls_id      36, 8          # set id to 36
acquire_timetags    0, 0, 1, 0, 4  # open the acquisition window
wait                400            # wait for 400 ns 
acquire_timetags    0, 0, 0, 0, 4  # close the acquisition window
fb_llp_ttls_id      0, 8           # set id to 0 to disable sending low-latency photon counts

High-resolution Time-tags#

The time-tag sequencers can also send high-resolution time-stamps (down to ~ 8ps resolution) on the cost of more processing time on the sequencers before being sent via LINQ, thus classified as high-resolution data types.

Similar to low-latency data types, there are two variants of high-resolution data types:

High-resolution time-tags
Time delta between detected events

Once the acquisition window is open, the detected time-tags will be sent in real-time until the window is closed. To enable sending high-resolution time-tags from the time-tag sequencer, the following command is used:

 fb_tdc_tags_id      id:I8/R,    duration:I16

Example

We have a time-tag sequencer sending the high-resolution time-tags of a qubit with id 36, we can configure it as follows.

Time-tag Sequencer:

fb_tdc_tags_id      36, 8          # set id to 36

acquire_timetags    0, 0, 1, 0, 4  # open the acquisition window
wait                400            # wait for 400 ns 
acquire_timetags    0, 0, 0, 0, 4  # close the acquisition window

fb_tdc_tags_id       0, 8          # set id to 0 to disable sending high-resolution time-tags for the next acquisition

Time delta#

The Q1ASM command to enable sending the time delta between detected events from the time-tag sequencer is

 fb_tdc_tdelta_id      id:I8/R,    duration:I16

For the sequencer to send the desired time-difference between two events, the user needs to configure the io_channelX as the time reference and the other io_channelY as the time source. Note that both can be the same channel. This allows the Q1 processor to subtract one time-tag from the other and send the time-difference with resolution of 1/128 ns and range of ±16.7 ms via LINQ.

Example

To send a time delta we need to define which channel is \(t_0\) and which channel is \(t_1\), so that the sequencer, where these events are enabled, can send \(t_0 - t_1\) We have a time-tag sequencer sending the time-difference between two events measured at the same channel with id 36, we can configure it as follows.

The QCoDeS to configure the io_channelY in a module at slot X is as follows.

moduleX.io_channelX.binned_acq_time_ref("firstX")      # set the time reference to the first detected event on channel X
moduleX.io_channelY.binned_acq_time_source("second")   # set the time source to the detected event on channel Y

Then the Q1ASM for the time-tag sequencer is,

fb_tdc_tdelta_id      36, 8          # set id to 36

acquire_timetags      0, 0, 1, 0, 4  # open the acquisition window
wait                  400            # wait for 400 ns 
acquire_timetags      0, 0, 0, 0, 4  # close the acquisition window

fb_tdc_tdelta_id      0, 8           # set id to 0 to disable sending high-resolution time-delta 

Q1 Immediates and Registers#

The common data types among all Q1 sequencers are registers and immediates. The Q1 command to send an immediate or a register is:

fb_com_data  id:I8, value:I32/R, duration:I16

This command sends the value of register R or an immediate I with the specified id. After sending the data, the sequencer waits for duration ns in real-time before executing the next instruction.

Example

We have a sequencer sending the value of a register or an immediate of a qubit with id 36, we can configure it as follows

Sequencer:

fb_com_data        36, R0, 8          # set id to 36, value to be shared in R0, wait 8 ns

Depending on the routing configuration (i.e. which sequencers are configured to receive the data with id 36), the value of R0 will be sent to the feedback queue of the receiving sequencers with the corresponding id.

Additional configuration commands fb_com_cfg and fb_com_extra are available; see the Q1 instruction reference.

Latencies of LINQ-based Feedback Data Types#

The latency of LINQ-based feedback is defined as the time required for data to travel from the source sequencer to the feedback queue of the receiving sequencer. The latency depends on the routing path, the data type being transmitted, size of the data, and the sequencer type

In the table below, we summarize the latencies of different LINQ-based data types based on the routing path. The value in this table reflects the time of travel for a specific data type from the originating Q1 sequencer to the destination Q1 sequencer, excluding the input/output path.

Sequencer Type	Data type	Multi-cast (ns)	Intra-cast (ns)	Self-cast (ns)
Readout	Thresholded Bits	472	250	160
	IQ Values	492	270	164
Time-tag	High-resolution time tags	1260	1000	910
	Time delta	1260	1000	910
	TTL counts	480	236	146
	Low-latency time-tags	480	236	146
All	Q1 registers / immediates	380	150	60

For a complete round trip latency that includes the input path of the specific module to the output path to a different module, use the interactive table below.

Table 1: Interactive table to calculate input-output latencies.

Note

The QTM has a negative input latency of -66 ns. This is because the acquisition window on the QTM starts after the acquire_timetags command is issued, which shifts the entire time grid relative to when the command is scheduled. As a result, the effective input latency appears negative when referenced to the Q1 instruction timeline.

Command	Description
`cluster.clear_router()`	Reset all routing to factory defaults.
`module.set_local_route(id, sequencers=None)`	Intra-cast: route `id` within the module, optionally to a subset of sequencers.
`cluster.set_cmm_route(id, targets)`	Multi-cast: route `id` to specific modules or sequencers via the CMM.
`cluster.set_broadcast(id)`	Broadcast: route `id` to every sequencer in the cluster via the CMM.
`module.clear_router()`	Reset a module’s router configuration to factory defaults.
`module.get_router_config()`	Get the router configuration for the respective module.