Discussions on Python software that powers the ChipWhisperer system
#1453 by ExMachina
Thu Jul 13, 2017 3:26 am

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?
Last edited by ExMachina on Mon Jul 17, 2017 4:45 am, edited 1 time in total.
#1463 by gdeon
Fri Jul 14, 2017 8:13 am
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?
#1464 by ExMachina
Fri Jul 14, 2017 8:24 am

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.
#1466 by gdeon
Fri Jul 14, 2017 3:28 pm
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.
(1.24 MiB) Downloaded 65 times
#1548 by ExMachina
Tue Aug 29, 2017 4:06 am

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
#1552 by coflynn
Wed Aug 30, 2017 9:15 pm
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...

Who is online

Users browsing this forum: No registered users and 2 guests