Easily Build This IMU Array Sandbox

October 2, 2024 by Arya Voronova 28 Comments

These days we’re used to our devices containing an inertial measurement unit (IMU) that lets it know its position relative to the Earth. They’re mechanical devices at heart, and so they’re not infallible, with a few well-known failure modes — but we can try and help it. One way that’s getting some attention is to put many MEMS IMUs on a single PCB, connect it to an FPGA, then process their data all together to make for a more sensitive IMU or filter out drift. Want to join in? Here’s an open source implementation from [will127534].

With 32 individual ICM-42688-P SPI-connected IMUs and the beloved ICE40 chip at the center of the board, this PCB is a powerful platform to help you jump onto the new direction of the IMU research world. There’s example Verilog code that tests the board’s workings, and you can pair it with a Pi Pico running MicroPython to test out its raw capabilities. After that, the stage is yours.

The board is cheap to order online, easy to assemble yourself if you must, or have JLCPCB assemble it — just solder some capacitors on the backside afterwards. There’s a breakout, but it’s mostly for tests. This board is very much designed to be a module in a bigger system, [will] mentions that he’s building a geophone. Clever array-based hacks are en vogue, it would feel – here’s a LED array from [mitxela] that uses LEDs as sensors.

Comparing X86 And 68000 In An FPGA

June 7, 2024 by Dave Rowntree 15 Comments

[Michael Kohn] started programming on the Motorola 68000 architecture and then, for work reasons, moved over to the Intel x86 and was not exactly pleased by the latter chip’s perceived shortcomings. In the ’80s, the 68000 was a very popular chip, powering everything from personal computers to arcade machines, and looking at its architecture and ease of programming, you can see why this was.

Fast-forward a few years, and [Michael] decided to implement both cores in an FPGA to compare real applications, you know, for science. As an extra bonus, he also compares the performance of a minimal RISC-V implementation on the same hardware, taken from an earlier RISC-V project (which you should also check out !)

Utilizing their ‘Java Grinder’ application (also pretty awesome, especially the retro console support), a simple Mandelbrot fractal generator was used as a non-trivial workload to produce binaries for each architecture, and the result was timed. Unsurprisingly, for CISC architectures, the 68000 and x86 code sizes were practically identical and significantly smaller than the equivalent RISC-V. Still, looking at the execution times, the 68000 beat the x86 hands down, with the newer RISC-V speeding along to take pole position. [Michael] admits that these implementations are minimal, with no pipelining, so they could be sped up a little.

Also, it’s not a totally fair race. As you’ll note from the RISC-V implementation, there was a custom RISC-V instruction implemented to perform the Mandelbrot generator’s iterator. This computes the complex operation Z = Z² + C, which, as fellow fractal nerds will know, is where a Mandelbrot generator spends nearly all the compute time. We suspect that’s the real reason RISC-V came out on top.

If actual hardware is more your cup of tea, you could build a minimal 68k system pretty easily, provided you can find the chips. The current ubiquitous x86 architecture, as odd as it started out, is here to stay for the foreseeable future, so you’d just better get comfortable with it!

Continue reading “Comparing X86 And 68000 In An FPGA” →

ICEBlaster: A Drag’n’Drop Bitstream Loader For ICE40

July 11, 2022 by Dave Rowntree 10 Comments

The iCE40 series of FPGAs gets a fair bit of coverage on these pages, largely due to its accessibility (thanks to huge efforts in reverse engineering and open tool chains) and likely also due to Lattice Semiconductors’ attitude to open source in general. Whilst these devices are small and rather limited, you can’t really beat them for a first foray into the subject. They’re plenty beefy enough for many of the simpler FPGA applications. [TinLethax] over on Hackaday.IO has plenty of experience with the devices, and has added another tool to our collective iCE40 arsenal, namely iCEBlaster, a USB mass storage device (MSC) style bootloader for drag-n-drop bitstream loading. The days of needing dedicated special programmers are starting to be numbered, with many chips now presenting a USB mass storage device to the host in order to upload the firmware image.

