Testing like a Pro

We are now using XCFE in Aeste, probably because it’s supposed to be a “light” desktop environment. However, I didn’t fancy it’s looks and absence of keyboard shortcuts similar to Ubuntu. Hence I took some time to make my desktop environment usable and setup some keyboard shortcuts. You can find out how to setup shortcuts from here. Here is a list of the ones that I set and their command names

Applications Menu /usr/bin/xfce4-popup-applicationsmenu
Take a screenshot xfce4-screenshooter -f
Open a terminal xfce4-terminal

First task was to arrange the file locations. Simply, instead of being rtl/module_name/verilog it’s better to make it rtl/verilog/module_name I discovered some sweet hacks in the process. The best of which is that, using git, to move all content of a folder into another folder you simply need to use a magical * character to refer to all files in a folder. For example the following command moves all git tracked files in verilog directory one level up in the folder hierarchy: git mv verilog/* .

Next task is to change all test benches of IO devices into Automated Test Benches, This means that the test bench will verify the behavior of the core instead of just dumping the waveform and the user verifying it.

Testing verifies two things. First that the core is behaving as expected within it’s design specifications. Second is that the core will not function properly outside of it’s intended design specs.

In the following I will list down some basic guidelines for testing to be considered comprehensive and thorough:

• Test each functionality several times. Even though it is essentially the same test but repeating it several times mimics the behavior of the actual device which will be doing the same things over and over again. Moreover, it helps eliminate possible errors that might not be discovered from a single run. For example, the device may work only for the first time because of a certain set of initial conditions but it fails when those conditions are absent. Other than that, the design might have some circuitry that is not properly cleared after each task.

• Test every single aspect of the device. If the device has a bus with a variable width you need to test each possible width. If the device have control signals that can take several values you need to verify every allowed combination.

• Use Random Values, especially for data buses since in run time those buses can carry any data value that the design has no control over it.

• Make your Test Bench generic. Use parameters to be able to tweak different aspects that can allow it to test many designs. This includes register addresses and internal control signals values which are normally dependent on the designer’s choice and don’t affect the actual behavior of the device.

In the next blog I’ll explain how I Implemented those features on the GPIO test bench and explain two possible ways to do it.