Throwing Down The FPGA Gauntlet

Gauntlet is a well-known arcade game from 1985 with many sequels and ports to more modern architectures such as Xbox and GameCube. Thanks to its popularity and relative age, the original arcade cabinet is well documented with the schematics available online. It was regarded as the most complex and ambitious hardware Atari had ever developed at the time it was released. In what can only be described as an absolute labor of love, [Alex] has recreated the arcade hardware on the Pipistrello FPGA board.

The project can actually play Gauntlet, Gauntlet II, and Vindicators II as they all ran on the same hardware. Four joysticks are supported so up to four players can play, though the EEPROM is emulated in RAM so high scores are reset when the device is powered down. The FPGA is almost out of space and can’t quite squeeze in the SRAM needed. So an SRAM expansion daughterboard is required; nothing a quick board run from our favorite purple PCB manufacturer can’t solve.

In the repo is an incredible write-up detailing the system, how it works, and the process of debugging it. This project also includes a complete simulation of the TMS5220 Voice Synthesis Processor, as Gauntlet was the first coin-operated arcade machine with a voice synthesizer. Getting the video correct was particularly tricky and it took several tries to get the color palette and motion looking right. Since [Alex] didn’t have access to an original Gauntlet arcade cabinet, they had to make do with MAME. After writing a test to make sure the FPGA was working correctly, there were differences between the MAME emulation and the FPGA output. To help out, [Colin Davies] came to the rescue. After [Colin] hooked up an original Gauntlet Arcade PCB with the motion test loaded up, the test showed that the FPGA had the correct behavior.

During development [Alex] actually simulated several frames of the game in ISIM (at a whopping 90 seconds per frame or 90 minutes per in-game second). Using ISIM allowed them to compare system state to MAME and validate the design much faster as they could better inspect the interworkings of the different modules. Using a clever trick of grabbing state from MAME after a few seconds, they primed the FPGA state and saved themselves a few hours of simulation.

If you’re looking to get into old hardware style arcade game development, give the browser-based 8bitworkshop IDE a spin. Or start with something a little smaller in scope and size with this adorable mini CRT arcade cabinet.

Continue reading “Throwing Down The FPGA Gauntlet”

Bunnie’s Betrusted Makes First Appearance As Mobile, FPGA-Based SoC Development Kit

Recently, [Bunnie Huang] announced his Precursor project: a spiffy-looking case housing a PCB with two FPGAs, a display, battery and integrated keyboard. For those who have seen [bunnie]’s talk at 36C3 last year, the photos may look very familiar, as it is essentially the same hardware as the ‘Betrusted’ project is intended to use. This also explains the name, with this development kit being a ‘precursor’ to the Betrusted product.

In short, it’s a maximally open, verifiable, and trustworthy device. Even the processor is instantiated on an FPGA so you know what’s going on inside the silicon.

He has set up a Crowd Supply page for the Precursor project, which provides more details. The board features a Xilinx Spartan 7 (XC7S50) and Lattice iCE40UP5K FPGA, 16 MB SRAM, 128 MB Flash, integrated WiFi (Silicon Labs WF200-based), a physical keyboard and 1100 mAh Lio-Ion battery. The display is a 200 ppi monochrome 336 x 536 px unit, with both the display and keyboard backlit.

At this point [bunnie] is still looking at how much interest there will be for Precursor if a campaign goes live. Regardless of whether one has any interest in the anti-tamper and security features, depending on the price it might be a nice, integrated platform to tinker with.

An FPGA Video Player Built Just For Fun

Sometimes, projects are borne out of neccessity; a fix for a problem that needs to be solved. Other times, they’re done just for the love of creation and experimentation. [ultraembedded]’s FPGAmp media player falls under the latter, and served as a great learning experience along the way.

The aim of FPGAmp is to play back a variety of media files on the Arty A7 development board, based around the Xilinx Artix-7 FPGA. Capable of playing back MJPEG video at 800 x 600 resolution and 25 fps, it’s also able to play back MP3s as well for stereo audio. Demonstrating the device on Twitter, [ultraembedded] notes that the method of using an LED to do SPDIF optical audio output isn’t legit, but does work. A later update switches to using a dedicated audio output board with the Arty A7 platform, featuring an excellent song from The Cardigans.

Using a RISC V processor core and a hardware JPEG decoder, we imagine [ultraembedded] really sharpened their FPGA skills with this project. Particularly in the wake of the sale of ARM to NVIDIA, RISC V continues to gain relevance in the hardware community. We were lucky enough to feature a keynote at last year’s Supercon, with Megan Wachs speaking on the technology. Video after the break.

Continue reading “An FPGA Video Player Built Just For Fun”

What’s Inside An FPGA? Ken Shirriff Has (Again) The Answer

FPGAs are somewhat the IPv6 of integrated circuits — they’ve been around longer than you might think, they let you do awesome things that people are intrigued by initially, but they’ve never really broke out of their niches until rather recently. There’s still a bit of a myth and mystery surrounding them, and as with any technology that has grown vastly in complexity over the years, it’s sometimes best to go back to its very beginning in order to understand it. Well, who’d be better at taking an extra close look at a chip than [Ken Shirriff], so in his latest endeavor, he reverse engineered the very first FPGA known to the world: the Xilinx XC2064.

