Topic Title

Hi,

I have been looking into the CW code to better understand what is happening. It took me a while to understand how SAM3U,The FPGA and ACD and such are working together (and how the code interfaces).



I will do more documentation(or is it already somewhere?) but for the record/please review

The python code uses a custom protocol to talk (via libusb) to the SAM3U chip

The SAM3U chip runs firmware (firmware hardware/capture/chipwhisperer-lite/sam3u_fw) with some functionality:

Programming the FPGA
Doing target UART -> USB protocol translations(signal go through the FPGA)
Programming the AVR target (signal go through the FPGA)
Pumping the ACD data out of the FPGA to the PC
But mostly talking to the FPGA over a large bus

The FPGA chip is programed mostly in verilog (hardware/capture/chipwhisperer-lite/hdl hardware/common and
openadc/hdl/example_targets) using makeise.

It works mostly as as tmuxing device (passing data depending on a few register settings)
Does clock generation (using DMC's)
Has a few registers (muxing/routing)
Configuration of tiggers/routing of clogs
Configuring openADC like Using internal/external clock for the ADC

Something like that?
I also watched http://scanlime.org/ 's nice video on glitching usb and was wondering is the FPGA would not be able to directly generate those few usb messages?

[gdeon]

This diagram looks largely correct - nice work. We have a few more diagrams in our training slides - I'll see if there's a high level block diagram that might help you further.

I've seen a bit of Micah's video but I can't remember much of it right now. Are you asking if the FPGA could directly talk to the PC? Or are you asking if the FPGA could generate USB messages to glitch the target boards?

Hello,

I would like to know if there is enough room in the FPGA to start implementing more complex signal/triggers as an alternative to the serial interface (say I want to glitch some SPI or usb based device) hence I am trying to get answer to the second question: if the FPGA could generate USB messages to glitch the target boards.

The diagram was created with draw.io and the PNG has the source integrated.

[gdeon]

I've attached a section from the ChipWhisperer training at Blackhat USA 2016. You might be interested in page 4 (block diagram of the entire ChipWhisperer toolchain) or some of the following slides for finer details about clock routing, FPGA limitations, etc.

It is probably not possible (and definitely not advisable) to add a USB decoder to the ChipWhisperer's FPGA - it's almost out of space already. Instead, you should use something like a GoodFET/GreatFET - like Micah did - to do this. It's possible to synchronize devices on the same USB hub (because they share the same clock signals) so you should be able to keep both the ChipWhisperer and the FET in sync.

Hi,

I am currently trying to recompile the FPGA code for the CW-lite but can not complete the process without making modifications to constrains. The second thing I am running into is that the CW software detect "a debug build??" and
does not want to do the fine adjust and similar. (I ran the ip core generation wizards). for short:

Am I missing something (like instructions), doing something wrong or is the code not fully present/working?
I want to try and enable some basic triggers(pattern or even just tigger after x pulses) on the CW-lite.

Currently some timing constraint( Component Switching Limit Checks: TS_clkgen = PERIOD TIMEGRP "clkgen" TS_clk_usb HIGH 50%;
) is not met

[coflynn]

The timing constraint failure is a known issue - a bunch of the timing constraints get set too fast due to the DCM blocks... none of the clocks are really valid beyond ~120 MHz (the ADC speed is 105 MHz max, you can push it a little beyond that). The problem is the 4x clock multiplication causes it to think there is a much faster clock. I was never able to properly override this, since I can't relax the input requirement safely, but it seemed to ignore me setting an output frequency.

For the "debug build" you need to build the .zip file. I assume this is the same as the github issue with more details of the PR build process? Let me know if not...

Hackaday also has a nice , but slighty outdated overview