Maximum number of pulses

[rodolfocarobene]

Hello, is there a maximum number of pulses that a single program can execute? If so, how much is it?

[meeg]

No. These are the limits that might apply:

• The tProc has a limit on program length (number of ASM instructions must be less than the size of the program memory as shown in print(soccfg)). But loops mean that you can have more pulses than you have instructions.
• Each generator has a limit on the memory available for arbitrary envelope tables (total number of IQ pairs added using add_pulse must be less than maxlen as shown in print(soccfg)). But a pulse that is repeated, or multiple pulses that use the same envelope, do not consume memory.

Why?

[rodolfocarobene]

Thanks for the fast answer.
We (@JavierSerranoGarcia) were trying a "flipping" experiment, where you apply an increasing number of pairs of pi-pulses to see gate fidelity and T1 (2 pi-pulses then measurement, 4 pi-pulses then measurement..., all in different qick-programs). Ideally you want all your measurement to be zero, actually you see some kind of exponential decay.

For sure the code was not optimal since I was actually calling add_gauss and set_pulse_register before every pulse, even if it clearly was not necessary, but in any case we had two problems:

• after ~40 pulses the results stopped making sense: the experiment was here composed of pi-pulses (from 40 to 140) and a measurement. While before 40 pulses you can see the exponential decay, as it should be, in this region we obtained always the qubit excited state, no matter what.
• after 144 pulses we started getting this error, that I thought could be related to a maximum memory size:

...
  File "/usr/local/share/pynq-venv/lib/python3.8/site-packages/qick/qick.py", line 2368, in reload_program
    np.copyto(self.tproc.mem.mmio.array[:len(self.binprog)], self.binprog)
  File "<__array_function__ internals>", line 200, in copyto
ValueError: could not broadcast input array from shape (2070,) into shape (2048,)

However we are using the rfsoc4x2 that has:

tProc: program memory 1024 words, data memory 1024 words

Even considering the useless add_gauss/set_pulse_register we should be around 144*3=432 instructions (plus ~10 for measurement and loop), but maybe we reached the envelope memory 65536 samples with 144 pulses of ~30 ns gaussians.

If this is the case, talking a bit more generally, which is the best way to implement a circuit that repeats pulses?
Let's say that we have a circuit with gates A, B, C, A, C, B in this order.
What I am doing now is using:

add_gaus(parameters for A)
set_pulse_register(parameters for A)
pulse()

add_gaus(parameters for B)
set_pulse_register(parameters for B)
pulse()

add_gaus(parameters for C)
set_pulse_register(parameters for C)
pulse()

add_gaus(parameters for A)
set_pulse_register(parameters for A)
pulse()

add_gaus(parameters for C)
set_pulse_register(parameters for C)
pulse()

add_gaus(parameters for B)
set_pulse_register(parameters for B)
pulse()

But I think in this way I am filling the memory of the DAC with a lot of repeated data, is it correct?

[meeg]

Yes, that error is coming from the program memory. Your weird results might be happening because your inefficient program is causing the program execution in the tProc to fall behind the times when you want your pulses to be played, but hard to say.

You should understand that the commands you write in your QICK program do not map one-to-one with ASM instructions; some are not ASM at all, some are macros that get translated to multiple ASM instructions. If you want to see the ASM instructions, print the program (print(prog), as done at the end of the 00 demo).

Yes, in your example you should remove the duplicate add_gaus commands.

[rodolfocarobene]

Ok, thank you very much for the answer!