Lab 5: Introduction to

Logic Simulation and

Verilog
Max Klemp
ECEN 248 - 517
TA: Javed Ali
Date: October 1, 2020
Objectives:
The objectives of this lab was to introduce Verilog and circuit design using verilog code.
This allows us to create much more complicated circuits than we would have been able to make
on a simple breadboard with physical ICs and wires. The limitation of space and size is no longer
an issue when digitally recreating the same design in Vivado.
Designs:
In this lab we are recreating the designs we had created earlier in other labs just using
verilog. We begin by designing a simple 2:1 MUX; the module takes three inputs, A, B and S
and outputs the result.

After implementing the 2:1 MUX the 4 bit version is the same as “calling” the module
from the 2:1 MUX verilog code to find the 4 bit outputs for A0,A1,A2,A3 and B0,B1,B2,B3 and
S. It is the same as the 2:1 MUX for the 0,1,2, and 3 for both A and B.

The next part of the experiment has us make a full adder. This module takes 3 inputs and
outputs a result and an overflow. In verilog the intermediate wires need to be declared as andAB,
andACin, andBCin. In verilog the code just assigns the boolean values to each value.
 The next implementation we need to create the ALU in verilog is to create the Add/Sub
that we used in lab 4. This uses 4 full adders as well as some XOR gates. This outputs the sum or
difference depending on the input of the ninth input.

After all of these modules have been implemented the final ALU design can be made
from the combination of the modules to make the final design. The final verilog code has uses
the implementation of the add/sub module and 4 bit MUX module only once and also uses the
intermediate wires to find the AND of the A and B inputs.

Results:
The results of the final ALU design cannot be tested the same as we test ALU on the
breadboard. The verilog version requires a test case to be loaded and tested for each of the
modules created, the 2:1 MUX, the 4 bit MUX, the Adder, the Add-Sub, and finally the ALU
design. These test cases are called test bench codes and are given to us and after implementing
them a terminal outputs if the test cases are passed or not. When the test benches are run a
waveform diagram is made signifying the different outputs and functions during the
implementation of the design. There is a line for each input and it is either 0 or 1 in the diagram.
When it is high the line is at the top and at the bottom when the line is low. The more
complicated the design the more complex the waveform. The waveform also tracks the time for
the implementation and the time is the dependent variable. All the test cases passed as expected
and a complicated waveform diagram was outputted for the final ALU.

Here the final ALU design test bench code passed all the tests.
Conclusion:
In conclusion the final ALU design outputs the correct outputs and given the test bench
case we can see that all tests have been passed meaning it must be a fully functioning design for
an ALU. For every design the test cases have been passed and the designs are modeled after the
ones we created in earlier labs meaning that the logic is sound and implementation in verilog was
successful. This lab was fairly simple to understand and was useful to introduce verilog using
circuits that we have already used to create something we would understand.
Questions:
1. Include the source code with comments for all modules you simulated. You do not have to
include test bench code. Code without comments will not be accepted! If the last 4 digits of your
UIN cannot be found in your verilog code, you will not receive any point for that design.

Test code will be attached in submission file in a .pdf

2. Include screenshots of all waveforms captured during simulation in addition to the test bench
console output for each test bench simulation.

2:1 Mux
4 bit MUX

Full Adder:
Add-Sub:

4 bit ALU:
3. Examine the 1-bit, 2:1 MUX test bench code. Attempt to understand what is going on in the
code. The test bench is written using behavioral Verilog, which will read much like a
programming language. Explain briefly what it is the test bench is doing.

The test bench for the 2:1 MUX is using assignments and boolean logic to apply known
solutions and assert certain inputs and test if the code you created has the same value as
the known result for the specific inputs.

4. Examine the 4-bit, 2:1 MUX test bench code. Are all of the possible input cases being tested?
Why or why not?

Not all the possible test cases are being tested because the test bench code only tests 16
cases but with 3 inputs for each of the 4 2:1 MUX with the option of being 0 or 1 for all
three inputs means there are at least 24 total cases.

5. In this lab, we approached circuit design in a different way compared to previous labs.
Compare and contrast bread-boarding techniques with circuit simulation. Discuss the advantages
and disadvantages of both. Which do you prefer? Similarly, provide some insight as to why
HDLs might be preferred over schematics for circuit representation. Are there any disadvantages
to describing a circuit using an HDL compared to a schematic? Again, which would you prefer.

The verilog approach to circuit design was much different, it was easier in some ways as
you didn’t have to physically attach things on a board. Certain things like limited space
and the small details that would cause a circuit to “fail” like a wire not pushed far enough
down into a breadboard and other similar issues. An advantage of the breadboard
technique however was that I felt like I was understanding the actual circuit paths when I
built them myself. This was true until I had bugs then breadboarding became very
frustrating especially when it was a busy circuit design. An advantage of Verilog is that it
is much faster and errors are displayed to you in the code. I would have to prefer Verilog
however because it is much more manageable than all the components and hassle of bug
fixing on a breadboard.

HDLs might be preferred over schematics for a circuit because the bigger the circuit gets
the more complicated and dense a schematic can be. The gate level circuit design for the
 ALU was massive and complicated to read. However a simple code that explains in detail
through commented code or modules is easier to follow for large builds. A disadvantage
however would be the lack of overall scope of the design perhaps? Still though I would
prefer HDL over a large circuit schematic to better comprehend the design.

6. Two different levels of abstraction were introduced in this lab, namely structural and dataflow.
Provide a comparison of these approaches. When might you use one over the other?

Structural abstraction is something we are more used to like using functions in coding
python or c++. These data types call a module in verilog and can be called to
significantly reduce the amount of raw coding or assigning and defining wires. Dataflow
is more about using higher language coding to manipulate outputs without calling a
module using something like “always” in verilog. Structural is much more like building a
circuit using parts. Dataflow is more like telling the program the steps without using the
framework of gates. Dataflow is useful when gate logic is complicated or unintuitive,
whereas Structural is nice for describing a circuit we have already made using gates so
we can understand the process better.

1. What did you like most about the lab assignment and why? What did you like least about it
and why?

I liked that the implementation of the circuit in verilog was fairly intuitive and supplied
errors if there was a small mistake unlike when building the circuit by hand, where a
small mistake could not be caught and become a problem that’s hard to find. The thing I
liked least about verilog was the amount of abstraction takes away from grasping at what
the physical circuit would be implemented in the real world.

2. Were there any sections of the lab manual that were unclear? If so, what was unclear? Do you
have any suggestions for improving the clarity?

The lab manual was VERY clear this week as it was basically an instruction manual until
the last module. Helpful as it was the first time using verilog code. Nothing was really
left out. No need for improvement really.

3. What suggestions do you have to improve the overall lab assignment?

An improvement that could be made would be to introduce an easy concept that we have
made in actual circuits to try and implement logic for something that we don’t have
firsthand knowledge about to test our understanding of verilog abstraction and the
process of turning a circuit idea into working code.