FPGA

354 Articles

DIY 6 GHZ Pulse Compression Radar

April 6, 2024 by 10 Comments

Conceptually, radar is pretty simple: send out a radio wave and time how long it takes to get back via an echo. However, in practice, there are a number of trade-offs to consider. For example, producing a long pulse has more energy and range, but limits how close you can see and also the system’s ability to resolve objects that are close to each other. Pulse compression uses a long transmission that varies in frequency. Reflected waves can be reconstituted to act more like a short pulse since there is information about the exact timing of the reflected energy. [Henrik] didn’t want to make things too easy, so he decided to build a pulse compression radar that operates at 6 GHz.

In all fairness, [Henrik] is no neophyte when it comes to radar. He’s made several more traditional devices using a continuous wave architecture. However, this type of radar is only found in a few restricted applications due to its inherent limitations. The new system can operate in a continuous wave mode, but can also code pulses using arbitrary waveforms.

Some design choices were made to save money. For example, the transmitter and receiver have limited filtering. In addition, the receiver isn’t a superheterodyne but more of a direct conversion receiver. The signal processing is made much easier by using a Zynq FPGA with a dual-core ARM CPU onboard. These were expensive from normal sources but could be had from online Chinese vendors for about $17. The system could boot Linux, although that’s future work, according to [Henrik].

At 6 GHz, everything is harder. Routing the PCB for DDR3 RAM is also tricky, but you can read how it was done in the original post. To say we were impressed with the work would be an understatement. We bet you will be too.

Radar has come a long way since World War II and is in more places than you might guess. We hate to admit it, but we’d be more likely to buy a ready-made radar module if we needed it.

Linear Feedback Shift Registers For FPGAs

April 6, 2024 by 28 Comments

If you want to start an argument at a Hackaday meeting, you have only to ask something like “How much does this weigh?” or “What time is it?” But if you really want to start a street brawl, you can always say, “Are these numbers random?” Making random numbers that are actually random is actually a tough nut to crack. Most of what we do is, technically, pseudo-random (but we’ll say random number and assume you know what we mean). One way to generate seemingly random sequences is to use a linear feedback shift register or LFSR. You can use LFSRs in software, but they are also very useful in hardware design and [Adam Taylor] takes us through his use of them on FPGAs in a recent post. Continue reading “Linear Feedback Shift Registers For FPGAs” →

Homebrew GPU Tackles Quake

March 28, 2024 by 21 Comments

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

March 21, 2024 by 5 Comments

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?

March 15, 2024 by 19 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” →