Recently I purchased a Sipeed TANG PriMER development board featuring an Anlogic EG4S20 FPGA (codenamed Eagle S20). The only reason I bought the board was to see what Anlogic FPGAs are capable of, since I had never heard of that FPGA vendor before. No need to think twice when the board costs less than 20$.
In advanced FPGA systems which require different clock frequencies for different parts of the design, there is often a shortage of global clock buffers. Often several of the clocks are related (see below) and it becomes possible to use a single clock plus several clock enable signals, instead of several dedicated clocks. This article tries to shed some light on the impact these two alternatives can have on an FPGA system.
For a long time I did not like when people declare their ports like this in VHDL:
entity example is port ( foo : in std_logic; bar : out std_logic; glarp : inout std_logic );
I was fine with vertical alignment along the colons, but the additional whitespace after the in/out keywords just looked horrific to me.
The same goes, to a less extent, for Verilog multibit wires/registers:
module example ( input wire [7:0] foo, output reg bar )
This all changed when I found out about column mode editing in Notepad++.
Here is some general advice for simulation of HDL code. No respect is paid to verification methodologies like UVM or OSVVM. Most of it is obvious, but it helps my memory when I write these things down.
- Use assert statements to catch error events. Your eyes can miss even the most obvious error when scanning over some simulation waveforms after a long day in front of the screen.
- Use log files and/or report statements to save information about the status and progress of simulation, errors or any other noteworthy event. This will speed up the task of locating events of interest and will allow you to do text searches over those files.
- Use colors, the right radix for numbers and hierarchical structure in your waveform viewer for optimal data representation. Unless you prefer to look at heaps of green lines with loads of 0’s and 1’s around them.
- Save your simulator/waveform settings. At some point you will come back and won’t have to repeat the tedious task of setting up a neat waveform view. The simulator/waveform settings should also go into the repository (separate folder for each simulator), but it’s a matter of taste.
There is a difference between testbench files and simulation files:
Testbench files are independent of the simulator and comparable tools. They include testbench configuration files, test case descriptions or stimuli and golden reference output files.
Simulation files are setup and command files for a simulator or similar vendor tool. Related configuration files include waveform settings and simulation scripts.
A project’s folder structure should also draw this distinction to keep simulator/vendor independent files separate. Log files and results should therefor be put in an output folder alongside the testbench files.
What is a HDL?
A hardware description language (HDL) is a computer language used to describe the structure and behavior of digital (and sometimes analog) electronic circuits. A HDL may look quite similar to a traditional programming language and indeed will behave similar as well in some aspects, however in other aspects there are important differences that one must be aware of when writing HDL code.
This article is meant to give an extremely brief overview of HDLs, their origins, what’s so special about them and what state of the art HDLs of today can offer.