FPGAs don’t tend to operate this way, needing a device-specific bitstream loading upon start-up, which (unless they have OTP memory) is usually the job of an external configuration memory. iCEBlaster (a play on the Xilinx ByteBlaster programmer, maybe?) runs on the STM32F4xx series devices at least, but should be easily portable to others. The idea is pretty straightforward — dragging a new bitstream file onto the storage device initiates an FPGA target reset, which in turn allows the STM32 to send the bitstream over to the iCE40 via the SPI interface. Nothing more than that.

If you’ve been looking to get into the iCE40, this guide might be a good starting point, and every learning experience needs a good project to drive it, how about running Doom on a softcore RISC-V?

FPGA Starter Videos To Help Soften That Learning Curve

February 17, 2022 by Dave Rowntree 8 Comments

Digi-Key have been producing YouTube videos for a number of years now, and if you weren’t aware, they’re definitely worthy of some viewing time. The playlist we’re highlighting here is a pretty good introduction to FPGAs, specifically those supported by open source tools, with low cost hardware. If you’ve always wanted to get into hacking FPGA platforms, but don’t know where to start, this is going to be a big help. After first covering what an FPGA is and is not, and why you want to use one, [Shawn Hymel] dives in to the toolchain.

We’re really lucky that the bitstream for the Lattice iCE40 was reverse engineered by the super talented Claire (née Clifford) Wolf (AMP hour interview) which enabled the project ICEstorm toolchain to be created. Leveraging Yosys for synthesis and logic mapping, Icarus verilog coupled with GTKwave for simulation, netpnr for place and route and finally the project ICEstorm bitstream tools for packing into iCE40 format and loading onto the hardware. The whole toolchain flow is managed by APIO for simplicity, that is, provided your FPGA board is supported!

Of course, [Shawn] is using the low cost (for an FPGA) ICEStick by Lattice for this tutorial series, and they’re currently hard to get (you know why by now!) but, there are many other boards you could use. If you want to play with applications coupling a ARM micro to an FPGA, then the excellent BlackIce Mx is an option, but there are many other boards now with an decent micro nestled next to an FPGA and a few peripherals for convenience.

We should mention here, that project ICEstorm and the iCE40 is not the only show in town. Project Trellis has had our eye for a while, which targets the more complex Lattice ECP5 device. Yosys and friends do support more architectures, but the available flows usually require at least some vendor tool support at this time (looking straight at you, Xilinx) but as more devices get decoded, the open source tools will grow, and we will bring you that news!

What’s nice about this Digi-Key YT series, is that it doesn’t just cover the basic toolchain flow, then drop you in at the deep end of a big learning curve. There are videos covering subjects such as finite state machines (FSMs), test-benching and simulation, using embedded (block) memories, PLLs, harder subjects like dealing with metastability and clock-domain crossing (OK, he covers one technique – there’s more than one way to skin that particular cat) before finally looking at soft cores like the RISC-V. Lots to learn, and pretty well executed if you ask us! A Github version is available, for those who can’t stand watching the videos!

Continue reading “FPGA Starter Videos To Help Soften That Learning Curve” →

Ice40 Runs DOOM

February 7, 2021 by Lewin Day 22 Comments

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” →

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.

Continue reading “Mithro Runs Down Open Source FPGA Toolchains” →

Symbiflow Open Source FPGA Toolchain

November 1, 2019 by Gerrit Coetzee 12 Comments

Anyone who’s ever had the pleasure of programming FPGAs knows that it’s a land of proprietary tools that almost require marriage level commitment to a specific platform to be effective. Symbiflow hopes to solve this by becoming the GCC of FPGAs.

Rather than a tool built around a specific chip or architecture, Symbiflow will provide a more universal interface. Users can program in Verilog; architecture definitions define how the code will be compiled for the right chip. They are currently targeting the popular Xilinx 7-series, the very affordable iCE40 series from lattice, and the ECP5 FPGAs also from Lattice.

If you’re headed to Hackaday Supercon this year, [Timothy Ansell] will be giving a talk on how Symbiflow is making this process much more approachable and much less proprietary. Overall we’re very excited about a common interface, especially as the price of FPGAs keep dropping into micro controller territory while also increasing in capability.

(Speaking of Supercon, and maybe this is a spoiler, the badge would not have been possible without Symbiflow, Project Trellis, Yosys, and NextPNR.)