FPGA

373 Articles

The DOOM Chip

May 13, 2020 by 18 Comments

It’s a trope among thriller writers; the three-word apocalyptic title. An innocuous item with the power to release unimaginable disaster, which of course our plucky hero must secure to save the day. Happily [Sylvain Lefebvre]’s DOOM chip will not cause the world to end, but it does present a vision of a very 1990s apocalypse. It’s a hardware-only implementation of the first level from id Software’s iconic 1993 first-person-shooter, DOOM. As he puts it: “Algorithm is burned into wires, LUTs and flip-flops on an #FPGA: no CPU, no opcodes, no instruction counter. Running on Altera CycloneV + SDRAM”. It’s the game, or at least the E1M1 map from it sans monsters, solely in silicon. In a very on-theme touch, the rendering engine has 666 lines of code, and the level data is transcribed from the original into hardware tables by a LUA script. It doesn’t appear to be in his GitHub account so far, but we live in hope that one day he’ll put it up.

“Will it run DOOM” is almost a standard for new hardware, but it conceals the immense legacy of this game. It wasn’t the first to adopt a 1st-person 3D gaming environment, but it was the game that defined the genre of realistic and immersive FPS releases that continue to this day. We first played DOOM on a creaking 386, we’ve seen it on all kinds of hardware since, and like very few other games of its age it’s still receiving active development from a large community today. We still mourn slightly that it’s taken the best part of three decades for someone to do a decent Amiga port.

Using An FPGA To Glitch The Olimex LPC-P1343

April 30, 2020 by 2 Comments

After trying out hardware hacking using an FPGA to interface with target hardware, [Grazfather] was inspired to try using the iCEBreaker (one of the many hobbyist FPGAs to have recently flooded the market) to build a UART-controllable glitcher for the Olimex LPC-P1343.

FPGA Modules (The cmd module intercepts what the host computer sends over UART, the resetter holds the reset line until the target is reset, the delay starts counting on reset and waits for a configured number of cycles before sending its signal, the trigger waits for the delay to finish before telling the pulse module to send a pulse, and the pulse works similar to the delay module and outputs to the power multiplexer.)

When the target board boots up, the bootROM reads the flash and determines whether the UART goes to a shell and if the shell can be used to read out the flash. This is meant for developing firmware and debugging it in the bootloader, only flashing a version when the firmware is production-ready. The vulnerability is that only a specific value read from address 0x2FC and the state of a few pins can lock the bootloader in the expected way, and any other value at the address causes the bootROM to consider the device unlocked. Essentially, the mechanism is the opposite of how a lock ought to work.

The goal is to get the CPU to misread the flash at the precise moment it is meant to be reading the specific value, then jumping to the bootloader in the unlocked state. The FPGA can be used as a tool between the host machine and target board, communicating via UART. The FGPA can support configuring the delay between resetting the target board and pulsing a ‘glitch voltage’, as well as resetting the target board and activating the glitch. The primary reasons for using the FPGA over a different microcontroller are that the FPGA allows for precise timing (83.3ns precision) and removes worries about jitters (a Raspberry Pi might have side effects from OS scheduling and other processes and microcontrollers might have interrupts messing up the timing).

The logic analyzer view

To simulate the various modules, [Grazfather] used Icarus Verilog as well as GTKWave to observe the waveforms generated. A separate logic analyzer observes the effects on real hardware.

With enough time, it is possible to brute force any combination of delay and width until you get a dump of the flash you’re not meant to read. You can check out how the width of the pulse gets wider until the max, when the delay is incremented and the width values are tried again.

Continue reading “Using An FPGA To Glitch The Olimex LPC-P1343” →

NEO430 Puts A Custom MSP430 Core In Your FPGA

April 27, 2020 by 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 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 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 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 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” →