fpga

557 Articles

Yo Dawg, I Heard You Like FPGAs

June 28, 2019 by 12 Comments

When the only tool you have is a hammer, all problems look like nails. And if your goal is to emulate the behavior of an FPGA but your only tools are FPGAs, then your nail-and-hammer issue starts getting a little bit interesting. That’s at least what a group of students at Cornell recently found when learning about the Xilinx FPGA used by a researcher in the 1990s by programming its functionality into another FPGA.

Using outdated hardware to recreate a technical paper from decades ago might be possible, but an easier solution was simply to emulate the Xilinx in a more modern FPGA, the Cyclone V FPGA from Terasic. This allows much easier manipulation of I/O as well as reducing the hassle required to reprogram the device. Once all of that was set up, it was much simpler to perform the desired task originally set up in that 90s paper: using evolutionary algorithms to discriminate between different inputs.

While we will leave the investigation into the algorithms and the I/O used in this project as an academic exercise for the reader, this does serve as a good reminder that we don’t always have to have the exact hardware on hand to get the job done. Old computers can be duplicated on less expensive, more modern equipment, and of course video games from days of yore are a snap to play on other hardware now too.

Thanks to [Bruce Land] for the tip!

FPGA Soft CPU Is Superscalar

June 22, 2019 by 34 Comments

We will admit it: mostly when we see a homebrew CPU design on an FPGA, it is a simple design that wouldn’t raise any eyebrows in the 1970s or 1980s. Not so with [Henry Wong’s] design, though. His x86-like design does superscalar out-of-order execution, just like big commercial modern CPUs. Of course [Henry] designs CPU architectures for Intel, so that’s not surprising. You can see a very detailed talk on the design in the video, below. You can also read the entire thesis project.

[Henry] starts out with a description of FPGAs and soft processors. He also covers the use of multiple instruction issue to increase the virtual clock rate of a CPU. In other words, if a 100 MHz CPU can do one instruction at a time, it won’t be any faster — in theory — than a 50 MHz CPU that can do two instructions at once. Of course, trying to do two at once has some overhead, so that won’t be completely true.

Continue reading “FPGA Soft CPU Is Superscalar” →

A Modular Logic Analyzer For FPGAs

May 26, 2019 by 4 Comments

When working on a project, it’s incredibly helpful to be able to visualize the various signals in play. This is important when attempting to determine if what is supposed to be happening is actually happening. However, logic analyzers can be expensive, so a group from [Bruce Land]’s ECE5760 class developed their own hardware solution instead.

The primary idea behind the project is modularity. The basic building blocks of the logic analyser are coded in Verilog. They’re designed so that the number of channels and added functions can be mixed and match to suit the given purpose and the capabilities of the target FPGA platform. The team’s logic analyzer is also capable of decoding SPI and I2C in hardware, and has a graphical user interface running on an attached laptop for visualizing signals.

It’s a tidy build, and an excellent project to learn the fundamentals of both FPGA programming and the various communications protocols involved. [Bruce Land]’s classes are a hotbed of FPGA projects, from pokerbots to NES chiptune emulators. Video after the break.

Continue reading “A Modular Logic Analyzer For FPGAs” →

A Stylish Pair Of FPGA Earrings

May 24, 2019 by 7 Comments

Sometimes, rather than going the commercialistic route, it can be nice to make a gift for that personal touch. [Mahesh Venkitachalam] had been down this very road before, often stumbling over that common hurdle of getting in too deep and missing the deadline of the occasion entirely. Not eager to repeat the mistake, help was enlisted early, and the iCE bling earrings were born.

The earrings were a gift for [Mahesh]’s wife, and were made in collaboration with friends who helped out with the design. The earrings use a Lattice iCE40UP5k FPGA to control an 8×8 grid of SMD LEDs. This is all achieved without the use of shift registers, with the LEDs all being driven directly from GPIO pins. This led to several challenges, such as routing all the connections and delivering enough current to the LEDs. The final PCB is a 4-layer design, which made it much easier to get all the lines routed effectively. A buffer is used to avoid damaging the FPGA by running too many LEDs at once.

It’s a tidy build, which makes smart choices about component placement and PCB design to produce an attractive end result. LEDs naturally lend themselves to jewelry applications, and we’ve seen some great designs over the years. Video after the break.

Continue reading “A Stylish Pair Of FPGA Earrings” →

PokerBot Uses FPGA For Card Calculating Horsepower

May 16, 2019 by 12 Comments

