NEO430 Puts A Custom MSP430 Core In Your FPGA

April 27, 2020 by Sven Gregori 18 Comments

We are certainly spoiled by all the microcontroller options nowadays — which is a great problem to have. But between the good old 8-bit controllers and an increasing number of 32-bit varieties, it almost seems as if the 16-bit ones are slowly falling into oblivion. [stnolting] particularly saw an issue with the lack of 16-bit open source soft cores, and as a result created the NEO430, an MSP430 compatible soft processor written in VHDL that adds a custom microcontroller to your next FPGA project.

With high customization as main principle in mind, [stnolting] included a wide selection of peripherals and system features that can be synthesized as needed. Not limiting himself to the ones you would find in an off-the-shelf MSP430 controller, he demonstrates the true strength of open source soft cores. Do you need a random number generator, CRC calculation, and an SPI master with six dedicated chip select lines? No problem! He even includes a Custom Functions Unit that lets you add your own peripheral feature or processor extension.

However, what impresses most is all the work and care [stnolting] put into everything beyond the core implementation. From the C library and the collection of examples for each of the controller’s features, so you can get started out of the box with GCC’s MSP430 port, to writing a full-blown data sheet, and even setting up continuous integration for the entire repository. Each topic on its own is worth looking at, and the NEO430 offers a great introduction or reference for it.

Of course, there are some shortcomings as well, and the biggest downer is probably the lack of analog components, but that’s understandable considering your average FPGA’s building blocks. And well, it’s hard to compete with the MSP430’s ultra low-power design using an FPGA, so if you’re thinking of replicating this watch, you might be better off with a regular MSP430 from a battery lifetime point of view.

Researchers Break FPGA Encryption Using FPGA Encryption

April 23, 2020 by Elliot Williams 18 Comments

FPGAs are awesome — they can be essentially configured into becoming any computing device you want. Simply load your selected bitstream into the device on boot, and it behaves like a different piece of hardware. With great power comes great responsibility.

You might try to hack a given FPGA system by getting between the EEPROM that stores the bitstream and the FPGA during bootup, but FPGA manufacturers are a step ahead of you. Xilinx 7 series FPGAs have an onboard encryption and signing engine, and facilities for storing a secret key. Once the security bit is set, bitstreams coming in have to be encrypted to protect from eavesdropping, and HMAC-signed to assure that they are authentic. You can’t simply read the bitstream in transit or inject your own.

Researchers at Ruhr University Bochum and Max Planck Institute for Cybersecurity and Privacy in Germany have figured out a way to use the FPGA’s own encryption engine against itself to break both of these security guarantees for the entire mainstream 7-series. The attack abuses a MultiBoot function that allows you to specify an address to begin execution after reboot. The researchers send 32 bits of the encoded payload as a MultiBoot address, the FPGA decrypts it and stores it in a register, and then resets because their command wasn’t correctly HMAC signed. But because the WBSTAR register is meant to be readable on boot after reset, the payload is still there in its decrypted form. Repeat for every 32 bits in the bitstream, and you’re done.

Pulling off this attack requires physical access to the FPGA’s debug pins and up to 12 hours, so you only have to worry about particularly dedicated adversaries, but the results are catastrophic — if you can reconfigure an FPGA, you can make it do essentially anything. Security-sensitive folks, we have three words of consolation for you: “restrict physical access”.

What does this mean for Hackaday? If you’re looking at a piece of hardware with a hardened Xilinx 7-series FPGA in it, you’ll be able to use it, although it’s horribly awkward for debugging due to the multi-hour encryption procedure. Anyone know of a good side-channel bootloader for these chips? On the other hand, if you’re just looking to dig secrets out from the bitstream, this is a one-time cost.

This hack is probably only tangentially relevant to the Symbiflow team’s effort to reverse-engineer an open-source toolchain for this series of FPGAs. They are using unencrypted bitstreams for all of their research, naturally, and are almost done anyway. Still, it widens the range of applicability just a little bit, and we’re all for that.

[Banner image is a Numato Lab Neso, and comes totally unlocked naturally.]

An FPGA And A Few Components Can Make A Radio

April 18, 2020 by Jenny List 18 Comments

There was a time when making a radio receiver involved significant work, much winding of coils, and tricky alignment of circuitry. The advent of Software Defined Radio (SDR) has moved a lot of this into the domain of software, but there is of course another field in which a radio can be created via code. [Alberto Garlassi] has created a radio receiver for the AM and HF bands with a Lattice MachXO2 FPGA and minimal external components.

He describes it as an SDR, which given that it’s created from Verilog, is a term that could be applied to it. But instead of using an SDR topology of ADC and digital signal processing, it implements a surprisingly traditional direct conversion receiver.

