Slice Your Next FPGA Design

A recent trend has been to convert high-level constructs into FPGA code like Verilog or VHDL. Silice goes the other way: it converts very hardware-specific concepts to Verilog and aims to be a more expressive and easier to use language.

Why Silice? The project’s web page enumerates its design goals:

  • A clean, simple syntax that clearly exposes the flow of operations and where clock cycles are spent.
  • Precise rules regarding flow control (loops, calls) and their clock cycle consumption.
  • Familiar hardware constructs such as always blocks, instantiation, expression tracking (wires).
  • An optional flow-control oriented design style (automatic FSM generation), that naturally integrates within a design: while, break, subroutines.
  • The possibility to easily describe pipelines.
  • Automatically takes care of creating flip-flops for variables, with automatic pruning (e.g. const or bindings).
  • Generic interfaces and grouped IOs for easy reuse and modular designs.
  • Generic circuits that can be instantiated and reused easily.
  • Explicit clock domains and reset signals.
  • Familiar syntax with both C and Verilog inspired elements.
  • Inter-operates with Verilog, allowing to import and reuse existing modules.
  • Powerful LUA-based pre-processor.

Continue reading “Slice Your Next FPGA Design”

FIR Filters For Xilinx

Digital filters are always an interesting topic, and they are especially attractive with FPGAs. [Pabolo] has been working with them in a series of blog posts. The latest covers an 8th order FIR filter in Verilog.  He covers some math, which you can find in many places, but he also shows how an implementation maps to DSP slices in a device. Then to reduce the number of slices, he illustrates folding which trades delay time for slice usage.

Folding takes a multi-stage parallel multiplication and breaks it into fewer multiplications done over a longer period of time. This reuses slices to reduce the number required for high-order filters.

Continue reading “FIR Filters For Xilinx”

Using Docker To Sail Through Open-Source Xilinx FPGA Development

Until a few years ago, developing for FPGAs required the use of proprietary locked-down tools, but in the last few years, the closed-source dam has burst, and open-source FPGA tools such as Yosys, SimbiFlow, and Icestorm have come flooding out. Setting up a build environment for these exciting new tools can still be quite a challenge, but [Carlos Eduardo] has decided to make setting up an open-source toolchain for Xilinx FPGAs a breeze with Docker.

His image only has three prerequisites: Docker, Python 3, and OpenOCD (which is used to load your FPGA with your bespoke bitfile). After the Docker image has been built and all of the tools installed, [Carlos] guides you through using Python, FuseSoc, and SymbiFlow to build your first open-source Xilinx FPGA project.

In addition to making setup a whole lot easier, utilizing containers allows the same development environment to be built on Linux, Mac, and Windows (using WSL), which will make life a lot easier for teams working across different OSs.  [Carlos’s] Dockerfile is unique because it supports the popular Artix-7 series of FPGAs — for the Lattice FPGAs that have been supported for a lot longer, there are existing Docker files already up on DockerHub. It’s easier than installing the vendor’s toolchain!

If this has you thinking it might be time to dip your toes into open-source FPGA development, check out this rundown of open-source FPGA tools from the 2019 Superconference.

Arduino And FPGA Done Differently

FPGA guru [Max Maxfield] recently took a look at the XLR8 (pronounced accelerate) board from a company called Alorium. On the surface, it looks like another Arduino UNO clone. But instead of a CPU, it contains an Intel MAX10 FPGA that runs a softcore AVR processor. Of course, that’s only part of the story. If the board was just a mock Arduino using an FPGA, that’s not very interesting for practical purposes. However, by incorporating accelerator blocks or XBs, you can add FPGA modules to the soft CPU. [Max] shows an example that you can see in the video below where an FPGA block controls servos more easily than a standard Arduino. There’s also a version that looks like an Arduino Nano, but can clock much faster as well as use the XBs.

In addition to prebuilt XBs, there is a workflow to build your own if you are familiar with working with FPGAs. The products aren’t exactly new, but we enjoyed [Max’s] take on the product. We also appreciated the simple code examples showing exactly how you would convert a program to use the accelerated functions. Continue reading “Arduino And FPGA Done Differently”

Surf’s Up, A Styrofoam Ball Rides The Waves To Create A Volumetric Display

We are big fans of POV displays, particularly ones that move into 3D. To do so, they need to move even faster than their 2D cousins. [danfoisy] built a volumetric display that doesn’t move LEDs or any other digital display through space, or project light onto a moving surface. All that moves here is a bead of styrofoam and does so at up to 1 meter per second. Having low mass certainly helps when trying to hit the brakes, but we’re getting ahead of ourselves.