Played against humans, Poker is a game as much about reading your opponent as it is about the cards you’re dealt. That doesn’t mean there aren’t certain mathematical ways to aid your decision making based on probabilities. In this vein, a group of students from Cornell’s ECE 5760 class built a pokerbot on an FPGA.

The bot uses the principle of Monte Carlo simulation to calculate the probabilities of an individual winning a hand of Limit Texas Hold’em. Calculating the entire set of possible hands is impractical, so in a Monte Carlo simulation a sample is calculated instead. By accelerating these calculations on an FPGA, the pokerbot is able to calculate 300,000 possible hands in just 150 ms, and present a probability of winning to the human player. This same calculation method is then used to make decisions for the computer players in the game, too.

The team report that the FPGA’s processing power brought a 10x speed up compared to their C++ program running on an Intel i7-6700HQ. The strong statistical calculations help to make the computer players engaging and realistic to play against.

It’s another great example of a project from Bruce Land’s classes, which are somewhat of a hotbed of development each year. Video after the break.

Continue reading “PokerBot Uses FPGA For Card Calculating Horsepower” →

What’s More Accurate Than A GPS Clock? The OpenPPS GPS Clock

May 11, 2019 by 19 Comments

Making a GPS clock is a relatively straightforward process on the face of it. Buy a GPS module for a few dollars, hook it up to a microcontroller board of your choice, pick the appropriate library and write a bit of code, et voila! A clock with time-wonk bragging rights!

Of course, your GPS clock will always tell the right time, but it won’t be really right. Your microcontroller will introduce all sorts of timing errors and jitter, so at best it’ll only be nearly right. [Rick MacDonald] has been striving to quantify and minimise these errors in his OpenPPS project, which aims to be as accurate a GPS time and frequency reference as possible.

In a very comprehensive multi-page write-up, he details his progression, through the GPS modules he used, his experience with timing jitter when he used an ESP32 alone to process their output, and then his experiments with an FPGA and then temperature-compensated oscillators. It moves from being a mere description of a GPS clock into a fascinating run-down of both GPS timing itself and the development pitfalls he encountered along the way. At the end of it all he has a GPS clock in a smart 3D-printed enclosure which he admits as yet doesn’t do anything more than tell the time, but as he points out it’s a clock with minimised jitter, delay, and drift, and it remains an ongoing project that will evolve into a full-blown time and frequency standard.

If your taste in GPS clocks is far more simple, there are plenty of projects showing how a more basic one can be produced.

Circuit-Level Game Boy: Upping Emulation Ante By Simulating Every Cycle

April 23, 2019 by 12 Comments

Usually when writing emulation software for a system like the Game Boy, one makes sure to take as many shortcuts as possible in order to reduce the resources required for the emulation. This has however the unfortunate side-effect that it reduces the overall accuracy of the emulation and with it the compatibility with games on the system.

This is the basic reasoning behind projects which seek to abandon simplistic abstractions in favor of cycle-accurate, full compatibility approaches, of which MetroBoy is probably the most extreme one. Instead of abstracting away the hardware, it instead does the emulation at the circuit level. As with such other projects, this means that the emulator requires a lot more CPU cycles to get things just right. On the bright side, one can likely still run this emulator on any modern system.

As the MetroBoy author explains, he implemented code in C++ which allowed him to construct circuits in an HDL-style manner, which should theoretically also allow him to generate a Verilog (or VHDL) softcore out of the project. As a demonstration of implementing HDL in C++ it’s decidedly interesting.

An approach like this is pretty much the exact opposite of a project like the UltraHLE (ultra high-level emulator) Nintendo 64 emulator, which used the knowledge that Nintendo 64 games are written in C as a first step to creating libraries that the code in the Nintendo 64 ROMs would call instead of the native (Nintendo) libraries. This allowed N64 games to directly run on the target system, with the graphic and system calls translated by UltraHLE into native OS calls, using the 3dfx Glide API for accelerated graphics.

While an approach like UltraHLE took allows for the most minimal use of system resources by essentially foregoing emulation completely, for retro systems like the Game Boy where games were implemented in assembly on bare hardware, using this circuit-level emulation ensures that one gets the most accurate match with the original handheld console experience.

As a word of caution to those who are now itching to try out MetroBoy, its Github site notes that it currently lacks support for game saves, uses a mixture of original Game Boy (DMG) and Game Boy Advance SP (AGS) hardware that confuses some games and has rather buggy sound support.

If playing around with software-defined Game Boy circuits isn’t enough and would like to literally look inside a real Game Boy, the X-ray image from the top of the article is something Chris over at Elektronaut pulled off several years ago.