The Wasp: Designing a Front Panel Computer with VHDL, Part 3

Prelude

Before I design any new modules and components, it’d be a good idea to store all files in a project folder in a structured way. This will also include an automated build and test system based on cmake.

So in this short post, I’ll show you how I’m organizing my project files. Then I’ll test this new build and test system by improving the data and address output modules by using type records. If you have your own toolchain set up already or use some kind of IDE, you can skip this post entirely. Or if you’re only interested in the overall Wasp design and not how to run VHDL simulations, you’ll, unfortunately, learn little here.

A CMake Template

A while ago, I found this amazing project template for VHDL projects. This is great work and full credit goes to Pedro Cuadra for it.

Before we proceed, here’s a list of tools you should install on your system. If you’re on Linux, your package manager should find all these tools in their respective repositories. For Window and OSX users, follow the installation instructions provided in the links below:

• git
• ghdl
• cmake
• A good text editor of your choice (e.g., vim, emacs, Atom, Visual Studio Code, etc.)

When you’re done with installing all tools and verified that they work, it’s time to set up a project folder for the Wasp project files.

Start by cloning the template mentioned above. Then remove the remote branches. Alternatively, download the repository as a zip file from it’s GitHub page and extract it on your computer:

$ git clone https://github.com/pjcuadra/ghdl_sample_project.git && cd ghdl_sample_project
$ git remote rm origin

If you don’t wish to keep track of the files with git, just delete the .git folder and .gitignore file.

Next, we’ll test the build system. We’ll do an out-of-source build. Enter this into your command line:

$ mkdir build && cd build
$ cmake ..
$ make check

If everything works, this should be your output:

    Start 1: test.adder.adder_tb
1/4 Test #1: test.adder.adder_tb .............................   Passed    0.00 sec

    Start 2: test.viterbi_encoder.viterbi_encoder_tb
2/4 Test #2: test.viterbi_encoder.viterbi_encoder_tb .........   Passed    0.00 sec

    Start 3: test.viterbi_encoder.next_state_lkup_table_tb
3/4 Test #3: test.viterbi_encoder.next_state_lkup_table_tb ...   Passed    0.00 sec

    Start 4: test.viterbi_encoder.output_lkup_table_tb
4/4 Test #4: test.viterbi_encoder.output_lkup_table_tb .......   Passed    0.00 sec


100% tests passed, 0 tests failed out of 4

Total Test time (real) =   0.02 sec
Built target check

Great! Now, I’m going to add all VHDL models I created so far into the project folder. Module code will go into the src folder and their respective test benches into the sim folder. Additionally, I add one extra line of code to CMakeLists.txt in the project base folder:

This line of code tells ghdl to use the VHDL-2008 standard; ghdl will default to VHDL-93 standard else, which does not support unconstrained arrays. Unconstrained arrays are necessary for the small improvement to the code from last time I’m going to make next.

Improving the Output Modules

As I mentioned last time, the interfaces of the data and address output modules are identical save for the width of their input buses. VHDL offers records for this purpose. I’ll define the new type records in a separate file so it is accessible from all other files. Here’s the code of the records and the updated/improved output modules:

On first look, this seems more convoluted. But there’s a big advantage here. Let’s say at a later stage of the development, I determine that the output modules need an extra control signal for some special function. To add that signal, I’d need to go through the code of all modules to add that input (or output) signal. I’d also need to update all the test benches. A long and tedious process (and a high risk of adding new bugs and errors). With records, I’d simply add the new signal to the record. All modules and/or test benches using that record as in- or output would be able to use that new signal with only little change to the code.

Conclusion

This post made only a little progress. But I thought it would be good to mention at least how I organize my files for this project.

Next time, I’ll expand the simple Wasp design from last time and start designing new modules. Specifically, I’ll add a Control Signal Generator, an Address Counter, and a Buffer.