DC Jack / USB Power

There are two main sources of power which can be used for all FPGA power supplies (VCC-INT, VCC-IO, and VCC-AUX). By default this is the USB connector, but this is limited by USB specs to a maximum of 500 mA.

If using a larger design in the FPGA you may exceed these limits, in which case you must move the switch to use the DC-Jack. This jack requires a 5.0V power supply capable of a suitable amount of current for your design (suggested: 2.0A).

Internal / External VCC-INT

The internal power supply provides a source of 1.0V for the VCC-INT. This supply can be programmed slightly above/below 1.0V to compare the effects of different VCC-INT supplies on the FPGA design. Details of the power supply are given in section TODO XREF. The internal supply can provide up to 6.0A for the VCC-INT rail.

There is also two banana jacks which can be connected to a 1.0V lab supply. You must be very careful to ensure you do not exceed 1.10V on this input, as beyond that range you risk damaging the FPGA.

The choice of internal/external is selected with the switch. There is a ferrite bead + large capacitors after this switch, so note that you cannot use the banana jack inputs as a voltage glitch insertion method. Instead you must insert them directly into the SMA connectors, described later.

Shunt Resistor Connections

The following shows the components around the shunt resistor:

Schematically, this is shown below. NOTE: the schematic flows in the "opposite" direction of the PCB. In the PCB power flows left to right, in the schematic it flows right to left.

A brief description of each element is given below.

VCC-INT Decoupling Capacitors

The optional decoupling capacitors for the VCC-INT rail are shown on the underside of the PCB here:

This capacitors are typically not mounted when using the shunt resistor to measure power waveforms.

VCC-AUX Shunt Resistor

