Timetag Sequencers#

A timetag sequencer is a type of Q1 sequencer which allows

  • The detection and timestamping of threshold crossing events (such as rising or falling edges). Each event is assigned an accurate timestamp — called a timetag.

  • The detection and counting of the aforementioned events for incoming pulses.

  • Fast forwarding of triggers via the LINQ protocol for

    • Threshold crossing events

    • Lookup Table based feedback

  • The generation of TTL (high/low) pulses with high timing precision for both rising and falling edges.

For detailed specifications and a block diagram of the qubit timetagging module, see the module [user guide](../modules/qtm.md).

QTM Block Diagram and Basic Operation#

Block diagram of a Qubit Timetagging Module

I/O Switch#

A switch that controls whether the output or input path of the timetag sequencer is connected to the physical SMP connector.s Hence, a QTM channel can act only either as an input or as an output per sequence. This switch is controlled via IOChannel.mode(). For more details please see the QTM Output API.

Output path#

The output path of the timetag sequencer is quite simple, and can only output TTL high/low signals on a 1 ns timegrid with 39 ps pulse placement precision.

  • The output path is controlled entirely by the latched instruction set_digital, along with real-time instructions such as upd_param or wait for controlling the placement of the pulses on the 1 ns grid. For more details about how the dual-core (Q1 and real-time core) architecture works, please see the Q1 sequencer page

  • The fine_delay argument of set_digital allows finer time precision by using the analog Delay block, seen above.

  • For more details please see the TTL Pulse Generation Tutorial as well as the Q1ASM User Guide.

Input Path#

The input path of the timetag sequencer can be used for timetagging and counting of rising/falling edges and voltage threshold crossings. The input path consists of:

  • Analog Thresholder - Used for the detection of threshold crossing by the input signal. Once the set analog threshold is crossed, this recorded event can be counted and/or timetagged.

  • Time-to-Digital-Converter (TDC) - This component timetags the detected events such as threshold crossing or rising/falling edges. The TDC determines and passes these timetags to the FPGA at a maximum rate of 1 per 44 ns, and has a built-in buffer of 16 entries. By default, 2x oversampling is enabled on the TDC, giving an RMS timetag precision of 20 ps. Other available modes include 4x oversampling and no oversampling, leading to a \(\sqrt(2)\) and \(\frac{1}{\sqrt(2)}\) factor change to timetag precision respectively.

  • Low-Latency Fast Counter - Counts can be recorded in the timetag sequencer in two ways - by counting the timetags produced by the the TDC, or through a low latency counter. When accumulating counts via the TDC output, the maximum sustained counting rate is \(\frac{1}{44 ns} \approx ~ 22.7\) MHz; while, for the low latency counter it is \(\approx 980\) MHz. Counting via TDC or the low-latency counter can be controlled via the API parameter IOChannel.binned_acq_count_source().

  • For more details about the timetagging and counting operation please refer to the QTM Scope Mode Tutorial and the QTM Binned Mode Tutorial.

Note

Note that in scope mode only timetagging is possible, while the binned mode operation includes timetagging (with higher dead-time) as well as counting.

Let us now discuss the available timetagging and counting modes in the timetag sequencer in more detail.

Available Timetagging Modes#

The QTM supports multiple acquisition strategies to balance latency (minimum time between events) and throughput (total number of events). The primary modes and sub-modes of operation of the QTM are as follows:

Mode

Sub-Mode

Dead Time

Feature

Max Events

Use Case

Scope Mode

Continuous

44 ns

Low-Latency Burst

2048 events

General-purpose fast timetagging recording all incoming events

Scope Mode

Windowed

44 ns

Low-Latency Burst

2048 events

General-purpose fast timetagging within specified window(s)

Binned Acquisition

Windowed

300 ns

Low-Latency Counting

3000000 bins

High number of sparser timetags and counting (both fast and slow)

1. Scope Mode#

Scope Mode is the digital equivalent of the analog scope acquisition used in QRM modules. It provides absolute timetagging of all events above the threshold.

The available sub-modes and important features are:

a. Continuous Scope Mode (timetags)

  • Records all incoming events continuously from the start of the acquisition window.

  • Stops only when the sequencer is stopped or when the 2048 event memory is full.

b. Windowed Scope Mode (timetags_windowed)

  • Only acquires timetags within the defined acquisition window.

  • Stores:

    • An 'OPEN' timetag at the window’s start.

    • A 'CLOSE' timetag at the window’s end.

    • A RISE/FALL timetag at every recorded rising/falling edge that crosses the set analog threshold within the acquisition window.

  • Useful to avoid recording noise outside of the relevant measurement period.

c. Low-Latency Burst

  • This allows for acquisition of timetags with lower latency, with timetags recorded as close as 20 ns apart in the QTM scope mode tutorial. This is suitable for short, high-speed bursts.

  • Key details:

    • One must disable TDC oversampling to reduce the timetag processing time of the TDC.

    • TDC has an internal buffer of 16 entries, and entries are passed to the FPGA at 44 ns per timetag.

    • Hence the built-in buffer is limited to 704 ns total.

    • Therefore, if counts arrive with a separation of \(x\) ns, the buffer will fill up after \(\lfloor\frac{704}{44-x}\rfloor\) events

  • After each burst, the system needs idle time to avoid buffer overflows. This mode is ideal when extremely fast detection is required over short durations.

