| Assignment #4 Problem Statement |
This laboratory assignment requires you to develop a testbench for the Verilog model you developed in the Laboratory Assignment #3. Your testbench will provide the following stimuli to test the designed up/down counter. You will need to modify your model of the previous assignment. You will remove the clock-divider sub-module which divides the 12 MHz clock to 1 Hz clock. It should read a testvector file called test.vec from the current directory and generate the stimuli. The testvector file (binary, not hex) will include the AIN input, number of complete cycles you want to simulate for the given AIN and the expected 7-segment output. The testbench will compare the output with the expected out and will display whether there was a match or mismatch and also write to a file called "mod.out." For each new AIN the testbench should also display (and write) appropriate message.
The test input combinations appearing in the order of test are tabulated below.
| AIN | DIRECTION | # of cycles | COMMENT |
| 000 | No count | 2 | Hold the counter at 5 (display 5) |
| 010 | UP from 3 to B every alternate | 4 | Up counter skipping even numbers |
| 001 | UP from 1 to 9 | 3 | Up counter |
| 011 | UP from 2 to E every alternate | 1 | Up counter skipping odd numbers |
| 010 | UP from 3 to B every alternate | 5 | Up counter skipping even numbers |
| 011 | UP from 2 to E every alternate | 2 | Up counter skipping odd numbers |
| 100 | Down from F to 3 | 3 | Down counter |
| 101 | Down from 9 to 1 every alternate | 5 | Down counter skipping even numbers |
| 110 | Down from C to 0 every alternate | 4 | Down counter skipping odd numbers |
| 001 | UP from 1 to 9 | 3 | Up counter |
| 101 | Down from 9 to 1 every alternate | 2 | Down counter skipping even numbers |
| 111 | Down counter | 1 | Plain down counter |
Lab 4 Report Introduction This laboratory assignment consists of a testbench for a Verilog model for an up/down counter from the previous laboratory assignment. The testbench will provide all the necessary stimuli to test the designed up/down counter. The testbench module will read a testvector file called test.vec from a current directory and generate the stimuli. The stimuli include a forever clock pulse, the AIN control signal, the reset, and the number of cycle. The testbench also creates an output file called mod.out. It will display whether there was a match or mismatch between the expected 7-segment output and the actual 7-segment output. The tested bitstream is listed in the order of {I2,I1,I0,nclr,cycle,S0E,S1E,S2E,S3E,S4E,S5E,S6E} where (I2,I1,I0) is the input control signal, nclr is the reset, cycle is the number of complete cycles, and the remaining variables are the expected 7-segment output. The tested input combinations appearing in the order of test are tabulated below:
Approach The top level module is the testbench module. It contains the instantiation of the counter and two initial procedures in which it will generate the input’s stimuli to test the designed up/down counter. The first initial behavior contains a forever keyword that uses to generate the clock pulses. The second initial behavior is used to fetch the input data from the test.vec file and also open and write the result of analysis to the output file called mod.out. It also contains the nested for loop that will check whether there was a match or mismatch between the bitstream and its output. Procedure Write the top level module with the instantiation of the up/down counter (see attachments). Create an input bitstream file so that the testbench module will be read. Compile the code, load the file, and run it. The output will be displayed on the screen and/or in the mod.out depend on the specified of the task command $display or $fdisplay, respectively. Analysis The crucial task of writing this testbench is knowing where to the place the necessary delay so that the input bitstream can be fetched correctly. The first delay is placed right before the counter enters the loop. This delay will give the counter time to initiate. The second crucial delay is placed right before the counter exits its innermost "for loop." This delay allows the counter to update its state so that new data can be compared. Moreover, it is obvious but worth to mention that this testbench’s module contains initial behaviors in which it can only be executed once. Because after spending several hours of wondering over why the second cycle never comes around, you will not forget that initial statement is not a cyclic. Feature Identification The most frustrating part of this laboratory assignment is trying to debug the code. It is not easy trying to figure out why the expected 7-segment doesn’t match with the actual output. However, a nice feature called $time system task will reduce a substantial amount of time and agony. The $time system task will help the designer to analyze the data by displaying the simulation time along with its output so that the designer knows where they are in the simulation. Conclusion After endless attempt trying to simulate the testbench using the previous up/down counter design that result to invalid output, we were forced to design a new up/down counter. The result showed that the new counter design work. The different between the two the designs is that the first one is an explicit approach and the other one an implicit approach. According to the written testbench, the testbench seems to work better with the implicit description over the explicit description. The explicit counter design either has problem with loading or it would not run at all. We can only presume that the size of the explicit description causes these problems. |