The VCC-INT shunt is the primarily power measurement point, as it provides power measurement for both designs inside the FPGA, along with the logic responsible for decrypting bitstreams (as reported at https://eprint.iacr.org/2016/249.pdf).

There may be additional information in the VCC-AUX power supply however, for example monitoring JTAG state transitions. There is a secondary shunt position (by default with no shunt mounted) for exploration of the VCC-AUX power supply. This can be seen in the schematic here:

The shunt is located on the rear side of the PCB, as shown here:

If using this shunt, you must remove resistor R26 (which has a metal slug 0-ohm resistor mounted) and replace with an appropriately sized 0805 resistor (suggested: 1 ohm). You must also remove capacitor C98, C95, C97, C94, and C93. They can be seen in the above photo.

Power Supply Source

You can turn the power to the FPGA on or off using the following switch:

When in the "OFF" mode the VCC-INT, VCC-IO, and VCC-AUX supplies are turned off. In addition the communications interfaces are all disabled to avoid back-powering the FPGA via the IO pins. If you have external connections (such as driving a clock from the ChipWhisperer) you need to ensure they are also disabled when the power is turned off.

When in the "AUTO" mode, the state of the power supplies can be controlled from the computer. Typically "AUTO" mode is used as it allows the computer to power cycle the device.

Low-Noise Power Supplies

Optional low-noise linear power supplies are available, which fit into the connectors around the switch-mode power supply. They have less power handling capabilities than the on-board switch-mode supplies, but have reduced noise that ends up injected into the PCB (and thus on the power traces).

These power supplies are only used for VCC-IO and VCC-AUX. Like the on-board supplies they will be disabled when the power to the FPGA is switched off using either the API interface or the target power switch.

If you wish to have the lowest-noise power source, you must mount the VCC-IO and VCC-AUX low-noise supplies, and also use an external supply for the VCC-INT supply.

GPIO Header

A 40-pin header is mounted at JP3. This female header also comes with a dual-sided male 40-pin header which ships which each PCB, allowing you to use either gender of connectors with this header.

The pinout of the header is marked on the PCB. All pins are routed to 3.3V VCC-IO banks on the Artix 7 FPGA. The layout of the header is such that the following can directly be plugged into the board:

• Digilent Inc PMOD devices

• NewAE OpenADC Module

20-Pin ChipWhisperer Connector

The bottom right side of the PCB contains a 20-pin connector that follows the standard ChipWhisperer pinout. This connector has ESD diodes present on the PCB to protect both the FPGA from external transients, and from glitches inserted into the FPGA from exiting the board and damaging external test gear.

LEDs

SMA Connectors

Three SMA connectors are present on the board. Two are routed to IO pins on the FPGA, and one routes directly to the on-board PLL.

Switches

Two user switches are provided: one push-button, and one 4-item DIP switch.

The push-button (SW4) routes to FPGA pin R1.

The dip-switch (S2) routes to FPGA pins J16, K16, K15, and L14 (see PCB silkscreen). With generic designs that dip-switch has the following uses:

See the example design documentation for more details.

Windows Drivers

Signed Windows drivers are provided in the GIT repository, or can be downloaded from here. To install drivers:

• If you don't have a clone of the GIT repository, download & unzip the zip-file somewhere.
• Plug the USB cable in, and once Windows detects the board you will be able to point it to a folder with drivers. Point it to either (a) the unzipped folder if you downloaded drivers, or (b) the folder /chipwhisperer/hardware/victims/cw305_artixtarget/usb_driver/ if using the GIT repository.

Note you can also try using the installer present in this folder, but it's suggested instead to point the Windows installer to the driver folder.

Linux Drivers

If you have previously setup the CW-Lite or CW-1200 on Linux, you should already have a rules.d file with some NewAE products. You can add the following to get the CW305 working:

# allow users to claim the device
SUBSYSTEM=="usb", ATTRS{idVendor}=="2b3e", ATTRS{idProduct}=="c305", MODE="0664", GROUP="plugdev"

If you haven't previously set this up, see the page Linux Driver Setup for details.

Connecting and Programming

from chipwhisperer.capture.targets.CW305 import CW305

cw = CW305()
cw.con(bsfile=r"C:\chipwhisperer\hardware\victims\cw305_artixtarget\fpga\vivado_examples\aes128_verilog\aes128_verilog.runs\impl_35t\cw305_top.bit", force=False)

If doing development, you probably want to set the force flag to "True". This will ensure you always get a newly programmed FPGA with the latest bitstream.

Running AES-128 Example

from chipwhisperer.capture.targets.CW305 import CW305

cw = CW305()
cw.con(bsfile=r"C:\chipwhisperer\hardware\victims\cw305_artixtarget\fpga\vivado_examples\aes128_verilog\aes128_verilog.runs\impl_35t\cw305_top.bit", force=False)

test_key = [0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6, 0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c]
test_inp = [0x6b, 0xc1, 0xbe, 0xe2, 0x2e, 0x40, 0x9f, 0x96, 0xe9, 0x3d, 0x7e, 0x11, 0x73, 0x93, 0x17, 0x2a]
exp_result = [0x3A, 0xD7, 0x7B, 0xB4, 0x0D, 0x7A, 0x36, 0x60, 0xA8, 0x9E, 0xCA, 0xF3, 0x24, 0x66, 0xEF, 0x97]

cw.loadEncryptionKey(test_key)
cw.loadInput(test_inp)
cw.go()
result = cw.readOutput()

print "ACT: "+" ".join(["%02X"%c for c in result])
print "EXP: "+" ".join(["%02X"%c for c in exp_result])

from chipwhisperer.capture.targets.CW305 import CW305
import random

cw = CW305()
cw.con(bsfile=r"C:\chipwhisperer\hardware\victims\cw305_artixtarget\fpga\vivado_examples\aes128_verilog\aes128_verilog.runs\impl_35t\cw305_top.bit", force=False)

test_key = [0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6, 0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c]

plaintexts = []
ciphertexts = []

for tnum in range(0, 20):
    pt = [random.randint(0, 255) for i in range(0, 16)]
    cw.loadEncryptionKey(test_key)
    cw.loadInput(pt)
    cw.go()
    ct = cw.readOutput()

    plaintexts.append(pt)
    ciphertexts.append(ct)

    print "result %d:"%tnum
    print " pt: " + " ".join(["%02x"%d for d in pt])
    print " ct: " + " ".join(["%02x"%d for d in ct])

#Example - saving to text
ptfile = open("plaintexts.txt", "w")
ctfile = open("ciphertexts.txt", "w")
for i in range(0, len(plaintexts)):
    ptfile.write(" ".join(["%02x"%d for d in plaintexts[i]]) + "\n")
    ctfile.write(" ".join(["%02x"%d for d in ciphertexts[i]]) + "\n")

ptfile.close()
ctfile.close()

#Example - saving to MATLAB workspace
import scipy.io
scipy.io.savemat('pt_ct_mat', {'plaintexts':plaintexts, 'ciphertexts':ciphertexts, 'key':test_key})

Accessing FPGA Registers

See the FPGA Projects section for important details of the FPGA design framework.

Turning off USB Clock & Triggering the FPGA

You can disable the USB interface clock (i.e., the clock used by Address/Data lines). Generally this is recommended during the power measurement, as a separate clock is provided for clocking the cryptographic module. The clock can be turned off with:

cw.usb_clk_setenabled(False)

This will reduce noise in the power measurement.

Once the USB clock is off, you must use a special trigger IO pin (since the address/data interface is disabled). This trigger pin can be toggled to trigger your cryptographic core, rather than relying on a register in your FPGA design.

A complete example of a power measurement might look like this:

#arm scope here
cw.usb_clk_setenabled(False)
cw.usb_trigger_toggle()
#wait for scope to complete here
cw.usb_clk_setenabled(True)

You may wish to add a small delay (such as {time.sleep(0.05)}) after turning off the clock.

You may also need to add a delay after triggering the pin - you don't want to turn the clock back on right away, but depending on your scope module it may report the trigger event has occurred before the capture is complete.

Setting PLL Frequency

The CW305 contains a 3-channel PLL. This is provided by a CDCE906 chip, which as the following routing diagram shows contains an extremely flexible architecture:

CDCE906 PLL Architecture, with CW305 Connections Marked

In the software, PLL1 and PLL2 are fixed to FPGA pins N13 and E12 respectively. The SMA output connector X6 can be connected to any of the PLLs (PLL0, PLL1, PLL2). This allows you to get a phase-matched clock on X6 that corresponds perfectly with a clock being fed to the FPGA. Due to the relative complexity of the PLL architecture, it's recommended to use an indirect API call method described below:

You can use the ChipWhisperer-Capture GUI to control the board, and translate your commands there into commands fed into the API. Doing this requires looking at the "Scripting Output" window. For example when performing a certain series of actions, the following might be printed to the window:

['Target Settings', 'ChipWhisperer CW305 (Artix-7)', 'PLL Settings', 'CLK-SMA (X6)', 'PLL0 Frequency', 15000000.0]
['Target Settings', 'ChipWhisperer CW305 (Artix-7)', 'PLL Settings', 'CLK-SMA (X6)', 'CLK-SMA Enabled', True]

cw.findParam(['PLL Settings', 'CLK-SMA (X6)', 'PLL0 Frequency']).setValue(15000000.0)
cw.findParam(['PLL Settings', 'CLK-SMA (X6)', 'CLK-SMA Enabled']).setValue(True)

>>> cw.pll
<chipwhisperer.hardware.naeusb.pll_cdce906.PLLCDCE906 object at 0x068CBDD0>

Setting VCC-INT

You can adjust the VCC-INT voltage using the following command:

#Set vcc-int to 0.95V
cw.vccint_set(0.95)

Turning Power On/Off

In addition to adjusting the VCC-INT supply, you can power cycle the FPGA target section. This can be used when you might expect faults to occur (such as after performing a glitch attack), where you want to ensure there are no errors such as CMOS latch-up occurring that can only be cleared by a power cycle.

Checking FPGA Status

Using from Other Languages

The provided modules are written in Python, but any language which is supported by libusb can talk to the hardware. This will require you to write your own lower-layer driver and is officially unsupported by NewAE.

If using from other software (such as MATLAB), it is suggested to use the existing Python interface, which can be done via a simple command-line interface too. The Python interface is guaranteed to maintain compatibility with future changes in the SAM3U firmware.