FPGA

364 Articles

Do We Need A New Hardware Description Language?

March 15, 2024 by 20 Comments

When you think about hardware description languages, you probably think of Verilog or VHDL. There are others, of course, but those are the two elephants in the room. Do we need another one? [Veryl-lang] thinks so. The Veryl language is sort of Verilog meets Rust. What makes Veryl interesting is that it transpiles to normal SystemVerilog, so it will — probably — work with your existing tool chains.

That means you can define your logic Veryl, have it output SystemVerilog, and then use that Verilog in your vendor’s (or an open source) Verilog tool. The output is supposed to be human-readable Verilog, too, so you don’t have to transport opaque blocks of gibberish.

Continue reading “Do We Need A New Hardware Description Language?” →

Bit-Serial CPU: Ultra-Tiny VHDL-Based CPU With Forth Interpreter

February 24, 2024 by 11 Comments

Soft cores for FPGAs come in many different flavors, covering a wide range of applications. The Bit-Serial CPU (bcpu) soft core presented by [Richard James Howe] is interesting for taking up just about the most minimal amount of resources (23 slices, 76 LUTs) while providing the means to run a Forth-based (eForth dialect) interpreter. To this CPU core a UART can be added (92 LUTs), as well as other peripherals.

As [Richard] states, the entire core with UART fits in 73 slices (220 LUTs) on a Spartan 6, while requiring a single port BRAM (block RAM). It features a 16-bit accumulator and lacks features such as interrupts, byte addressability and function calls, but those are not required to run the eForth interpreter. The main purpose of this soft core (other than the challenge) is to have a UART-programmable core that can be slotted in any FPGA design. For more serious requirements [Richard] also has the H2 SoC, which can run full-fat FORTH.

Continue reading “Bit-Serial CPU: Ultra-Tiny VHDL-Based CPU With Forth Interpreter” →

Compute The Mandelbrot Set With A Custom RISC-V CPU

January 17, 2024 by 9 Comments

When faced with an FPGA, some people might use it to visualize the Mandelbrot set. Others might use it to make CPUs. But what happens if you combine the two? [Michael Kohn] shows us what happens with his RISC-V CPU with an instruction specially made for computing the Mandelbrot set.

[Michael] takes us through the unusual process of turning his 8008 into a RISC-V CPU. Re-using bits of logic here and replacing other logic there leaves him with a functional RISC-V core. Not finished, [Michael] takes it upon himself to also create a custom instruction just for computing a point for the Mandelbrot set, accelerating the demo from twenty-three seconds to merely one!

Still not finished, [Michael] also creates an implementation of the long gone F100-L CPU, once again with added Mandelbrot set flair, simultaneously with the RISC-V project. Finally, he ports his “Java Grinder” Java bytecode compiler to both RISC-V and the F100-L, because Java runs on 1 Billion devicesTM.

Continue reading “Compute The Mandelbrot Set With A Custom RISC-V CPU” →

Will We Recycle FPGAs In The Future?

December 22, 2023 by 21 Comments

If you really want to look at how much something costs, you need to look at total cost of ownership, not just the sticker price. Same goes for things like pollution and carbon footprint. A vehicle, for example, might have a low carbon footprint in operation but require more carbon in the manufacturing or disposal processes. Researchers have noted that FPGA accelerators get replaced and may wind up as e-waste in as little as two years. They propose REFRESH, an architecture that recycles old FPGAs into new ones by joining multiple FPGA dice with a simple interposer to coordinate the work.

The idea is not as radical as it might first seem. Many modern chips use chiplets anyway, so this is a reasonable extension of that idea. You simply need a way to harvest the old devices.

Continue reading “Will We Recycle FPGAs In The Future?” →

Nyan Keys: Because Your Keyboard Is Painfully Slow

December 10, 2023 by 32 Comments

