Times when we fire a pulse seems wrong

[JavierSerranoGarcia]

Hi @rodolfocarobene, I am testing the qibosoq interpolated version by sending different types of pulses and plotting them into the oscilloscope. I already did the same with qick and things worked as expected. Now, using qibosoq, I see the duration of the pulses are Ok but the time when they are fired is weird. I am wondering if this is the way it was programmed. In addition, how can we send pulses at the same time?

The pulses are: `pulse_fl_1 = Rectangular( frequency = 0, #MHz amplitude = -0.5, relative_phase = 0, start_delay = 0, duration = 1., name = "flux_pulse", type = "readout", dac = 0, adc = 0 )

pulse_fl_2 = Rectangular( frequency = 0, #MHz amplitude = -0.5, relative_phase = 0, start_delay = 0.0, duration = 2., name = "flux_pulse", type = "readout", dac = 0, adc = 0 )

pulse_drive_1 = Rectangular( frequency = 100, # float in MHz amplitude = 0.5, # float in [-1, 1] relative_phase = 0, # int in degrees start_delay = 0.0, # float in us duration = 0.5, # float in us name = "id1", # str mixer_frequency = 150.0, # float in MHz type = "readout", # str in {"readout", "drive"}

rel_sigma = 6,

dac = 5, # int adc = 0, # optional int )

pulse_drive_2 = Rectangular( frequency = 100, # float in MHz amplitude = 0.5, # float in [-1, 1] relative_phase = 0, # int in degrees start_delay = 0., # float in us duration = 0.5, # float in us name = "id2", mixer_frequency = 150.0, # float in MHz # str type = "readout", # str in {"readout", "drive"}

rel_sigma = 5,

dac = 5, # int adc = 0, # optional int )

pulse_ro = Rectangular( frequency = 200, #MHz amplitude = 0.5, relative_phase = 0, start_delay = 0., duration = 2., name = "flux_pulse", type = "readout", dac = 14, adc = 0 ) sequence = [pulse_fl_1, pulse_drive_1, pulse_ro,pulse_fl_2 , pulse_drive_2]`

[rodolfocarobene]

Hi @JavierSerranoGarcia , this is quite weird. Pulses should start immediately when start_delay=0

https://github.com/qiboteam/qibosoq/blob/faa13a2bfb36c996fb8b24aa9dc04fa67376e84c/src/qibosoq/programs/flux.py#L159-L161

Can you share the working QICK code? Also, would be nice to know if this problem appears also with standard firmwares or is linked to the interpolated channels. Moreover, does the frequency part work?

[JavierSerranoGarcia]

The qick program:

(pynq-venv) xilinx@ZCU216b-pynq:~/logs$ cat program.log
INFO :: 2024-05-10 08:02:12 ::  
// Program

        synci 700;
        regwi 0, $15, 0;
        regwi 0, $14, 0;
