These days, if you want to start learning about FPGAs, it can be a daunting experience. There’s a huge variety of different platforms and devboards and it can be difficult to know where to start. [RoGeorge] decided to take a different tack. Like a 16-year-old drag racer, he decided to run what he brung – a printer control panel cum FPGA development board (Romanian, get your Google Translate on).
[RoGeorge] was lucky enough to score a couple of seemingly defective control panels from HP Laserjets discarded by his workplace. Seeing potentially good parts going to waste, like keypads and LCDs, he decided to investigate them further – finding a 50,000 gate Xilinx Spartan IIE running the show. Never one to say no to opportunity, [RoGeorge] dived in to learning how to work with FPGAs.
The forum posts are a great crash course in working with this sort of embedded FPGA platform. [RoGeorge] covers initial mapping of the peripherals on the board & finding a JTAG connector and programming solution, before moving on to basic FPGA programming and even covers the differences between sequential programming on microcontrollers and the parallel operation of FPGAs. Even if you don’t intend to get down and dirty with the technology, spend half an hour reading these posts and you’ll be far more knowledgeable about how they work!
In the end, [RoGeorge] showed how to teach yourself to work with FPGAs for the price of a couple of programming cables – not a mean feat by any means. It’s a testament to the hacker spirit, and reminds us of [SpriteTM]’s efforts in hacking hard drive controllers.
[Robert Baruch] wanted to tackle a CPU project using an FPGA. One problem you always have is you can either mimic something that has tools and applications or you can go your own way and just build everything from scratch (which is much harder).
[Robert] took the mimic approach–sort of. He built a CPU with the express idea of running Infocom’s Z-machine virtual machine, which allows it to play Zork. So at least when you are done, you don’t have to explain to your non-tech friends that it only blinks an LED. Check out the video, below, for more details.
Continue reading “Zork Comes to Custom FPGA CPU (Again)”
Building a software defined radio (SDR) involves many trades offs. But one of the most fundamental is should you use an FPGA or a CPU to do the processing. Of course, if you are piping data to a PC, the answer is probably a CPU. But if you are doing the whole system, it is a vexing choice. The FPGA can handle lots of data all at one time but is somewhat more difficult to develop and modify. CPUs using software are flexible–especially for coding user interfaces, networking connections, and the like) but don’t always have enough horsepower to cope with signal processing tasks (and, yes, it depends on the CPU).
[Eric Brombaugh] sidestepped that trade off. He used a board with both an ARM processor and an ICE FPGA at the heart of his SDR design. He uses three custom boards: one is the CPU/FPGA board, another is a 10-bit converter that can sample at 40 MSPS (sufficient to decode to 20 MHz), and an I2S DAC to produce audio. Each board has its own page linked from the main project.
Continue reading “Ice, Ice, Radio Uses FPGA”
[F4HDK] calls his new computer A2Z because he built everything from scratch (literally, from A to Z). Well, strictly speaking, he did start with an FPGA, but you have to have some foundation. The core CPU is a 16-bit RISC processor with a 24-bit address bus and a 128-word cache. The computer sports 2 megabytes of RAM, a boot ROM, a VGA port and keyboard, and some other useful I/O. The CPU development uses Verilog.
Software-wise, the computer has a simple operating system, a filesystem, and basic programs like a text editor and an image viewer. Development software includes an assembler and a compiler for a BASIC-like language that resides on the PC. You can also run an emulator to experiment with A2Z without hardware. You can see a “car game” running on A2Z in the video below. You can also see videos of some other applications.
Continue reading “FPGA Computer Covers A to Z”
If you are from the United States and of a certain age, it is very likely you owned some form of Commodore computer. Outside the US, that same demographic was likely to own an Amstrad. The Z80-based computers were well known for game playing. [Freemac] implemented a working Amstrad CPC6128 using a Xilinx FPGA on a NEXYS2 demo board.
The wiki posting is a bit long, but it covers how to duplicate the feat, and also gives technical details about the design. It also outlines the development process used ranging from starting with a simple Z80 emulation and moving on to more sophisticated attempts. You can see a video of the device below.
Continue reading “Amstrad on an FPGA”
Gravity can be a difficult thing to simulate effectively on a traditional CPU. The amount of calculation required increases exponentially with the number of particles in the simulation. This is an application perfect for parallel processing.
For their final project in ECE5760 at Cornell, [Mark Eiding] and [Brian Curless] decided to use an FPGA to rapidly process gravitational calculations. This allows them to simulate a thousand particles at up to 10 frames per second. With every particle having an attraction to every other, this works out to an astonishing 1 million inverse-square calculations per frame!
The team used an Altera DE2-115 development board to build the project. General operation is run by a Nios II processor, which handles the VGA display, loads initial conditions and controls memory. The FPGA is used as an accelerator for the gravity calculations, and lends the additional benefit of requiring less memory access operations as it runs all operations in parallel.
This project is a great example of how FPGAs can be used to create serious processing muscle for massively parallel tasks. Check out this great article on sorting with FPGAs that delves deeper into the subject. Video after the break.
Continue reading “Gravity Simulations With An FPGA”
Hackaday reader [nats.fr] wrote in with some code from a project that resizes a video stream on the fly using an FPGA. Doing this right means undoing whatever gamma correction has been applied to the original stream, resizing, and then re-applying the gamma. Making life simpler, [nats.fr] settled on a gamma of two, which means taking a bunch of square roots, which isn’t fast on an FPGA.
[nats]’s algorithm is pretty neat: it uses a first-stage lookup to figure out in which broad range the value lies, and then one step of Hero’s algorithm to refine from there. (We think this is equivalent to saying he does a piecewise linear interpolation, but we’re not 100% sure.) Anyway, it works decently.
Of course, when you start looking into the abyss that is special function calculation, you risk falling in. Wikipedia lists more methods of calculating square roots than we have fingers. One of them, CORDIC, avoids even using multiplication by resorting to clever bitshifts and a lookup table. Our go-to in these type of situations, Chebyshev polynomial approximation, didn’t even make the cut. (Although we suspect it would be a contender in the
gamma=2.2 cases, especially if combined with range-reduction in a first stage like [nats.fr] does.)
So what’s the best/fastest approximation for
sqrt(x) for 16-bit integers on an FPGA? [nats.fr] is using a Spartan 6, so you can use a multiplier, but division is probably best avoided. What about arbitrary, possibly fractional, roots?