Jamie Iles

Quartus Prime has an IDE interface for building FPGA projects which can work well, but for me it falls short in a few areas. We’ll look at how we can integrate Quartus FPGA building in CMake so it can be built along with the rest of a project.

Intel FPGAs use the Quartus Prime software for synthesis and on Linux, the supported OS is Red Hat Enterprise Linux. It is possible to run Quartus Prime on Ubuntu too with some extra steps, but this is not supported by Intel. By installing Quartus Prime into a Docker image, we can make it easy to quickly deploy the tools to other systems including laptops and continuous integration jobs.

The Keynsham SoC featuring the Oldland CPU now runs on the DE0-CV. The DE0-CV is a bigger board than the DE0-NANO that I was previously using and has a number of nice features: A bigger, Cyclone V device. 64MB SDRAM versus 32MB on the DE0-NANO. VGA output with a simple 12-bit ADC. PS/2 controller. 6x7 segment displays More accessible pushbuttons. On the new board the Keynsham SoC only uses ~25% of logic resources so there is plenty of room for expansion!

Simulating Verilog, particularly once a design grows beyond anything simple can be both tricky and frustrating. I’m going to describe the simulation process that I’ve used during development of the Oldland CPU project in the hope that it might be useful to others. Don’t develop in FPGA tools It is entirely possible to develop a design in the FPGA tools, but this doesn’t scale - you’re confined to the lacklustre editor, long compile times and cryptic error messages in addition to being tied to a vendor flow.

I’ve recently released an early version of a GDB remote serial protocol implementation that runs on bare-metal on a Raspberry Pi that allows you do debug bare metal applications without the use of a JTAG. Once running you can connect with GDB as a remote target and perform all of the normal debugging that you’d expect and you can even single step through interrupt handlers and exceptions. The implementation uses the security extensions of the ARM core so that the target application requires no modification.

Introduction Any reasonably sized program needs some half decent debug logging mechanism. At a minimum we want something that can allow us to enable debug prints at compile time for production builds, but often we want more than that – we need to handle different verbosity levels, and once we have a number of components we probably want to be able to selectively enable some debug. The other part of debug logging is where we store the information – it may be stdout, a file, syslog, but for now lets assume stdout for simplicity.