Please see the QTM scope mode tutorial for detailed documentation.

2. Binned Mode#

In this mode, events are detected only during the defined acquisition window and their timetags are recorded relative to a settable reference timestamp. The time reference can be set via the QCoDeS API instruction binned_acq_time_ref(), while the data source (events) for the timetags to be recorded is set using the binned_acq_time_source() parameter. By selecting the binned_acq_time_ref('sequencer') option, the reference time can be set in the sequencer program by the set_time_ref Q1ASM instruction. This instruction can occur multiple times in the sequence program, resetting the time reference for the timetags that will be recorded ahead. For more details please refer to the QTM IOChannel API and the Q1ASM User Guide.

Features:

  • Supports up to 3000000 events per module (in total, all 8 sequencers).

  • Each bin data structure stores, for that acquisition window:

    • the number of counts (i.e., the number of times the set analog threshold was crossed)

    • the time difference between the user defined event and time reference; for example, between the first detection and the start of the window or between the first and second detections.

    • other data validation parameters such as the number of averages.

  • Even though only a single timetag can be recorded per bin, the resolution of the recorded timetag is the same as that set by the TDC resolution (20ps by default, ~28ps if you disable oversampling).

Constraints:

  • Only 1 (relative) timetag can be recorded per bin.

  • To record the timetags of many incoming signals using bins, the acquisition bin must be changed. This must be done in the Q1ASM sequence program by closing the current acquisition window, incrementing/decrementing the bin register, and then starting a new acquisition window. Hence, throughput is determined by the acquisition window duration, instead of the TDC dead-time.

  • Minimum of 300 ns between the start of 2 acquisition windows.

  • If wait_trigger is used to move to the next window, photons arriving too close together may raise trigger conflict warnings. Keeping the required separaton of 300 ns between incoming events will ensure no trigger network conflicts can occur. See the example below for trigger based event counting for more details.

Please see the QTM binned mode tutorial for detailed documentation.

Trigger sources#

In this section we describe the feedback capabilities of the timetag sequencer.

Edge detection based triggers#

When acquiring a digital signal with a QTM module, any rising or falling edge detected during the acquisition window can be mapped to the trigger network. Forwarding signals to the trigger network can be carried out in parallel with the acquisition procedure, and does not require closing of the window.

To send triggers based on edge detection:

  1. Enable trigger forwarding using the IOChannel.forward_trigger_en() parameter.

  2. Select a trigger address to which a trigger is sent on the network using the IOChannel.forward_trigger_address() parameter.

  3. Set the polarity of the incoming signal from which a trigger will be sent to the network, i.e. whether a rising or falling edge is used to send a trigger. This is done using the IOChannel.forward_trigger_mode() parameter.

Note

Trigger forwarding may only be used with signals with a frequency lower than that set by the trigger network latency (252 ns).

Example: trigger based event counting

In this example, trigger forwarding by a timetag sequencer (connected to module.io_channel0) based on a rising edge detection will be used to close an acquisition window. This enables a single event detection to be captured in one acquisition window. This efficiently utilizes the full bin memory of a sequencer store a timetag for every event that is detected. This can enable one to efficiently gather a large number of timetags from a photon source if the photon flux that has an event separation greater than the trigger network latency.

Here are the settings required:

module.io_channel0.mode("input")
module.io_channel0.analog_threshold(THRESHOLD)

module.io_channel0.forward_trigger_en(True)
module.io_channel0.forward_trigger_mode("rising")
module.io_channel0.forward_trigger_address(1)

module.io_channel0.binned_acq_time_ref("sequencer")
module.io_channel0.binned_acq_time_source("first")
module.io_channel0.binned_acq_on_invalid_time_delta("record_0")

The program for sequencer 0:

move            0, R0
move            {acq_reps},R1
move            0, R2

set_scope_en    1
wait_sync       4
set_time_ref

loop:
    acquire_timetags 1, R0, 1, R2, 4
    wait_trigger     1, 4
    acquire_timetags 1, R0, 0, R2, 4
    add              R0, 1, R0
    nop
    loop             R1, @loop   #Repeat loop until R1 is 0

stop

Truth table based triggering#

The truth table allows users to define a set of conditions that map the outcome of thresholded acquisitions, from up to 4 channels, to specific trigger network addresses when those conditions are met.

To use the truth table to send triggers on the network:

  1. The truth table needs to be enabled using the IOChannel.truth_table_en() parameter.

  2. The conditions that will determine the outcome of the truth table will need to be specified using the IOChannel.truth_table_data() parameter.

  3. Enable mapping of the thresholded acquisition to the trigger address using the IOChannel.forward_trigger_en() parameter.

For more details please see the count-based feedback tutorial.