Homebrew GPU Tackles Quake

Have you ever wondered how a GPU works? Even better, have you ever wanted to make one? [Dylan] certainly did, because he made FuryGPU — a fully custom graphics card capable of playing Quake at over 30 frames per second.

As you might have guessed, FuryGPU isn’t in the same league as modern graphics card — those are made of thousands of cores specialized in math, which are then programmed with whatever shaders you want. FuryGPU is a more “traditional” GPU, it has dedicated hardware for all the functions the GPU needs to perform and doesn’t support “shader code” in the same way an AMD or NVIDIA GPU does. According to [Dylan], the hardest part of the whole thing was writing Windows drivers for it.

On his blog, [Dylan] tells us all about how he went from the obligatory [Ben Eater] breadboard CPU to playing with FPGAs to even larger FPGAs to bear the weight of this mighty GPU. While this project isn’t exactly revolutionary in the GPU world, it certainly is impressive and we impatiently wait to see what comes next.

Continue reading “Homebrew GPU Tackles Quake

Weird Things To Do With FPGAs

There’s an old joke about how can you find the height of a building using a barometer. One of the punchlines is to drop the barometer from the roof and time how long it takes to hit the ground. We wonder if [Alexlao512] had that in mind when he wrote a post about unconventional uses of FPGAs. Granted, he isn’t dropping any of them off a roof, but still. The list takes advantage of things we usually try to avoid such as temperature variation, metastability, and the effects of propagation delays.

For example, you probably know that hooking up an odd number of inverters into a loop forms an oscillator—the so-called ring oscillator. The post discusses how you can use an oscillator like that to measure propagation delay or even as a strain gauge. If you put pressure on the FPGA chip, the frequency of the ring oscillator will subtly vary.

Continue reading “Weird Things To Do With FPGAs”

Do We Need A New Hardware Description Language?

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

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

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?

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

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.