If you ever wished for a breadboard-friendly FPGA, the XC2064 can scratch that itch, although with its modest 64 configurable logic blocks, there isn’t all that much else it can do — certainly not compared to even the smallest and cheapest of its modern successors. And that’s the beauty of this chip as a reverse engineering target, there’s nothing else than the core essence of an FPGA. After introducing the general concepts of FPGAs, [Ken] (who isn’t known to be too shy to decap a chip in order to look inside) continued in known manner with die pictures in order to map the internal components’ schematics to the actual silicon and to make sense of it all. His ultimate goal: to fully understand and dissect the XC2064’s bitstream.

Of course, reverse engineering FPGA bitstreams isn’t new, and with little doubt, building a toolchain based on its results helped to put Lattice on the map in the maker community (which they didn’t seem to value at first, but still soon enough). We probably won’t see the same happening for Xilinx, but who knows what [Ken]’s up to next, and what others will make of this.

Write In PipelineC For FPGAs

The best thing about field-programmable gate arrays (FPGAs), when you have a massively parallel application, is that everything runs in parallel. The worst thing about FPGAs, when you need a lot of stuff to happen in sequence, is that everything runs in parallel. If you have a multi-step computation, for example, you need to break it up into chunks, figure out the timing between them, and make sure that each chunk clears before it is fed new data. This is pipelining, and taking care of all the low-level details yourself is one of the things that can sometimes make FPGA a four-letter word beginning with “F”.

[Julian Kemmerer]’s PipelineC is a C-like language that compiles down into VHDL so that you can use it in an FPGA, and it does the pipelining for you. He has examples of how you’d use it to construct a simple state machine, and after you’ve written a few hundred state machines the long way, you’ll know why this is a good idea.

PipelineC isn’t the only high level synthesis language out there, but it sits in an interesting place. It doesn’t take care of memory or define interfaces. It just takes care of pipelining. We haven’t tried it out yet, but it looks like it would be interesting for moderately complex projects, where the mechanics of pipeline signalling is a hassle, but you don’t require the deluxe treatment. Check it out, and if you like it, let us (and [Julian], natch) know.

If you want to dive head-first into pipelining, give [Al Williams]’ two-part mini-series a look.

Pipeline graphic CC BY-SA 3.0 by CBurnett

Glasgow Uses An FPGA As An Embedded Systems Multitool

Everyone who builds embedded systems wants tools to help build and debug systems faster, so it isn’t uncommon to see boards outfitted with various tools like serial port sniffers. We’ve seen a few incarnations and the latest is Glasgow. The small board uses an FPGA and claims to do the following:

  • UART with automatic baud rate determination
  • SPI or I2C
  • Read and write common EEPROMs and flash chips
  • Read and write common EPROMs including a data rescue function
  • Program AVR chips via SPI
  • Play back JTAG SVF files
  • Debug ARC and some MIPS CPUs
  • Program XC9500LX CPLDs
  • Communicate to several wireless radios and CPUs
  • Do sound synthesis
  • Read raw data from floppy drives

The revC board is the first to be relatively functional and sports 16 I/O pins operating at up to 100 MHz, although the documentation hints that 6 MHz might be the top of what’s easily accomplished. The software is written in Python and the iCE40 FPGA toolchain that we’ve talked about many times in the past.

This already looks like a useful tool and the reconfigurable nature of FPGAs makes it a good platform to expand. The documentation discusses the difficulty in debugging things for the board, so the base software offers support such as a built-in logic analyzer to help.

We have seen dev boards become bench tools, like using the iCEstick as a logic analyzer. It’s nice to see dedicated tools like this one built up around the speed and versatility of FPGAs.

Continue reading “Glasgow Uses An FPGA As An Embedded Systems Multitool”

SoftCore CPU Comparison

Monty Python once did a sketch where people tried to summarize Proust in fifteen seconds. Although summarizing eight FPGA-based CPUs is almost as daunting, [jaeblog] does a nice job of giving a quick sketch of how the CPUs work with the Xilinx Vivado toolchain and the Digilent Arty board.

The eight CPUs are:   VexRiscv, LEON3, PicoRV32, Neo430, ZPU, Microwatt, S1 Core, and Swerv EH1.

The comparison criteria were very practical: A C compiler (gcc or llvm) for each CPU and no CPUs that were tied to a particular FPGA. Two of the CPUs didn’t fit on the Arty board, so their comparisons are a bit more theoretical.  There were other considerations such as speed, documentation, debugging support, and others.

It was interesting to see the various CPUs ranging from some very mature processors to some new kids on the block, and while the evaluations were somewhat subjective, they seemed fair and representative of the things you’d look for yourself. You can also get the test code if you want to try things for yourself.

The winner? The post identifies three CPUs that were probably the top choices, although none were just perfect. Of course, your experience may vary.

If you want an easy introduction to adding things to a soft CPU, this RISC-V project is approachable. Or if you prefer SPARC, check out this project.