danfoisy vdatp 3d simulation

[danfoisy] and son built an acoustic levitator kit from [PhysicsGirl] which inspired the youngster’s science fair project on sound. See the video by [PhysicsGirl] for an explanation of levitation in a standing wave. [danfoisy] happened upon a paper in the Journal Nature about a volumetric display that expanded this one-dimensional standing wave into three dimensions. The paper described using a phased array of ultrasonic transducers, each with a 40 kHz waveform.

After reading the paper and determining how to recreate the experiment, [danfoisy] built a 2D simulation and then another in 3D to validate the approach. We are impressed with the level of physics and programming on display, and that the same code carried through to the build.

[danfoisy] didn’t stop with the simulations, designing and building control boards for each 100 x 100 10 x 10 grid of transducers. Each grid is driven by 2 Intel Cyclone FPGAs and all are fed 3D shapes by a Raspberry Pi Zero W. The volume of the display is 100 mm x 100 mm x 145mm and the positioning of the foam ball is accurate down to .01 mm though currently there is considerable distortion in the positioning.

Check out the video after the break to see the process of simulating, designing, and testing the display. There are a number of tips along the way, including how to test for the polarity of the transducers and the use of a Python script to place the grids of transducers and drivers in KiCad.

danfoisy vdatp schematic  danfoisy vdatp board layout

Continue reading “Surf’s Up, A Styrofoam Ball Rides The Waves To Create A Volumetric Display”

Ice40 Runs DOOM

Spec sheets are an important tool in determining the performance of a given part or system, but they’re not the be all and end all when it comes to engineering. However, specs alone don’t prove whether a given system can complete a given task. Sometimes, you need to actually do the work to prove it instead – as [Sylvain] has done, running DOOM on the iCE40 FPGA.

DOOM’s minimum specifications demand a 386 with 4MB RAM minimum, but it’s commonly agreed that a 486 DX2 running at 66MHz with 8MB of RAM is required to play the game smoothly. With an iCEBreaker v1.0b running a RISC V softcore at 25MHz, it may seem like a difficult task, but the RISC V core has the benefit that many instructions run in a single clock cycle that take many on the 486. While the iCEBreaker doesn’t have much RAM onboard, it’s a simple job to piggyback an 8MB SPI device on top of the existing flash storage. Control of the game is via keystrokes sent to the iCEBreaker over serial, while video is handled over a PMOD video interface with an HDMI connector.

[Sylvain] does a great job of explaining all the minute details of the work that was required to get things working, and has provided files on Github for those keen to replicate the feat or expand upon the code. Music is notably absent but MIDI output could likely be achieved without much hassle. “Does it run DOOM?” is still a question asked of many platforms, even the new Nintendo Game & Watch. Video after the break.

Continue reading “Ice40 Runs DOOM”

Hacking Hardware Bitcoin Wallets: Extracting The Cryptographic Seed From A Trezor

It’s long been common wisdom that one of the safest places to keep your cryptocurrency holdings is in a hardware wallet. These are small, portable devices that encrypt your keys and offer a bit more peace of mind than holding your coins in a soft or web wallet.

But of course, as we know, nothing is totally secure.

And we were reminded of this fact by Kraken Security Labs, when they showed us how they bypassed all of the safeguards in a popular wallet, the Trezor, to dump and decrypt it’s seed.

It’s worth noting that the hack does require physical access to the wallet — albeit only about fifteen minutes worth. And by “physical access” we mean that the hack leaves the device thoroughly mutilated. The Kraken team started by desoldering the heart of the wallet, a STM32 processor. They then dropped it into a socket on an interface board, and got to glitching.

The hack relies on an attack known as voltage glitching. Essentially, at a precisely-timed moment during the device’s boot sequence, the supply voltage is fluctuated. This enables the chip’s factory bootloader, which can read out the contents of it’s onboard flash memory. The memory is read-protected, but can be accessed 256 bytes at a time through a second voltage glitch. Neither of these attacks work 100% of the time, so if the device fails to boot or the memory remains locked, the FPGA performing the attacks simply tries again. After enough iterations, the Kraken team was able to fully dump the chip’s flash memory.

Continue reading “Hacking Hardware Bitcoin Wallets: Extracting The Cryptographic Seed From A Trezor”