LOOP_J: synci 50;
        regwi 0, $22, 0;                        //phase = 0 | freq = 0
        regwi 0, $24, -1073676288;              //gain = -16383 | addr = 0
        regwi 0, $31, 0;                        //mode3 = 0
        regwi 0, $26, 590131;                   //stdysel | mode | outsel = 0b01001 | length = 307 
        regwi 0, $16, 16;                       //out = 0b0000000000010000
        seti 7, 0, $16, 181;                    //ch =0 out = $16 @t = 0
        seti 7, 0, $0, 191;                     //ch =0 out = 0 @t = 0
        regwi 0, $27, 0;                        //t = 0
        set 0, 0, $22, $24, $26, $0, $31, $27;  //ch = 0, pulse @t = $27
        synci 530;
        regwi 2, $12, 3810;                     //phase = 0 | freq = 3810
        regwi 2, $14, 1073676288;               //gain = 16383 | addr = 0
        regwi 2, $21, 16777216;                 //mode3 = 16777216
        regwi 2, $16, 590039;                   //stdysel | mode | outsel = 0b01001 | length = 215 
        regwi 0, $16, 16;                       //out = 0b0000000000010000
        seti 7, 0, $16, 181;                    //ch =0 out = $16 @t = 0
        seti 7, 0, $0, 191;                     //ch =0 out = 0 @t = 0
        regwi 2, $17, 0;                        //t = 0
        set 1, 2, $12, $14, $16, $0, $21, $17;  //ch = 5, pulse @t = $17
        synci 530;
        regwi 5, $12, 87381333;                 //freq = 87381333
        regwi 5, $13, 0;                        //phase = 0
        regwi 5, $15, 16383;                    //gain = 16383
        regwi 5, $16, 591053;                   //phrst| stdysel | mode | | outsel = 0b01001 | length = 1229 
        regwi 0, $16, 16;                       //out = 0b0000000000010000
        seti 7, 0, $16, 181;                    //ch =0 out = $16 @t = 0
        seti 7, 0, $0, 191;                     //ch =0 out = 0 @t = 0
        regwi 5, $17, 0;                        //t = 0
        set 5, 5, $12, $13, $0, $15, $16, $17;  //ch = 14, pulse @t = $17
        synci 700;
        regwi 0, $22, 0;                        //phase = 0 | freq = 0
        regwi 0, $24, -1073676288;              //gain = -16383 | addr = 0
        regwi 0, $31, 0;                        //mode3 = 0
        regwi 0, $26, 590438;                   //stdysel | mode | outsel = 0b01001 | length = 614 
        regwi 0, $16, 16;                       //out = 0b0000000000010000
        seti 7, 0, $16, 181;                    //ch =0 out = $16 @t = 0
        seti 7, 0, $0, 191;                     //ch =0 out = 0 @t = 0
        regwi 0, $27, 0;                        //t = 0
        set 0, 0, $22, $24, $26, $0, $31, $27;  //ch = 0, pulse @t = $27
        synci 699;
        regwi 2, $12, 3810;                     //phase = 0 | freq = 3810
        regwi 2, $14, 1073676288;               //gain = 16383 | addr = 0
        regwi 2, $21, 16777216;                 //mode3 = 16777216
        regwi 2, $16, 590039;                   //stdysel | mode | outsel = 0b01001 | length = 215 
        regwi 0, $16, 16;                       //out = 0b0000000000010000
        seti 7, 0, $16, 181;                    //ch =0 out = $16 @t = 0
        seti 7, 0, $0, 191;                     //ch =0 out = 0 @t = 0
        regwi 2, $17, 0;                        //t = 0
        set 1, 2, $12, $14, $16, $0, $21, $17;  //ch = 5, pulse @t = $17
        synci 530;
        waiti 0, 0;
        synci 50;
        synci 35;
        mathi 0, $15, $15 + 1;
        memwi 0, $15, 1;
        loopnz 0, $14, @LOOP_J;
        end ;`

We see that after every pulse there is a synci that delay the next pulse.

Channel 5 is interpolated and seems it works but I have not checked yet if the right frequency is sent,

Regarding other firmwares I will try later

[rodolfocarobene]

Yes, there is indeed always the synci instruction, but that should not be the case...

We have to check if this is something introduced by QICK (maybe with interpolated channel it is required to wait a bit?) or not. If this is the case with other firmware versions this should not happen.

Moreover, another possible source of error could be a mismatched version between the qibosoq client and the qibosoq server, I believe

[JavierSerranoGarcia]

Hi @rodolfocarobene, which version of qibosoq and qick we should use on both sides?

[rodolfocarobene]

The interpolated branch of qibosoq, both for the client and the server. QICK should be of version <=0.2.249

[JavierSerranoGarcia]

Hi @rodolfocarobene, we are using version 0.2.230, qibosoq in the interpolated branch, and the client and server running both in the board.

[rodolfocarobene]

Hi Javier, version 0.2.230 should be supported. If I remember correctly I also have tested it when I was at TII. I would try to debug the problem adding some "print" in the server code.

For example you could add print(obj_sequence) at the end of this:

https://github.com/qiboteam/qibosoq/blob/30aa3de9cb0b6431aa4154a7c1c51d393009a0b2/src/qibosoq/server.py#L23-L34

In this way we will be able to understand if the problem (not having a fixed start_delay) is in the communication protocol or later