Programming an FPGA with Verilog looks a lot like programming. But it isn’t, at least not in the traditional sense. There have been several systems that aim to take C code and convert it into a hardware description language. One of these, cynth, is simple to use and available on GitHub. You will need to install scala and a build system called sbt, if you want to try it.
There are limitations, of course. If you want a preprocessor, you’ll have to run it separately. You can’t use global variables, multiplication, floats, and many other pieces of C. The compiler generates a Verilog file for each C function.
Continue reading “FPGAs in C with Cynth”
The Linux kernel recently added support for loading firmware into an FPGA via the FPGA Manager Framework. [OpenTechLab] has built a driver for the Lattice iCE40 FPGA (same chip used on the iCEStick and other development boards). One attraction to the iCE40 is there is an open source toolchain called iCEStorm.
Even if you aren’t specifically interested in FPGAs, the discussion about Linux device drivers is good background. The principles would apply to other drivers, and would definitely apply if you want to write another FPGA loader.
Continue reading “Lattice iCE40 FPGA Configured by Linux Kernel”
By now, most of us have had some experience getting ROMs from classic video games to run on new hardware. Whether that’s just on a personal computer with the keyboard as a controller, or if it’s a more refined RetrioPie in a custom-built cabinet, it has become relatively mainstream. What isn’t mainstream, however, is building custom hardware that can run classic video games on the original console (translated). The finished project looks amazing, but the prototype blows us away with it’s beauty and complexity.
[phanick]’s project is a cartridge that is able to run games on the Polish Famicon clone called the Pegasus. The games are stored on an SD card but rather than run in an emulator, an FPGA loads the ROMs and presents the data through the normal edge-connector in the cartridge slot of the console. The game is played from the retro hardware itself. It takes a few seconds to load in each ROM, but after that the Pegasus can’t tell any difference between this and an original cartridge.
The original prototype shown here was built back in 2012. Since then it’s been through a few iterations that have reduced the size. PCBs were designed and built in-house, and the latest revision also includes a 3D-printed case that is closer to the size of the original Famicon cartridges.
Even if you don’t have an interest in classic video games or emulation, the video below is worth checking out. (Be sure to turn on the subtitles if you don’t speak Polish.) [phanick] has put in a huge amount of time getting all of the details exactly right, and the level of polish shows in the final product. In fact, we’ve featured him before for building his own Famicom clone.
Continue reading “FPGA Emulates NES Cart; Prototype So Cyberpunk”
Industrial controls are fun to use in a build because they’re just so — well, industrial. They’re chunky and built to take a beating, both from the operating environment and the users. They’re often power guzzlers, though, so knowing how to convert an industrial indicator for microcontroller use might be a handy skill to have.
Having decided that an Allen-Bradley cluster indicator worked with the aesthetic of his project, a Halloween prop of some sort, [Glen] set about dissecting the controls. Industrial indicators usually make that a simple task so that they can be configured for different voltages in the field, and it turned out that the easiest approach to replacing the power-hungry incandescent bulbs with LEDs was to build a tiny PCB to fit inside the four-color lens.
The uniquely shaped board ended up being too small for even series resistors for the LEDs, so a separate driver board was also fabbed. The driver board is set up to allow a single 5-volt supply and logic levels of 3.3-volt or 5-volt, making the indicator compatible with just about anything. The finished product lends a suitably sinister look to the prop.
If you’re not familiar with the programmable logic controllers such an indicator would be used with in the field, then maybe you should try running Pong on a PLC for a little background.
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”