Introduction
Anyone that has known me longer than a few weeks, understands that I have a deep and abiding dislike of all things Microsoft. I’m a long term Unix user. I cut my teeth, on early versions of SunOS, and I might be one of the last living human beings to have successfully built a properly booting “MINIX” based computer. An actual 9 track tape containing the full source distribution of BSD ~2.x lingers in a closet here at the house. I have done significant VHDL and Verilog development under Linux, and will probably continue to do so for the foreseeable future. This being said…
My current work requires the use of tools that only run under Windows. My employer, while fairly supportive of Linux still operates infrastructure that is primarily Microsoft-centric. It became apparent, a few weeks ago, that there was a lack of resources online that support the installation and use of GHDL/GTKWave under Windows. Given that I have to spend most of my working time using Windows, it’s probably time to start limiting the number of OSes that I have to deal with on my desktop.
There is a counter-argument, of course, that I could run a Linux VM under something like VirtualBox. I usually hear this argument made by people that haven’t tried doing long term development work under VirtualBox. VirtualBox is a great tool. Unfortunately, it has problems running on modern hardware. I could buy VMWare, but I’m not going to. I owned a VMWare license at some point. I’ve used it a lot in a professional setting. Shamelessly paraphrasing my best friend, about 8 years ago… “I just don’t have time to fool around with operating systems any longer”.
This post is the inauguration of my journey toward sharpening my formal verification background. Along the way, I plan for there to be a good bit of dawdling about around DSP related topics relative to FPGA development. I’m going to concentrate on formal verification of VHDL. My journey, with purpose, is avoiding the use of System Verilog. I have no problem with System Verilog. However, I believe that someone focused on VHDL development should be able to perform verification on their work without having to learn a new language.
Latest statistics indicate that VHDL is in use by around 60% of active HDL developers. Requiring someone to learn a new language simply slows adoption of formal verification. For those that enjoy learning new languages, I’ll probably also occasionally venture off the path to look at using Python for co-simulation applications. Most of what I do these days is centered on putting things in space. Formal verification is important. Co-sim is important.
‘Nuf said… On to the work…
Installing MSYS2
The first step in installing GHDL under WIndows 10 is to install MSYS2. MSYS2 describes itself as a “collection of tools and libraries providing you with an easy-to-use environment for building, installing and running native Windows software”. That’s about right. It’s not bad actually. The installer does a pretty good job. The package manager is, in fact, PACMAN, which should be familiar to folks that have built and used an Arch Linux distribution.
I won’t repeat the MSYS2 installation guide, as it’s both well written and pretty straight forward. I will offer some notes, however.
Install Pointers
Pointer Number 1: DO NOT attempt to place MSYS2 in “Program Files”. The prominent, but efficient, warning about using a “short ASCII-only path on a NTFS volume, no accents, no spaces, no symlinks, no subst or network drives, no FAT“, isn’t a joke. My recommendation is to use “C:\msys64”. I get the aversion to hanging something like this right off the root directory. It’s just… Sloppy… Heed the warning. The trouble you will save yourself later, is vast.
Pointer Number 2: Step (6) recommends running “pacman -Syu”. You want to do this until pacman says there is nothing left to do. My last install required running pacman three times. Let pacman do it’s job.
Installing Miscellaneous Useful Packages
MSYS2 packages are catalogued here: https://packages.msys2.org/queue
Some useful packages include…
base-devel
From the MSYS2 MinGW 64-bit shell prompt…
pacman -S base-devel
This will install a host of useful development tools…
gcc Toolchain
If you plan to be using GHDL fairly often, you’ll probably want to be working in the MinGW 64-bit environment. I installed the appropriate gcc toolchain to compile for this environment. There are other cross-compilation environments that might be useful as well, including ARM and MIPS cross-compilation toolchains.
pacman -S --needed mingw-w64-x86_64-toolchain
git
This is a necessary package. A working git will be required later to support both installation/build of UVVM and OSVVM. This one isn’t really optional.
pacman -S git
Python Signal Processing Tools
It’s very likely that future posts will discuss DSP related topics. Python can be very useful for avoiding unnecessary entanglements with MATLAB. I love MATLAB. I use it everyday. MATLAB is far from free, in every possible context of the term “free”, and Python makes a fair substitute. I’m actively trying to use Python more frequently for signal processing work. It is good.
pacman -S mingw-w64-x86_64-python-scipy mingw-w64-x86_64-python-matplotlib mingw-w64-x86_64-python-numpy
If you’re strictly here to work with GHDL, then these may be optional. We may be using these, however, for co-simulation support later.
Installing GHDL Using PACMAN
Installing GHDL is very straightforward. There are two variants of GHDL current building under MSYS2. The first variant is “mcode”. I don’t recommend installing the “mcode” variant. Performance is fantastic, but HDL doesn’t compile to an executable. As a consequence, you can’t use gdb to debug your HDL. I’ve also had some trouble building OSVVM and UVVM with the mcode variant. The LLVM (Low Level Virtual Machine) variant works just great.
pacman -S mingw-w64-x86_64-ghdl-llvm
Afterwards, you should be able to type “ghdl -v” from the command line, and GHDL should run and tell you what version you’ve installed.
Installing GTKWave
GTKWave is an absolute necessity. It’s a very capable visualization tool for waveform output files from GHDL. I’ve used GTKWave in conjunction with Xilinx Vivado, by the way.
pacman -S mingw-w64-x86_64-gtkwave
Once installation is finished, you should be able to type “gtkwave” and the GTKWave main window should pop up. This was personally very satisfying to see.
Installing Notepad++
I started using Notepad++ about two months ago at work. I can’t say enough good things about it. Notepadd++ appears to be a really good open source editor. Both VHDL and Verilog profiles are supported (along with just about every other language you can imagine).
A Makefile Template
To get started, here is a makefile template that I developed a while ago for building under GHDL. It’s straightforward, and could use some work, but this, and the code that follows, make testing GHDL fairly straightforward. This makefile has been tested using GHDL under Windows 10.
# vhdl files
FILES = source/*
VHDLEX = .vhd
# testbench
TESTBENCHPATH = testbench/${TESTBENCHFILE}$(VHDLEX)
TESTBENCHFILE = ${TESTBENCH}_tb
#GHDL CONFIG
GHDL_CMD = ghdl
GHDL_FLAGS = --ieee=synopsys --warn-no-vital-generic
SIMDIR = simulation
STOP_TIME = 500ns
# Simulation break condition
GHDL_SIM_OPT = --stop-time=$(STOP_TIME)
VCDFILE = ${SIMDIR}/${TESTBENCHFILE}.vcdgz
WAVEFORM_VIEWER = gtkwave
.PHONY: clean
all: clean compile run view
compile:
ifeq ($(strip $(TESTBENCH)),)
@echo "TESTBENCH not set. Use TESTBENCH=<value> to set it."
@exit 1
endif
@mkdir -p simulation
@$(GHDL_CMD) -i $(GHDL_FLAGS) --workdir=simulation --work=work $(TESTBENCHPATH) $(FILES)
@$(GHDL_CMD) -m $(GHDL_FLAGS) --workdir=simulation --work=work $(TESTBENCHFILE)
#@mv $(TESTBENCHFILE) simulation/$(TESTBENCHFILE)
run:
@$(GHDL_CMD) -r $(GHDL_FLAGS) --workdir=simulation --work=work $(TESTBENCHFILE) --vcdgz=$(VCDFILE) $(GHDL_SIM_OPT)
view:
@gunzip --stdout $(SIMDIR)/$(TESTBENCHFILE).vcdgz | $(WAVEFORM_VIEWER) --vcd
clean:
@rm -rf $(SIMDIR)
Testing
The two source files, shown below, can be used in conjunction with the makefile above to test your new Windows 10 based GHDL development environment. Create a source directory… Create two directories under the source directory called {source, testbench}. Place the makefile in the top level directory. Drop counter.vhd into the source directory. Copy counter_tb.vhd into the testbench directory.
Assuming installation was successful, you should be able to run “make TESTBENCH=counter” from the top level directory. Once everything compiles, GTKWave should start, and load the resulting .vcd file.
A Simple Counter (counter.vhd)
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity counter is
port (
clk: in std_logic;
n_rst: in std_logic;
cout: out std_logic_vector (7 downto 0)
);
end entity;
architecture behaviour of counter is
signal cnt: std_logic_vector (7 downto 0);
begin
process (clk, n_rst)
begin
if n_rst = '0' then
cnt <= (others => '0');
elsif rising_edge(clk) then
cnt <= cnt + 1;
end if;
end process;
cout <= cnt;
end architecture;
A Simple Testbench (counter_tb.vhd)
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity counter_tb is
end entity;
architecture testbench of counter_tb is
component counter
port(
clk: in std_logic;
n_rst: in std_logic;
cout: out std_logic_vector (7 downto 0)
);
end component;
signal clk: std_logic;
signal n_rst: std_logic;
signal cout: std_logic_vector (7 downto 0);
begin
dut: counter port map (clk, n_rst, cout);
process
begin
clk <= '0';
wait for 5 ns;
clk <= '1';
wait for 5 ns;
end process;
process
begin
n_rst <= '0';
wait for 10 ns;
n_rst <= '1';
wait for 250 ns;
end process;
end;
Conclusion
If you have any issues with building a working development environment based on the above directions, it’s important to spend some time with Google searching for answers. In my opinion, this is one of the best ways to learn. My hope is that this post provides some working/verified guideposts to assist with getting GHDL up and running, but as always, YMMV (Your Mileage May Vary). GHDL is under active development. I spent a few hours getting GHDL running under Windows. Hopefully this post helps someone save a little time!
My next post will detail installation and pre-compilation of OSVVM and UVVM. I’ll be taking a long and detailed look at both frameworks. My understanding is that OSVVM runs quite nicely under UVVM. UVVM appears to have a large, and growing, collection of verification IP. Stay tuned…