hey ,I am working on clock glitch attack and during the process i have to glitch at specific clk cycle and accordingly i set the External offset and attacked but it doesn’t yield any results but when i have done sweep with range of EO’s i am getting successful glitch ,But this is not the position where i really need to glitch and it shouldn’t give any correct results but here it is happening . And my guess is there is delay between the glitch happen and the EO we configured , So is there any way i can calculate this delay.
I’m not sure if I understand your question correctly.
First, it sounds like you’re asking why the glitch does not occur at the same time that Husky is triggered. The glitch is not immediate: there is a fixed delay that is in addition to scope.glitch.ext_offset; this delay depends on the trigger module you are using (scope.trigger.module); for the basic module it is 7 clock cycles.
It also sounds like you are observing successful glitches but at a different time than you would expect. This will depend on your target so I really can’t help with that. Since in this case you have an FPGA target, you could try running a simulation to try to understand why successful glitches happen when they do.
I hope this helps!
Thanks, that helps. I’m measuring a total trigger-to-glitch delay of about 54 cycles on a CW305 with husky at 45 MHz with scope.trigger.module = ‘basic’. After subtracting your 7 cycles for the basic module, I have ~47 cycles left. Where does the rest come from — the ext_single arming path, CDC into the glitch MMCM, or fixed pipelining inside scope.glitch between ext_offset expiring and the glitch edge appearing on HS2?
Are you sure that you are measuring correctly, with the correct clock?
The glitch is 7 cycles after the trigger event, plus scope.glitch.ext_offset cycles, measured using the clock specified by scope.glitch.clk_src. There are no additional delays.