Laboratory Experiment #8:
Arithmetic-Logic Unit Modeling
Ari Mahpour
ECE 526 Lab
Student ID #: 101146706
Table of Contents
Purpose....................................................................................... 3
Test Strategy ............................................................................... 4
Results ........................................................................................ 5
Conclusion .................................................................................. 5
Waveform Diagram .................................................................... 6
Purpose
The purpose of this lab was to design and implement an arithmetic logic unit into a
purposeful Verilog module. The arithmetic logic unit performs a series of calculations integral to
the functionality of the central processing unit. Whether it be a simple math function of data
storage, the arithmetic logic unit will perform it all. A three bit input, known as the operational
code (opcode), triggers the operation based on a number. For example, an input of 101 will
pass the data bus contents to the output. A total of eight opcodes can be used in the this
particular arithmetic logic unit. Other inputs consist of a carry in bit, a clock, the accumulator
eight bits), and the data itself (eight bits).
In this implementation, a simple case statement did the job. It would treat each opcode
as a case and perform whatever function that specific opcode designated. In addition, other
one bit outputs had to be evaluated. These included a carry flag, overflow flag, sign flag, zero
flag, and parity flag. After performing a function in the arithmetic logic unit, each of these one
bit outputs would hold a value corresponding to the data that was processed (via the
designated opcode).
Test Strategy
The test vectors in this laboratory experiment were targeted to test the functionality of
the arithmetic logic unit and ensure that all of its functions performed correctly. In the test
bench itself, a clock was generated and each operation was tested individually on the clock. The
case statement is only evaluated at the positive edge of the clock therefore it was imperative
that the timing of the simulations would run simultaneously. Rather than setting each function
to run at every edge of the clock (i.e. 20 ns clock frequency), the clock would have a period of 2
nanoseconds and each function would be evaluated at every 10 nanoseconds.
Throughout the process of running through each opcode, various outputs had to be
observed such as the carry, overflow, sign, zero, and parity flag. Each one of the one-bit outputs
could have had potentially different values at each individual operational states, therefore,
each bit was observed using the “$monitor” function in the test bench. Also, documented int eh
test bench are points where certain flags are anticipated to turn on (in which results will be
discussed in the next section).
Results
The results for the test strategy came out to be a success. When performing each function, the
necessary flags had turned on (or off) and each function was performed without any issues. Wehtehr it
was simply passing data, adding values, or running each bit of a data input through a primitive gate,
each function proved to be a success. For this laboratory exercise, both the LOG file and the output
waveform do justice to what the outputs should look like. The output value (known in the module as
alu_out) was displayed as “OUT” simply for aesthetic purposes. Just as the data loaded was in
hexadecimal form, so too the output was represented in the hexadecimal form. Both the output LOG file
and waveform vector file can be viewed at the end of this laboratory report.
Conclusion
In the laboratory experiment we explored a very important concept that was clearly
applied to the computer architecture world. The concept of case statements proved to work
quite well in this particular implementation of the arithmetic logic unit. No other behavioral
design (at least that in which we learned thus far) would have been as efficient and worked as
well as the case statement. In the hardware implementation, this can work as a switcher, more
commonly known as a multiplexer. As seen in many circuit descriptions, multiplexers are an
essential part of any logic circuit. Without them, digital design would be much more difficult.
After learning about the arithmetic logic unit we move onto the next lab which is the final piece
to the digital design of the central processing unit.
Waveform Diagram
I hereby attest that this lab report is entirely my own work. I
have not copied either code or text from anyone, nor have I
allowed or will allow anyone to copy my work.
Name (printed): ______________________________________
Name (signed): ______________________________________
Date:
___________________