Husky glitch width limited? Can't seem to open the HP MOSFET to short. Mixing width+repeat?

vabashiah · February 6, 2024, 5:06pm

We are trying to generate glitch to see if target board’s glitch detector activates, but not sure if Husky outputs the glitch. Thought it would be simple setting up glitch to external trigger on GPIO4, but we are perplexed on not seeing the voltage fall down.

Glitch generation is enabled on HP GLITCH

I can see that via Trigger MCX shows that glitch is enabled at times, but we can’t see on 100 MHz 1GSa/s oscilloscope the actual short from the glitch port. The voltage just “waves sligthly at end”.
Glitch enable times are around 35-70 ns as shown below. HP GLITCH is used. Blue color is the glitch enable, magenta is trigger.

The HP GLITCH MOSFET is IRF7807TRPBF (https://cz.mouser.com/datasheet/2/196/Infineon_IRF7807_DataSheet_v01_01_EN-3363023.pdf) and has rise+fall time 17+6 ns, which is about 43.5 MHz, so can’t open fully faster than that, thus we should be able to see something on 100 MHz scope. That is not counting in also turn-on+turn+off time, which is 12+25 ns. So 60 ns should open fully the MOSFET.

One 35 ns glitch from a repeat:

Repeated 35 ns glitches (zoomed out the previous image)

Doubled the width, now about 70 ns width - this should make the MOSFET open fully, see

Code to accompany so you can see settings

Now I am using it with CW313 and SAM4S from Husky package to try determining what I’m doing wrong.

Setup is the generic script.

import chipwhisperer as cw
%run "../../Setup_Scripts/Setup_Generic.ipynb"

scope.io.glitch_trig_mcx = "glitch"
scope.glitch.enabled = True
scope.glitch.clk_src = 'pll'
scope.clock.pll.update_fpga_vco(600e6)
scope.glitch.output = 'glitch_only'
#scope.glitch.output = 'enable_only'
scope.glitch.trigger_src = 'ext_single'
scope.glitch.repeat = 20
#scope.glitch.arm_timing = "before_scope"

assert scope.glitch.mmcm_locked
print(scope.glitch.phase_shift_steps)

4592

Width and offset setting:

scope.glitch.offset = 0 - 0*scope.glitch.phase_shift_steps
scope.glitch.width = 200000 # - 400000 causes ADC clipped #100
print(f"offset {scope.glitch.offset}, width {scope.glitch.width}")

offset 0, width 200000

200k equals those about 35 ns glitch enable, 400k about 70 ns. The 400k width causes ADC clipping (maybe this is a note to see that it really output the glitches?) 800k for some weird reason clips back to width of maybe 10 ns enable (???)

Using SCOPE_GAIN 18 here, use GPIO4 as trigger

print("Using scope gain", SCOPE_GAIN)
scope.gain.db = SCOPE_GAIN #12
scope.adc.samples = 120000 #50000 #120000
scope.adc.presamples = 10000
scope.trigger.module = 'basic'
scope.trigger.triggers = 'tio4'
scope.arm()

Run the capture which raises the GPIO4, trigger causes glitch enable signals to show:

trace = cw.capture_trace(scope, target, bytearray(16), bytearray(16))
print(scope.errors)

With width at 200k, it goes through without any error, using width 400k causes ADC clipping and the clipped signal when graphed with bokeh looks like:

Is the tall vertical line the glitch we were not able to see on the scope? Since the Y axis is without units and centered, not sure I am looking at voltage fall/short. But since it’s measured over shunt, then it would make sense that it’s short which puts high peak of current for some time.

Glitch width vs repeat on Husky

Repeat and width on Husky is something that I can’t wrap my head right even after multiple reads of the settings documentation. You can have one wide glitch or repeat with some limitation? I’d probably rather want single wider glitch, I can’t quite see how repeat constrains width.

Alex_Dewar · February 6, 2024, 7:02pm

The max width using glitch_only is 50% of a clock cycle. Values above scope.glitch.phase_shift_steps//2 simply overflow, so you’re still getting something between 0 and scope.glitch.phase_shift_steps//2. To get above this width, you need to use enable_only which keeps the glitch active for a full clock cycle. As the glitch is always a full clock cycle long, scope.glitch.width and scope.glitch.offset do nothing if you’re using enable_only.

Repeat simply repeats the glitch on subsequent clock cycles. With enable_only active, this effectively gives you glitches that are multiple clock cycles wide.

Alex

jpthibault · February 6, 2024, 9:00pm

Also, the easiest / best way to understand how the offset and width settings shape the glitch is to run our Husky glitching demo notebook: https://github.com/newaetech/chipwhisperer-jupyter/blob/master/demos/husky/03%20-%20Husky%20Glitching.ipynb

vabashiah · February 7, 2024, 3:05pm

Unfortunately that exact demo always seemed confusing for me, mostly because it shows glitches coupled with logic analyzer in a way that is not usually used together. (Compared e.g. to the old wiki that was for Lite back then)

jpthibault · February 7, 2024, 3:10pm

Fair enough - how could we make it less confusing?

The challenging part for me, in trying to teach how the glitch setting works, is that we have so many knobs and settings, so I’m not sure how to make it not appear overly complicated or overwhelming.

vabashiah · February 8, 2024, 4:39pm

Two things confused me mostly:

the maximum width of glitch - I didn’t know before that you can’t make glitch wider than clk_src cycle, though it was enabled once trigger is raised for “width” of cycles and offset, until repeat is reached
this block diagram of the glitch module - https://chipwhisperer.readthedocs.io/en/latest/_images/cwlitepro_glitch.png

The diagram e.g. doesn’t have pll option as clk_src, which if I understand right on Husky is scope.clock.clkgen_freq speed, based on its PLL.

Left side does not have glitch_only. Since enable_only goes into the AND box, how it could be both enable_only and glitch_only when choosing which signal is used as enable output, but you can’t have both set?

As the glitch is always a full clock cycle long, scope.glitch.width and scope.glitch.offset do nothing if you’re using enable_only

This is confusing to me according to the diagram, as there’s enable_only going into the AND box with the delay line offset and width, but also bypasses it (so yes enable_only could do that, but then glitch_only doc says “Output only the glitch pulses - do not use the clock” which does not seem to agree with the diagram) but is correctly the Husky Glitching demo:

The glitch clock output is high when MMCM1, MMCM2, and glitch enable are all high. (Because scope.glitch.output = “glitch_only” in this example

Maybe a suggestion - create one simple glitching demo for the CW313+ATSAM4S, where you show enable_only and glich_only in 2 sections on a basic trigger, like “Husky triggers” is done. Use the generated pictures from “Husky glitching demo” to show what is happening in each case, how the glitches will look like in these simple cases.
Add scope.io.glitch_trig_mcx = "glitch" saying:

you can connect Glitch Out MCX to see that is how it’s output on oscilloscope. For more experimenting with settings, see “Husky glitching”, where the Logic Analyzer shows how a glitch would be generated for various settings as combination of clocks and enable signals.

I think I now better understand how to use the LA in “Husky glitching demo”, but still have to ask what exactly MMCM1 and MMCM2 signals represent? Feels understanding the internal design would make it also easier to use.

Thanks

Alex_Dewar · February 8, 2024, 11:28pm

Does this diagram make things more clear?

If you extend enable_only for more than one clock cycle (via scope.glitch.repeat), you’ll get multiple glitch pulses in glitch_only. You can also use enable_only as the output to get a single glitch that spans multiple clock cycles.

I think the doc is basically saying, just use glitch_pulses & enable_only instead of (glitch_pulses AND enable_only) XOR clock_only, which would be useful for clock glitching, but not voltage glitching. I’ll update that doc so that it’s more clear.

JP can correct me if I’m wrong here, but I believe these are the .offset and .width delay blocks from the diagram.

jpthibault · February 9, 2024, 2:45am

That’s right; MMCMs are Xilinx PLL modules, which are used here to phase-shift the glitch source clock by the number of steps prescribed by offset and width. MMCM1/2 are internal signals that are used to shape the glitch. The notebook illustrates this visually, but it doesn’t really explain it - noted!

vabashiah · February 27, 2024, 8:16pm

We’ve spent some 2+ weeks trying it out, basically got it working, but still not 100% sure I understand it, looking at results on Husky over shunt and also glitch MCX out, checking chip’s glitch detector on oscilloscope.

Still unable to see from the diagram how “enable_only” works with “width”. We made it experimentally how we wanted, but it was more “just changing parameters around”

jpthibault · February 28, 2024, 2:28pm

scope.glitch.width has absolutely no effect in enable_only mode.
scope.glitch.offset does, however. You can see this in the 03 - Husky Glitching.ipynb notebook (“glitch enable” is your glitch output in enable_only mode).

Clearly, this isn’t as clear as it should be! We’ll try to improve that.