Stage 4: Writing the FPGA design in VHDL
So we’ve finally made it to the finale in our series on designing with FPGA’s. Following on from our previous article where we implemented the software functions we need in order to be able to reprogram our FPGA easily, we can now get into the nitty-gritty of programming the FPGA to do what we want.
Firmware with a difference
As mentioned briefly in our first article, FPGA’s are not like your common microcontroller. A microcontroller has a processor core that executes instructions sequentially that are stored in on board memory. They’re really good at logically complex sequential operations but are much harder to constrain time wise. Unless you’re using interrupts/hand-crafted assembler then you can probably argue that they’re also non-deterministic, meaning that you don’t know when exactly something is going to be performed. This is due to the other workload the microcontroller has to work through first.
The FPGA on the other hand is an array of logic which you can specify via an HDL to become the logical function you need. Unlike Microcontrollers, FPGA’s excel at more simplistic, high speed parallel tasks. They’re also much more deterministic and are fantastic at doing tightly constrained real time operations and calculations. FPGA’s are consistently used to implement non-standard protocols, tightly controlled DSP calculations and tasks that require parallelizable functions to be performed. They do however struggle with algorithmically complex functions, requiring a lot of logic resource in order to do so.
Writing the VHDL required to get an FPGA working is a very different beast to writing the C or assembler for a microcontroller. When you write VHDL you constantly have to think about how all the logic you’re defining will work with other parts of your design on a real time, concurrent basis. It’s a very different mindset from writing any other language. You also want to be as far removed from device primitive instantiations as much as possible so that you can make good use of the modularity VHDL can provide (although sometimes you can’t get around them).
Debugging/Verifying VHDL is also very different. In C you can run simulators or debug on the platform by stepping through your code with a debugging tool. In VHDL you rely on using test benches and bus functional models to simulate and verify the majority of the functionality of your design. Only very rarely would you resort to using the equivalent debugging tool which is an IP block that captures the states of certain pre-specified signals for download via a programmer/debugger tool. A typical industry setup for designing FPGA’s usually has two or three verification engineers to each design engineer, demonstrating how much more verification work goes into an FPGA than that which would happen on a typical microcontroller.
VHDL Simulation Waveforms used in Informal Verification
There are a lot of different tasks when it comes to designing an FPGA with VHDL. Some of the most frequent are:
- Doing the design in VHDL
- Writing informal test benches for the design in VHDL
- Making the verification solution (which is different from an informal test bench!) in a scripted language
- Checking timing/using static timing analysis
- Checking for clock domain crossing/meta-stability/synchronisation etc…
The list of things to do very much depends on how complex your design is. If you’re making a design which is “low speed” (usually below some tens of megahertz) then you can usually get away with not doing as many timing checks. If you’re only ever using one clock domain (read as just using one clock to run the whole design) then you can avoid clock domain crossing checks. You can also get away with only doing informal test benches if what you are doing if very simple or is not going into a product that needs to be reliable (if they even exist). The list of things to do is very much tailored to the requirements.
In our case, we just want to do some extremely simple stuff. This means we can actually skip test benches, timing checks and other checks all together. All we plan on doing is writing some really simple VHDL in order to show the basics of FPGA design. At some point in the near future, we will write another series on “high speed” FPGA design and verification because that is a whole topic in itself.
Get the tools
We mentioned in previous articles that there are a few main vendors in the FPGA market, with Xilinx and Altera being the biggest. Each of these vendors provides their own software tools in order to design and synthesise FPGA logic. Because we’re focusing on a Xilinx part, we’re going to be using the Xilinx tool set in order to do our design.
Xilinx has two main tools that you can use to design FPGA’s: ISE and Vivado. Vivado is aimed at their much newer line of FPGA’s, more specifically their “7 Series” and above e.g. Artix 7, Kintex 7 and Virtex 7. ISE is aimed at all FPGA’s historically before this, including our humble Spartan 3A. This means that we need to use Xilinx ISE in order to create our design. At the time of writing this (and for probably most of the future now as ISE is no longer in development), the version of ISE I’m going to use is the 64 bit version of 14.7.
ISE has pretty much most of the functionality you will need in order to develop a basic FPGA. The IDE has an built in text editor, GUI windows for the FPGA workflow and also a way to launch iSim, their basic FPGA simulation tool. If we were to set up this design to be built from an automated platform or other synthesizer tools/simulators were to be used then the tool-chain becomes trickier to set up. As we quickly mentioned before though, we’re all good in this instance.