You probably don’t notice keyboard latency when typing or doing mundane tasks, but if you start gaming, that’s also when you might start complaining. Every millisecond counts in that arena. Think your keyboard is fast? Think again. Because unfortunately, no matter what you’ve got in there, that key matrix is slowing you down. What you need is an FPGA-based keyboard with an overkill MCU. You need Nyan Keys.

[Portland.HODL] set out to make the lowest-latency mechanical keyboard possible that would accept any Cherry-compatible switches, and boy howdy, is this thing fast.

Coupled with the STM32F723VET6 MCU is USB 2.0 HS, which has an 8000Hz polling rate. At worst, key latency measures 30μS, which blows the 1mS average out of the water.

Because it uses a Lattice Semi iCE40HX 4k FPGA, each key switch can connect to its own I/O pin, which also eliminates the need for diodes.

It also means that each key switch can have its own “core” — an 8-bit timer that is always counting up to 255. The key can only change its state when the timer reads 255. This acts as a rather clever debounce mechanism.

If all that’s not enough, [Portland.HODL] built an operating system called NyanOS written in C to avoid any performance-reducing overhead. Oh, and it has an opt-in Bitcoin miner.

We’ve seen a lot of keyboards, the fast ones are fast because of the input side — they are chording keyboards that take combinations to type, rather than using one key (or so) per character. The Characorder is so fast that it was banned from competition.

Die of an Altera EPM7032 EEPROM-based Complex Programmable Logic Device (CPLD). (Credit: ZeptoBars, Wikipedia)

Using EPROMS And EEPROMs As Programmable Logic With Lisp

October 28, 2023 by 9 Comments

That EPROMs, EEPROMs and kin can be used as programmable logic should probably not come as a major surprise, but [Jimmy] has created a Lisp-based project that makes using these chips as a logic array very straightforward. All it takes is importing the package into one’s Lisp project and defining the logic, before the truth function generates the binary file that can be written to the target chip.

Suggested is the one-time-programmable AT27C512R EPROM (64k x8), but any 8-bit parallel interface (E)EPROM should work, with non-OTP chips being nice unless the chip has to go into a production device. A possible future improvement is the addition of 16-bit (E)EPROM support.

The use of EEPROMs is common with PLA-replacements, as with, for example, the Commodore 64, where the official PLA IC tends to go bad over time. Due to the complexity of the logic in these PLA ICs, here CPLDs are used, which internally are still EEPROM-based, but feature many more programmable elements to allow for more complex logic. If all you need is a bit of glue logic and you are looking for something in between a stack of 74-logic ICs and a CPLD, an EEPROM may be just be the solution, regardless of whether you prefer to create the binary image with Lisp or C.

Continue reading “Using EPROMS And EEPROMs As Programmable Logic With Lisp” →

FPGA Runs IBM 5151 MDA Display

September 13, 2023 by 11 Comments

When it comes to driving a display, you can do all kinds of fancy tricks with microcontrollers to get an image up. Really, though, FPGAs are the weapon of choice for playing with these kinds of signals. [Ted Fried] put one to great work driving an ancient IBM 5151 MDA display, and shared his results on Hackaday.io.

The build relies on a Digilent Arty Z7-20 SOC FPGA development board, which has a beefy 600 MHz ARM processor on board. It also packs 500 MB of DRAM—more than enough for storing pixel data for an ancient display.

To drive the old display, [Ted] whipped up a state machine on the FPGA. It’s tasked with fetching display data from RAM and creating the appropriate timings for the MDA display interface. The images are stored directly in an array in C code running on the ARM core. From there, they are copied into the FPGA’s RAM for trucking out to the display. The 720×350 images are stored as 1 bit per pixel, and are created by converting the original JPEGs into single-bit bitmaps in GIMP, before final conversion into a C code array via utility of [Ted’s] own design.

If you’ve ever wanted to display your images in resplendent amber or green, then this could be the project for you. It’s also just a great way to learn about using FPGAs and interfacing with alternative display technologies. If you’ve been whipping up your own retro display hacks, don’t hesitate to drop us a line.