I haven’t posted much about any of my projects for a some time. This is because I’ve spent the past few months squirrelling away on something new: a while ago I decided a good way to learn more about VHDL would be to write a parser/checker for it. I had a vague plan of using it to write a linting tool or indexer. I’ve also wanted to learn more about LLVM so I started hacking together a code generator on the back end of the linting tool that generated LLVM IR for sequential VHDL processes. After that I thought I might as well write a simulation kernel too and it snowballed into something approximating an embryonic VHDL compiler/simulator.
The tool is currently called “nvc” which might stand for “Nick’s VHDL Compiler” or perhaps “New VHDL Compiler”. You can get it from GitHub here: github.com/nickg/nvc. See the README file for instructions on how to build and run it.
The eventual goal is full IEEE 1076-1993 support, or at least as much as possible until I get bored. Currently its capabilities are very limited. In particular it doesn’t implement enough of VHDL to compile the IEEE std_logic_1164 package which makes it almost useless for any real-world designs. The following should give an example of what it can do at the moment though.
entity counter is
port (
clk : in bit;
count : out integer );
end entity;
architecture behav of counter is
begin
process (clk) is
variable count_var : integer := 0;
begin
if clk'event and clk = '1' then
count_var := count_var + 1;
count <= count_var;
end if;
end process;
end architecture;This is a very simple behavioural model of a counter that increments on rising edges of clk. We can also add a top-level entity to generate the clock signal:
entity top is end entity;
architecture test of top is
signal clk : bit := '0';
signal count : integer := 0;
begin
clkgen: process is
begin
wait for 5 ns;
clk <= not clk;
end process;
uut: entity work.counter
port map (
clk => clk,
count => count );
process (count) is
begin
report integer'image(count);
end process;
end architecture;The final process will print the value of the counter every time it changes. You may normally have written the clkgen process with a concurrent assignment:
clk <= not clk after 5 ns;
Unfortunately processes and instantiations and the only sort of concurrent statements implemented in nvc at the moment. This is not as restrictive as it sounds: apart from generate statements all others can be trivially rewritten as processes. This is in fact how they are specified in the standard.
First we need to run the analysis step which parses the code into an internal format, performs type checking, and runs some simplification passes such as constant folding. With the above code in a single file counter.vhd we can run:
$ nvc -a counter.vhd
[gc: freed 425 trees; 297 allocated]
The work library now contains the serialised abstract syntax tree for each analysed design unit:
$ ls -lh work
total 24K
-rw-r--r-- 1 nick nick 8 Nov 5 13:37 _NVC_LIB
-rw-r--r-- 1 nick nick 682 Nov 5 13:37 WORK.COUNTER
-rw-r--r-- 1 nick nick 1.6K Nov 5 13:37 WORK.COUNTER-BEHAV
-rw-r--r-- 1 nick nick 33 Nov 5 13:37 WORK.TOP
-rw-r--r-- 1 nick nick 7.6K Nov 5 13:37 WORK.TOP-TEST
Next we run the elaboration step which builds the full design hierarchy starting from a top level entity. It also runs the LLVM IR code generation step to produce a bitcode file.
(This step produces a large amount of debug output which should be ignored.) If you look inside the work library again you should see the generated LLVM bitcode and a serialised AST for the elaborated design – this is used for debugging later.
$ ls -lhtr work | tail -2
-rw-r--r-- 1 nick nick 8.2K Nov 5 13:39 WORK.TOP.elab
-rw-r--r-- 1 nick nick 1.3K Nov 5 13:39 _WORK.TOP.elab.bc
The elaboration step runs a number of simple LLVM optimisation passes over the bitcode before writing it out but you can run more if you like using the standard LLVM opt tool.
Now we can finally simulate the model! The simplest way to do this is in batch mode as follows:
$ nvc -r --stop-time=50ns top
0ms+0: Report Note: 0
5ns+2: Report Note: 1
15ns+2: Report Note: 2
25ns+2: Report Note: 3
35ns+2: Report Note: 4
45ns+2: Report Note: 5
Normally nvc will run until there are no more events scheduled but as the clkgen process will schedule events forever we have to specify an explicit stop time. The bitcode file is transparently converted into native machine code using LLVM’s JIT engine when the simulation is loaded.
Commercial simulators usually provide an interactive debugging environment as well as a batch mode and nvc tries to emulate this. Use the -c switch to the run command to enter interactive mode:
This mode uses TCL for command processing, which is the de-facto standard for scripting in the EDA industry. If you have readline or libedit installed you’ll also get fancy line-editing capabilities. The features here are currently pretty limited but we can see the state of all the signals in the design:
% show signals
:top(test):clk STD.STANDARD.BIT '0'
:top(test):count STD.STANDARD.INTEGER 0
Note that nvc has collapsed the ports in counter with the signals in top as they are identical: this might be confusing if you’re searching for a particular name. Now we can run the simulation and verify the signal values change:
% run 45 ns
% 0ms+0: Report Note: 0
5ns+2: Report Note: 1
15ns+2: Report Note: 2
25ns+2: Report Note: 3
35ns+2: Report Note: 4
45ns+2: Report Note: 5
% show signals
:top(test):clk STD.STANDARD.BIT '1'
:top(test):count STD.STANDARD.INTEGER 5
Notice that the run command returns straight away and the print outs happen in the background: this is because the interactive mode forks off another process to run the simulation.
A legacy of the project’s origins as a linter, the error messages try to be more helpful than most VHDL compilers:
counter.vhd:33: no suitable overload for operator
"+"(STD.STANDARD.BIT, universal integer)
clk <= not (clk + 1);
^^^^^^^This is about the limit of what nvc can do at the moment. I’m not sure how far I’ll develop it but it’s been good fun hacking thus far. So obviously don’t start using it for real designs or reporting bugs just yet ;-).
Posts