Variables and signals in VHDL – and when variables are better

VHDL has two types of what-would-normally-be-called-variables:

* `signal`s, which must be used for inter-process communication, and can be used for process-local storage
* `variable`s which are local to a process.

(there’s also variables of a `protected type` which we’ll ignore for now as they’re another thing altogether)

Tool switches

[@boldport]( asked:

[What are your #FPGA design space exploration techniques?](

which he expands upon:

“Design space exploration” is the process of trying out different settings and design methods for achieving better performance. Sometimes the goals are met without any of it — the default settings of the tools are sufficient. When they’re not, what are your techniques to meet your performance goals?

Yet again, the 140 character constraint leaves me with things unspoken….

Version control for FPGAs

[@boldport](!/boldport) recently asked on Twitter what version control software people used on their FPGA designs. I replied that I use [git]( at home and [Subversion]( at work. The reasons why take a bit more than 140 characters, so I’ve written them here!

Inferred state machines in VHDL (vs 2-process-machines of all things!)

A few weeks ago I read a [blog post]( ) by the illustrious MS researcher Prof. Satnam Singh. He writes about his [Kiwi]( project which he describes as “[trying] to civilise hardware design” – as compared to the explicit writing of state machines.

His example is a Ethernet processor which simply swaps the source and destination MAC addresses over and retransmits them. He has code in C#, and it looks a lot like the inferred state machine style of VHDL I’ve been toying with for a while.

So (finally) I’ve toyed…

Categorised as Uncategorised Tagged

Finally, actually reading a PGM file in VHDL

And so, finally, [after all that setup](/node/65), some code [to read PGM files](/node/66/) and [how to make use of it](/node/67/). Next stage will be writing some files!

As always, the code can be [found on github](

Reading image files with VHDL part 3

[Having written a function](/node/66/) to read a PGM image, how do we use it?

Well, the testbench at the bottom of the pgm vhdl file has an example:
variable i : pixel_array_ptr;
— Without the transpose function, we would have to present the initialisation data in a non-intuitive way.
constant testdata : pixel_array(0 to 7, 0 to 3) := transpose(pixel_array'(
(000, 027, 062, 095, 130, 163, 198, 232),
(000, 000, 000, 000, 000, 000, 000, 000),
(255, 255, 255, 255, 255, 255, 255, 255),

Reading image files with VHDL part 2

Having [set up a library](/node/65/) for reading images, let’s now go on to read an image in!


Recall, we have a function:
impure function pgm_read (filename : string)
return pixel_array_ptr;

So, some declarations – fairly self-explanatory:
file pgmfile : text;
variable width, height : coordinate; — storage for image dimensions
variable l : line; — buffer for a line of text
variable s : string(1 to 2); — to check the P2 header

Reading image files with VHDL part 1 (again)

Data storage
One things VHDL can do ([contrary to popular belief :)](/node/60/)) is 2-D arrays. So reading images into a 2-D array is a very natural way to store the data.

We’ll create a package called `pgm` to keep all our image reading and writing code together:

package pgm is
subtype coordinate : natural;
subtype pixel is integer range 0 to 255;
type pixel_array is array (coordinate range <>, coordinate range <>) of pixel;
type pixel_array_ptr is access pixel_array;
— Function: transpose

libv – assert_equal, str, etc.

The `assert_equal` functions are part of my library of useful things (maybe this could be a start towards [VHDL’s jQuery]( :) `libv`. Why not just use `assert` as is? Well, it’s useful to report all assert results in the same fashion, particularly to include the values that you expected and what you tested, along with the difference between them – often this is useful debugging information.

Here’s an example….


It’s been very kindly pointed out to me via email (by Tricky) that I was talking complete rubbish saying that [VHDL is rubbish at 2d arrays](/node/60/).

What I should’ve said was “VHDL is rubbish at arrays of other arrays”, which is a subtle but critical difference! Arrays of other arrays are very useful (for example in register files), and the fact that the dimensions of one of the arrays must be known at compile time can make some things tricky to impossible. For example, a generic mux with a variable number of inputs can’t easily also have a generic number of bits on each input.