CW305_ECC Clock Cycles

Hi everyone,
The snippet involves the very first move_inhibit=1, in this tutorial, it said,

The set of 8 writes that are blocked by move_inhibit occur on clock cycles 4195 to 4203…

I could see that the left edge of move_inhibit is at 41925 ns. Is it the clock cycle 4195? Further, where can I find the clock frequency that CW305 operate in for ECC point operations? And where are the 8 writes mentioned above?

If I zoom in move_inhibit, there seems more than 8 pulses consisting from bram_rx_wr_en, bram_ry_wr_en, and bram_rz_wr_en. Are these pulses the 8 wirtes?

Hi Alan,
On your waveform, pull up the tb.cycle_count signal.
Now just before bit_counter goes from 0 to 1, you should find bram_r[x|y|z]_wr_en be high for 8 consecutive clock cycles when cycle_count is between 4237 and 4244. Now scroll back to where bit_counter is initialized to 0, and you’ll see that cycle_count is 42 at that point. 4237 - 42 = 4195.

Here’s an example showing this (in this example move_inhibit happened to be low on the first bit, but the same principle applies).

The 8 writes are not pulses; they are burst over 8 consecutive cycles, as you can see here.

In this simulation, the clock is driven with a 6ns period, but that’s a completely arbitrary number, since the attack only concerns itself with numbers of clock cycles, not nanoseconds.


1 Like

Hey Jean,
Always appreciate for your help!

  1. After the above discussions, I just found that I didn’t really understand what bram_r[x|y|z]_wr_en do, what do they exactly mean?
  2. In the section Correaltion Attack, we can see r[x|y|z]read_offset= 205, 473, and 17, respectively. Where can we find theses values?


1- follow the Verilog code, you’ll see that they connect to the BRAM write control.
2- these are the clock cycle indices where the x/y/z BRAMs are read, relative to when bit_counter changes

1 Like

Hey Jean,

  1. Where could I see the x/y/z BRAM read cycles? Could you show me a gtkwave example?
  2. In the section, Cryptograpy Detour, I saw a key word,


Sorry because Verilog code is a total new thing to me, could I ask you where could I find this very keyword in gtkwave? Does the understanding of it bother our attack?

  1. Each bit takes 4204 cycles to process, then we would have 256 times 4204 cycles. Thus we totally need 1, 076, 224 cycles, this is much larger than my CW-Lite’s capability of sample storing, which can only accommodate 24400 samples. Do I mix up the concept of cycles and samples? What’s the difference between them?

This is an instance name, not a signal. See here:

If you want to really understand all this properly, you’ll absolutely need some Verilog fluency. Verilog is quite different from most languages so you can’t really wing your way through this. I’m sure there are good online tutorials (I don’t know of any specific ones to recommend).

From the notebook:
“With a ChipWhisperer-Lite, every trace needs to be captured in several steps, using the sample offset feature”

What we do is run the operation to capture the first 24400 samples. Then we set the sample offset to 24400 (which means "start capturing 24400 samples after the trigger asserts), re-run the exact same operation, and capture samples 24400 - 48799. We repeat this until all ~1M samples of the ECC operation are collected. You can see this in the notebook code for the get_traces() method.


1 Like

Hey Jean,

About the place where I could see x/y/z BRAM read cycles, could you give me a gtkwave example?


The X, Y and Z memories are read these number of clock cycles after cycle_count is updated:

rxread_offset = 205
ryread_offset = 473
rzread_offset = 17

for example here’s the X read: