Support qick v2

[cpcepa]

Created a pull request to start the new feature discussion.

Checklist before review:

• Supports 3 opcodes for QICK v2
• New configV2 added to support QICK asm_v2
• To discuss Qibolab v2 and driver support
• able to generate all pulse with EXECUTE_PULSE_SEQUENCE_RAW
• initial tested able to run on PYNQ v3.01 (built with https://github.com/sarafs1926/ZCU216-PYNQ), but only with numpy 1.26.4

Checklist before merge:

• Reviewers confirm new code works as expected.
• Test done on ZCU 216
• Tests are passing.
• Documentation is updated.

[cpcepa]

@rodolfocarobene I created a new ConfigV2 to support new parameters in asmv2. I assume those who use qibosoq endpoint should know which firmware are they running on RFSoC. Though we need more thoughts in qibolab side.

ConfigV2 Field	→	QICK Parameter	Type	Default
reps	→	reps	int	1000
final_delay	→	final_delay	float	100 us
final_wait	→	final_wait	float	0 us
initial_delay	→	initial_delay	float	1 us
reps_innermost	→	reps_innermost	bool	False

Difference between ConfigV1 and V2

Feature	V1	V2
Relaxation	relaxation_time	final_delay
Shots	reps	reps
Averaging	average (bool)	reps_innermost (inverted) it should be a different category
Readout TOF	ro_time_of_flight	Separate config
Soft Avg	soft_avgs	Not in V2
Extra Timing	-	final_wait, initial_delay

[rodolfocarobene]

Hi @cpcepa, thanks for the work! I have a few general comments.

First, what is the difference between Config and ConfigV2? It seems to me that most of the changes are renamings, which I would generally avoid. Then there is the removal of soft_avg, which is fine (I was also planning to remove it), and the removal of ro_time_of_flight, which I don't understand. Where did it go? I would expect something like:

self.trigger(ros=[adc_ch], t=t + self.ro_time_of_flight)

My proposal would be to just keep using Config, removing soft_avgs.

Then, I'm not sure about the pulse scheduling. I think you may have unintentionally introduced a difference with respect to the current qibosoq behavior. This is not necessarily bad, but I think we should discuss it.

Currently, a sequence is executed roughly like this:

• global_time += pulse_0.start_delay
• execute pulse_0 immediately
• global_time += pulse_1.start_delay
• execute pulse_1 immediately

What you are doing instead seems to treat start_delay not as a delay relative to the previous pulse, but as a global/absolute time. I would rather do something along these lines:

for elem in self.sequence:
    # Wait the required amount of time so that the pulse starts at the correct time.
    if isinstance(elem.start_delay, QickRegister):
        self.sync(elem.start_delay.page, elem.start_delay.addr)

    ...

    self.pulse(ch=pulse.dac, name=pulse.name, t="auto")

Also, what exactly have you tested so far? In particular, have you tested this using an actual board, and possibly with qubits? I'm asking mainly to understand what we already know to be functionally correct and what still needs to be tested. For example, from experience I know that delay sweepers in Ramsey-like experiments can be error-prone. If this has already been tested, that's useful to know; otherwise, we'll need to test it.

In any case, I think we should first agree on Config and on the timing behavior. I'm open to changing the timing semantics, but I think it would be better to first port the existing behavior to tProcV2 and only then change it. That would also make the qibolab driver easier to adapt.

After that, we can functionally test all the features. Finally, I can do a more formal code review. Code quality is of course important, but at this stage I think getting the behavior and functionality right is the higher priority.

[cpcepa]

Hi @rodolfocarobene, I will add back ro_time_of_flight since I tested out yesterday and realised I have this shortfall and need to delay the ADC readout.

I also prefer to combine both config, but V1's unit is usually in tproc cycle, V2 is in mircoseconds (us). Can we follow V2 us unit whenever possible? That also means I need to do a conversion from us -> tproc cycle in v1 code, e.g.
cycles = prog.us2cycles(time_us)

For start_delay, I think I overlooked or misunderstood from how it was used here: https://github.com/meeg/qick_demos_sho/blob/main/tprocv2/01_gens-and-readouts.ipynb. Was thinking that since the pulses are added one by one, "t" acts like delay.
May I know where is the function self.sync() from? Closest I can find is sync_all() in asm_v1 and resync() in asm_v2.
I see that it is an instructions in asm_v1.

I am currently running qibosoq on PYNQ v3.0.1 (python3.10), ZCU216 for all the test, and I have qubit access these few days, so will try to finish all testing. Haven't tested any experiment yet because currently we are debugging why qubit not responding.
Pulse generation (check via loop back) is done, I can say that all pulses are supported. Though I will need more testing when dealing with flux pulse since my ZCU216 development board does not support coupling.

I agreed that behavior and functionality right is the higher priority since I am not an expert in this, will need to rely on your expertise to guide me on the functions. Thanks in advance!

[rodolfocarobene]

Yea, let's try to update the config code just so that tproc2 works, eventually we will also drop tprocv1! Thanks for your work!