It has a quadrature AM demodulator which has a passing similarity to an SDR with I and Q phased signals, but that’s where the similarity ends. Frequency selection is via an oscillator controlled from a serial port, and there is even a PWM amplifier on board that can drive a speaker. The result can be seen in the video below, and as you can hear the direct conversion with quadrature demodulator approach makes for a very effective AM receiver.

If this is a little much but you still fancy a radio with minimal components, you should have a look at the Silicon Labs range of receiver chips.

Continue reading “An FPGA And A Few Components Can Make A Radio” →

An RF Engineer’s FPGA Learning Journey

March 12, 2020 by Al Williams 3 Comments

[KF5N] admits he’s not a digital design engineer; he’s more into the analog RF side of things. But he’s recently taken on a project to communicate between a Ubuntu box and an Intel MAX10 FPGA. He did a presentation at a recent ham radio convention about what he’d learned and how you could get started.

The video talks a lot about the Intel (used to be Altera). However, the nearly 40 minute video after the break isn’t a step-by-step tutorial so even if you are interested in other devices, you’ll probably enjoy watching it. If you’ve programmed even one FPGA, this video likely won’t hold your interest — you aren’t the target audience. However, at about 00:31 he does recommend some books and some very inexpensive FPGA boards, so it’s not a total wash.

[KF5N] talks about what an FPGA is and how it’s different from a microcontroller. He also recommends Cornell’s [Bruce Land’s] course materials. He wasn’t a big fan of the online courses he tried. Of course, since he’s using an Intel chip, he also recommended the Intel courses. A lot of the video covers how to save on getting a development board. The Cornell class calls for a $250 board that is pretty powerful. That’s also pretty expensive, so he recommends a lighter version for about $85.

He also talks about the toolchain and his project to interface to his Linux box. He wound up with an SPI interface that ran up to 30 MHz. He also talks about using Julia to build a driver to talk to the interface on the PC side.

We didn’t notice him mentioning our own FPGA bootcamp, although he did mention projects on Hackaday.io. If you want to see a similar video but with open source tools, [David Williams] did a talk at Superconference that gives the same kind of overview but with Yosys and other related tools.

Continue reading “An RF Engineer’s FPGA Learning Journey” →

Java On GPUs And FPGAs

March 11, 2020 by Al Williams 48 Comments

There was a time when running a program on an array of processors meant that you worked in some high-powered lab somewhere. Now your computer probably has plenty of processors hiding in its GPU and if you have an FPGA, you have everything you need to make something custom. The idea behind TornadoVM is to modify OpenJDK and GraalVM to support running some Java code on parallel architectures supported by OpenCL. The system can utilize multi-core CPUs, GPUs (NVIDIA and AMD), Intel integrated GPUs, and Intel FPGAs.

If you want to try your hand at accelerated Java, there are some docker containers to get you started fast. There’ are also quite a few examples, such as a computer vision application.

Continue reading “Java On GPUs And FPGAs” →

Fear Of Potato Chips: Samy Kamkar’s Side-Channel Attack Roundup

March 9, 2020 by Dan Maloney 13 Comments

What do potato chips and lost car keys have in common? On the surface, it would seem not much, unless you somehow managed to lose your keys in a bag of chips, which would be embarrassing enough that you’d likely never speak of it. But there is a surprising link between the two, and Samy Kamkar makes the association in his newly published 2019 Superconference talk, which he called “FPGA Glitching and Side-Channel Attacks.”

Continue reading “Fear Of Potato Chips: Samy Kamkar’s Side-Channel Attack Roundup” →

Mithro Runs Down Open Source FPGA Toolchains

March 6, 2020 by Elliot Williams 28 Comments

Tim [Mithro] Ansell has a lot to tell you about the current state of open FPGA tooling: 115 slides in 25 minutes if you’re counting. His SymbiFlow project aims to be the GCC of FPGA toolchains: cross-platform, multi-platform, completely free, and all-encompassing. That means that it’s an umbrella framework for all of the work that everyone else is doing, from work on synthesis and verification tools, to placing and routing, to vendor-specific chip libraries. His talk catches you up with the state of the art at the end of 2019, and it’s embedded below. Spoiler alert: SymbiFlow has the big Xilinx 7-series FPGAs in its crosshairs, and is closing in. SymbiFlow is that close to getting a networked Linux system on the FPGA fabric in a Xilinx 7 today, completely independent of any vendor tools.

But let’s step back a sec for a little background. When you code for an FPGA, words you type get turned into a bitstream of ones and zeroes that flip perhaps a few million switches inside the chip. Going from a higher-level language to a bitstream is a lot like compiling normal programming languages, except with the twist that the resulting computational logic doesn’t map straight into a machine language, but rather into lower-level physical hardware on the FPGA. So “compilation” for FPGAs involves two steps: synthesis and place-and-routing. Synthesis takes the higher-level language that you write and turns it into a set of networks and timing requirements that represent the same logic, and can work across chip families. Yosys is the open-source synthesis tool of choice here.