One day [Andy] was cruising around eBay and spotted something interesting. Forty Virtex-E FPGAs for two quid each. These are the big boys of the FPGA world, with 512 user IO pins, almost 200,000 logic gates, packed into a 676-ball BGA package. These are not chips designed for the hobbyist. These chips are not designed for boards with less than six layers. These chips aren’t even designed for boards with 6/6mil tolerances from the usual suspects in China. By any account, a 676-ball package is not like a big keep out sign for hobbyists. You don’t turn down a £2 class in advanced PCB design, though, leading to one of the most impressive ‘I just bought some crap on eBay’ projects we’ve seen.
The project [Andy] had in mind for these chips was a generic dev board, which meant breaking out the IO pins and connecting some SRAM, SDRAM, and Flash memory. The first issue with this project is escape routing all the balls. Xilinx published a handy application note that recommends specific design parameters for the traces of copper under the chip. Unfortunately, this was a six-layer board, and the design rules in the application note were for 5/5mil traces. [Andy]’s board house can’t do six-layer boards, and their design rules are for 6/6mil traces. To solve this problem, [Andy] just didn’t route the inner balls, and hoped the 5mil traces would work out.
With 676 tiny little pads on a PCB, the clocks routed, power supply implemented, too many decoupling caps on the back, differential pairs, static RAM, a few LEDs placed just for fun, [Andy] had to solder this thing up. Since the FPGA was oddly one of the less expensive items on the BOM, he soldered that first, just to see if it would work. It did, which meant it was time to place the RAM, Flash, and dozens of decoupling caps. Everything went relatively smoothly – the only problem was the tiny 0402 decoupling caps on the back of the board. This was, by far, the hardest part of the board to solder. [Andy] only managed to get most of the decoupling caps on with a hot air gun. That was good enough to bring the board up, but he’ll have to figure some other way of soldering those caps for the other 30 or so boards.
Slowly, very slowly, the time when we don’t subject embedded beginners to AVRs and PICs is coming. At a glacial pace, FPGA development platforms are becoming ever more capable and less expensive. [Eric Brombaugh] has been playing around with both ARMs and FPGAs for a while now and decided to combine these two loves into a single board that’s capable of a lot.
This board is fittingly called an STM32F303 + ice5 development board, and does exactly what it says on the tin. There’s an STM32F303 on board providing a 32-bit CPU running at 72 MHz, 48 kB of SRAM, a quarter meg of Flash, and enough peripherals to keep anyone happy. The FPGA side of this board is a Lattice iCE5 with about 3k Look Up Tables (LUTs), and one time programmable non-volatile config memory.
The connections between the ARM and FPGA include a dedicated SPI port, and enough GPIOs to implement full-duplex I2S and a USART. Like all good projects, [Eric] has shared all the files, schematics, and BOMs required to make this board your very own reality, and has provided a few links to the development toolchains. While the FPGA is from Lattice’s ice40 family, it’s not supported by the Open Source Project Icestorm toolchain. Still, it’s a very capable board for ARM and FPGA development.
To decode the device’s packets he reached for his RTL-SDR receiver and took a look at it in software. GQRX confirmed the presence of the carrier and allowed him to record a raw I/Q file, which he could then supply to Inspectrum to analyse the packet structure. He found it to be a simple on-off keying scheme, with bits expressed through differing pulse widths. He was then able to create a Gnu Radio project to read and decode them in real time.
Emulating the transmitter was then a fairly straightforward process of generating a 350MHz clock using the on-board PLL and gating it with his generated data stream to provide modulation. The result was able to control his fan with a short wire antenna, indeed he was worried that it might also be doing so for other similar fans in his apartment complex. You can take a look at his source code on GitHub if you would like to try something similar.
It’s worth pointing out that a transmitter like this will radiate a significant amount of harmonics at multiples of its base frequency, and thus without a filter on its output is likely to cause interference. It will also be breaking all the rules set out by whoever the spectrum regulator is where you live, despite its low power. However it’s an interesting project to read, with its reverse engineering and slightly novel use of an FPGA.
It always surprises us that magnetic levitation seems to have two main purposes: trains and toys. It is reasonably inexpensive to get floating Bluetooth speakers, globes, or just floating platforms for display. The idea is reasonably simple, especially if you only care about levitation in two dimensions. You let an electromagnet pull the levitating object (which is, of course, ferrous). A sensor detects when the object is at a certain height and shuts off the magnet. The object falls, which turns the magnet back on, repeating the process. If you do it right, the object will reach equilibrium and hover near the sensor.
Some students at Cornell University decided to implement the control loop to produce levitation using an Altera FPGA. An inductive sensor determined the position of an iron ball. The device uses a standard proportional integral derivative (PID) control loop. The control loop and PWM generation occur in the FPGA hardware. You can see a video of their result, below.
Usually, when you think of driving a VGA–in software or hardware–you think of using a frame buffer. The frame buffer is usually dual port RAM. One hardware or software process fills in the RAM and another process pulls the data out at the right rate and sends it to the VGA display (usually through a digital to analog converter).
[Connor Archard] and [Noah Levy] wanted to do some music processing with a DE2-115 FPGA board. To drive the VGA display, they took a novel approach. Instead of a frame buffer, they use the FPGA to compute each pixel’s data in real-time.
[Sam Miller], [Sahil Gupta], and [Mashrur Mohiuddin] worked together on a very fast LED matrix display for their final project in ECE 5760 at Cornell University.
They started, as any good engineering students, by finding a way to make their lives easier. [Sam] had built a 32×32 LED matrix for another class. So, they made three more and ended up with a larger and more impressive 64×64 LED display.
They claim their motivation was the love of music, but we have a suspicion that the true reason was the love all EEs share for unnaturally bright LEDs; just look at any appliance at night and try not be blinded.
The brains of the display is an Altera DE2-115 FPGA board. The code is all pure Verilog. The FFT and LED control are implemented in hardware on the FPGA; none of that Altera core stuff. To generate images and patterns they wrote a series of python scripts. But for us it’s the particle test shown in the video below that really turns our head. This system is capable of tracking and reacting to a lot of different elements on the fly why scanning the display at about 310 FPS. They have tested display scanning at twice that speed but some screen-wrap artifacts need to be worked out before that’s ready for prime time.
The team has promised to upload all the code to GitHub, but it will likely be a while before the success hangover blows over and they can approach the project again. You can view a video interview and samples of the visualizations in the videos after the break.
Thanks to their Professor, [Bruce Land], for submitting the tip! His students are always doing cool things. You can even watch some of his excellent courses online if you like: Here’s one on the AVR micro-controller.
We’ve seen a lot of Enigma builds here at Hackaday — the World War II era encryption machine captured our readers’ imaginations. But perhaps the more important machines to come out of cryptanalysis during that era were Turing’s electromechanical Bombe, because it cracked Enigma, and the vacuum-tube-based Colossus, because it is one of the first programmable electronic digital computers.
[Ben]’s build combines his explorations into old-school cryptanalysis with a practical learning project for FPGAs. If you’re interested in either of the above, give it a look. You can start out with his Python implementations of Colossus to get your foot in the door, and then move on to his GitHub repository for the FPGA nitty-gritty.
It’s also a cool example of a use for the XuLA2 FPGA board and its companion StickIt board that plug straight into a Raspberry Pi for programming and support. We haven’t seen many projects using these since we first heard about them in 2012. This VirtualBoy hack jumped out at us, however. It looks like a nice platform. Anyone else out there using one?