Unit 1g
Testing the ALU
Creating a Test Bench
Given the complexity of large scale digital designs, it is estimated that more the 50% of the total design time for a new device is spent on testing and validation. Just think a little about the way you have tested your designs so far. You created a script file with a set of cases representing each function that you wanted to test, you ran the script and then looked at the output data to manually verify that the actual output was what you expected. Some of those script files were fairly long, yet they typically tested only one case for each of the functions that you wanted to test. What if you wanted to test every possible case? For addition, this would mean testing 2**128 input combinations, a seriously long script file. If each of these cases took 1 microsecond of simulation time, the adder test would run for approximately 10**29 years? (by comparison the age of the sun is about 4.5 x 10**9 years). Obviously we need a different approach.
Instead of thinking of testing on a case-by-case basis let’s think about testing as validating the behavior of the circuit. For example instead of testing if the addition function works by asking if 2+2=4, let’s make an assertion about the relationship between the inputs and the outputs. For example as ASSERTION about an adder would test the PROPERTY, A+B = R. In the context of testing, an ASSERTION is a statement about the expected behavior (called a PROPERTY) of the circuit.
Assertions can take many forms. They can test properties that must always hold, or never hold. For example
Assert NEVER, Property ALUop = “1000” ---- Since 1000 is an unassigned operation code.
Assertions can test relationships between multiple inputs and outputs
Assert IMPLICATION Property WHEN ALUop = 0011 THEN R = A+B.
Assertions are most powerful for test timing and sequence relationships (although these will not be useful for testing your ALU, we will see this in detail in the memory bus unit)
Assert SEQUENCE Property A,B,C
There are several languages and commercial tools for generating, writing, and testing assertions. Most of these are beyond the scope of this class. To implement assertions in HDL designer, you will use a special library called the OPEN VERIFICATION LIBRARY, the implements a set of VHDL block that can test a set of standard properties defined for the electronics design automation industry. We have implemented this library as HLD designer blocks and stored then in a library call COE1502_OVL. You should map this library into your project at I:\1502\COE1502_OVL. If you don’t remember how to do this refer to the earlier unit where you mapped the COElib. Once mapped, open the library by clicking on the library name in the project manager. If the library is properly mapped you should see the following.
Each of the components in
this library is designed to test the validity of a particular property in
either a spatial (one or more signals at the same time) or temporal (one or
more signals in time sequence) context. To find out how each one works, go to
the course web page under the reference heading and click on Open Verification
Library Documentation
If you’re confused, don’t worry. You will only use two or three types of assertion blocks for this unit. Take a quick look at the documentation for assert_always, assert_never, and assert_implication. Notice that each of these has inputs for clock, reset, and (one or more) test_expr. You can ignore clock and reset for now. These are std_logic signal inputs that define the timing of each test case. The text_expr input is of type boolean and thus may only take on the value TRUE or FALSE. To built and assertion that tests a particular property that describes your ALU, you will need to write out a VHDL concurrent assignment statement (in an embedded block) that represents the property to be tested. As an example, here is a statement that tests the addition property and sets test_expr to a Boolean, test_expr based on where the result, R, is the sum of A and B..
test_expr <= R=(A+B);
With the property coded this way, test_expr is now the input of the assertion block. Notice that the addition operation in the property statement uses the internal addition function built into VHDL. This is a behavioral model and has no particular mapping to hardware, which is exactly what we want. Putting all of this together in a block diagram view, our example looks like figure 1 below. In modelsim, this design will print a user defined message any time the clock is rising and A+B does not equal R.
Figure
1
Don’t try to implement this right now. First, we will learn a structured way of defining your property assertions and putting them all together called a test bench.