Section 5: Verilog Combinational RTL Design
In the past discussion sections, we have learned how to model hardware at the gate-level (GL). In this discussion section, you will learn a new approach to modeling hardware using Verilog at the register-transfer level (RTL). By the end of this discussion section, you will have explored both a GL and RTL implementation of an absolute difference unit. RTL modules are usually implemented at a much higher level of abstraction compared to GL models. This improves designer productivity and gives the FPGA tools more flexibility in optimizing the final hardware, but it also means the designer might not fully understand the final hardware and has less control over the details of the final hardware. This is a key trade-off we will need to balance carefully when using RTL modeling. It is also possible to write RTL models that cannot map to any kind of reasonable hardware. It is critical that students always know what is the hardware they are modeling whether they are working at the gate- or register-transfer level.
1. Logging Into ecelinux with VS Code
We have drastically simplified the process of logging into ecelinux
with VS Code using the workstations. Find a free workstation and log into
the workstation using your NetID and standard NetID password. Then
complete the following steps:
- Open the ECE 2300 folder on the desktop to locate two shortcuts
- ECE 2300 Handouts: opens the handouts page
- ECE 2300 VS Code: starts VS Code (enter server number and password)
That is it! Our custom ECE 2300 VS Code script will take care of:
- installing Remote SSH, Verilog HDL, Surfer extensions
- configuring SSH for accessing
ecelinuxwithout extra prompts - starting VS Code connected to
ecelinuxwithout extra prompts - opening the file explorer in your
${HOME}/ece2300directory - installing the Verilog HDL extension on the server
- opening a terminal
There is no need to fork the repo for today's discussion section. Simply clone the repo as follows.
% source setup-ece2300.sh
% mkdir -p ${HOME}/ece2300
% cd ${HOME}/ece2300
% git clone git@github.com:cornell-ece2300/ece2300-sec05-verilog-rtl sec05
% cd sec05
% tree
The repo includes the following files:
Makefile.in: Makefile for the build systemconfigure: Configure script for the build systemconfigure.ac: Used to generate the configure scriptscripts: Scripts used by the build systemece2300: ECE 2300 unit testing library and miscellaneous macrosabsdiff/absdiff.mk: Tells build system about files in this subprojectabsdiff/FullSubtractor_GL.v: One-bit full subtractor at gate levelabsdiff/SubtractorRippleCarry_4b_GL.v: Four-bit ripple-carry subtractor at gate levelabsdiff/GTComparator_1b_GL.v: One-bit greater-than comparator at gate levelabsdiff/GTComparator_4b_GL.v: Four-bit greater-than comparator at gate levelabsdiff/Mux2_1b_GL.v: One-bit two-to-one multiplexor at gate levelabsdiff/Mux2_4b_GL.v: Four-bit two-to-one multiplexor at gate levelabsdiff/AbsDiff_4b_GL.v: Absolute difference unit at gate levelabsdiff/Subtractor_4b_RTL.v: Four-bit subtractor at register-transfer levelabsdiff/GTComparator_4b_RTL.v: Four-bit greater-than comparator at register-transfer levelabsdiff/Mux2_4b_RTL.v: Four-bit two-to-one multiplexor at register-transfer levelabsdiff/AbsDiff_4b_RTL.v: Absolute difference unit at register-transfer levelabsdiff/test: Directory with unit tests for each hardware module
Go ahead and create a build directory, run configure to generate a Makefile, and run the tests.
To make it easier to cut-and-paste commands from this handout onto the
command line, you can tell Bash to ignore the % character using the
following command:
Now you can cut-and-paste a sequence of commands from this tutorial
document and Bash will not get confused by the % character which begins
each line.
Throughout this handout you will see discussion check-off tasks. The TAs will not be assessing your understanding. Instead, students should show their work to another student and then together they will perform a self and peer assessment of each discussion check-off task. The student peer will initial the check-off. As always, the assesssment should based on the demonstrated understanding using our five-point scale as follows:
-
5 (Mastery): Student mastered the check-off without any help and feels very confident in their understanding; student could teach other students about the corresponding concepts
-
4 (Accomplished): Student accomplished the check-off with maybe a little help and feels good about their understanding, but could probably use a little more time to really master their understanding; student is probably not quite ready to teach other students about the corresponding concepts
-
3 (Progressing): Student completed the check-off but needed significant help; student is not quite confident in their understanding and needs more time to really improve their understanding of the corresponding concepts
-
2 (Beginning): Student started but did not finish the check-off
The goal is not for one student to judge another student, but for the two students to agree on the demonstrated level of understanding. There is nothing wrong with agreeing on a 4 or 3. This can help a student crystallize where they should focus their time to improve the understanding!
Near the end of the discussion section, the student should raise their hand and show their overall progress to a TA who will initial and collect the check-off sheet.
Discussion section check-off sheets are not graded!
Unlike the lab check-off sheets, the discussion check-off sheets are not graded. They will not impact your grade in the course in any way. The discussion check-off sheets provide formative self and peer assessment. They enable students to gauge their progress in mastering the concepts presented in the discussion section, and enable the instructors to get an overall feel for how the class is doing. Please make sure your self and peer assessments are honest and accurate!
Discussion Check-Off Task 1: Verify Initial Release
We always start by running make check to get a high-level view of
what is and is not working. So go ahead and do make check again and
look closely at what tests are passing and what tests are failing.
Show a peer student the result of make check. Work together to
conduct a self and peer assessment and have the peer student initial
the check-off.
2. Absolute Difference Unit Interface
We will be implementing an absolute difference unit using both GL and RTL modeling. Both implementations will have similar interfaces. The GL interface is as follows:
module AbsDiff_4b_GL
(
(* keep=1 *) input wire [3:0] in0,
(* keep=1 *) input wire [3:0] in1,
(* keep=1 *) output wire [3:0] diff
);
The RTL interface as the same ports and bitwidths, except instead of
declaring these ports as wire we declare them with logic. In RTL
modeling, we will always use logic for both ports and internal signals.
module AbsDiff_4b_RTL
(
(* keep=1 *) input logic [3:0] in0,
(* keep=1 *) input logic [3:0] in1,
(* keep=1 *) output logic [3:0] diff
);
The absolute difference unit takes as input two four-bit unsigned binary
numbers and outputs the corresponding absolute difference on the diff
output port.
3. Gate-Level Implementation of Absolute Difference Unit
We have provided you a gate-level implementation of an absolute difference unit in these files:
absdiff/FullSubtractor_GL.vabsdiff/SubtractorRippleCarry_4b_GL.vabsdiff/GTComparator_1b_GL.vabsdiff/GTComparator_4b_GL.vabsdiff/Mux2_1b_GL.vabsdiff/Mux2_4b_GL.vabsdiff/AbsDiff_4b_GL.v
Spend some time looking through and trying to understand the provided gate-level implementation.
Discussion Check-Off Task 2: Draw Block Diagram of GL Implementation
The best way to demonstrate your understanding of hardware is to draw
a detailed block diagram of how all of the blocks are instantiated
and connected. Work alone or with a partner to create a block drawing
of the provided gate-level implementation. Use a top-down approach
(i.e., start from the AbsDiff_4b_GL module and work down to the
logic gates in the FullSubtractor_GL, GTComparator_1b_GL, and
Mux2_1b_GL modules). You must be able to point to the actual AND,
OR, NOT, etc gates in your diagram. You can either work alone and
show a peer student your block diagram, or you can work together with
another student on a single block diagram. Once done complete a self
and peer asssessment and have the peer student initial the check-off.
4. RTL Implementation of Building Blocks
In this section, we will experiment with RTL implementations of the key building blocks that make-up the absolute difference unit: a four-bit greater-than comparator, a four-bit subtractor, and a four-bit two-to-one multiplexor.
4.1. RTL Implementation of Four-Bit Subtractor
In Verilog GL modeling, we must explicitly instantiate gates. When
writing Verilog Boolean equations, we can use the assign statement
along with a limited number of operators (i.e., ~, &, |, ^). The
most basic form of RTL modeling simply enables designers to use more
complex operators in an assign statement.
Open the Subtractor_4b_RTL.v file and implement the subtractor using
RTL modeling with the - operator. Run all of the provide tests to
verify your implementation.
Notice how simple the RTL implementation is compared to the GL implementation. An RTL implementation enables the designer to express the subtractor at a very high level, and then trust that the FPGA tools will be able to choose an appropriate subtractor hardware implementation. Of course the downside is the designer has less control over what specific subtractor hardware implementation is actually used on the FPGA.
Discussion Check-Off Task 3: Verify RTL Subtractor
Show a peer student your implementation for the RTL four-bit
subtractor. As always make sure you have removed the
ECE2300_UNUSED, ECE2300_FLOATING, and ACTIVITY comment. Then
show the peer student how the same test cases are used to test both
the GL and the RTL four-bit subtractor (i.e., show the student where
the includes are which include the test case file). Show the peer
student your implementation passing all of the provided tests. Do not
just run make check. You must run just the test bench for the
subtractor on its own. Finally, show the peer student how you can run
just the random test case on its own. Once done complete a self and
peer asssessment and have the peer student initial the check-off.
4.2. RTL Implementation of Four-Bit Greater-Than Comparator
An RTL model of the greater-than comparator can use the RTL > operator.
Open the GTComparator_4b_RTL.v file and implement the comparator using
the > operator in an assign statement. Run all of the provided tests
to verify your implementation.
Discussion Check-Off Task 4: Verify RTL Greater-Than Comparator
Show a peer student your implementation for the RTL four-bit
greater-than comparator. As always make sure you have removed the
ECE2300_UNUSED, ECE2300_FLOATING, and ACTIVITY comment. Then
show your design passing all the tests. For this check-off use make
check so you can get a high-level view of your progress so far. Once
done complete a self and peer asssessment and have the peer student
initial the check-off.
4.3. RTL Implementation of Four-Bit Two-to-One Multiplexor
An RTL model of a multiplexors can use the ternary operator. Open the
Mux2_4b_RTL.v file and implement the multiplexor using the ternary
operator in an assign statement. Ask your peer student if you do not
recall what the ternary operator is. Run all of the provide tests to
verify your implementation.
Then zoom in and generate the waveforms for the directed test case before viewing them using Surfer.
% cd ${HOME}/ece2300/sec05/build
% ./Mux2_4b_RTL-test +test-case=2 +dump-vcd=waves.vcd
% code waves.vcd
Discussion Check-Off Task 5: Verify RTL Multiplexor
Show a peer student your implementation for the RTL four-bit
greater-than comparator. As always make sure you have removed the
ECE2300_UNUSED, ECE2300_FLOATING, and ACTIVITY comment. Then
show your design passing all the tests by running just the
Mux2_4b_RTL-test test bench. Then show the peer student your
waveforms. Display all inputs and outputs of the mux and explain how
the mux works using the waveforms. Once done complete a self and peer
asssessment and have the peer student initial the check-off.
5. RTL Implementation of Absolute Difference Unit
Now that we have RTL models of our building blocks, we can create an RTL model for the entire absolute difference unit. We will explore both a structural and flat implementation.
5.1. Structural RTL Model
Let's start with a structural RTL model. Open AbsDiff_4b_GL.v and
copy the structural implementation into AbsDiff_4b_RTL.v. Change the
building blocks to all be the RTL implementation. Then rerun all the
tests to verify that your structural RTL modeling is functionally
correct.
Notice how structural RTL modeling like this provides a nice balance between productive modeling and control over the hardware implementation. We can let the FPGA tools optimize each building block individually, but we still get explicit control over how these building blocks are composed.
Discussion Check-Off Task 6: Verify Structural RTL Implementation
Show a peer student your implementation for the structural RTL
absolute different unit. Then show your design passing all the tests
by just running the ./AbsDiff_4b_RTL-test. Once done complete a
self and peer asssessment and have the peer student initial the
check-off.
5.2. Flat RTL Model
We can also use a flat RTL model which does not instantiate any
building blocks at all, but instead directly use assign statements to
model the entire absolute difference unit. Open AbsDiff_4b_RTL.v and
remove your structural RTL implement. See if you can implement the
absolute difference unit in a single line using a combination of a RTL
ternary and subtraction operators. Then rerun all the tests to verify
that your flat RTL modeling is functionally correct.
Notice how flat RTL modeling enables the designer to express their intent at a very high level, but the designer now has very little control over the final hardware implementation. Not only will the FPGA tools optimize the building blocks, but hopefully the FPGA tools will realize an implementation only needs a single subtractor. When using flat RTL modeling we have lost much of the intuition about the hardware implementation that was so explicit in our GL modeling and still somewhat present in our structural RTL modeling. Students will need to carefully navigate the tension between productivity and control when developing gate-level models, boolean equation models, structural RTL models, and flat RTL models.
Discussion Check-Off Task 7: Verify Flat RTL Implementation
Show a peer student your implementation for the flat RTL absolute
different unit. Then show your design passing all the tests by just
running the ./AbsDiff_4b_RTL-test. Discuss with the peer student
the trade-off between flat RTL modeling, structural RTL modeling, and
GL modeling. Once done complete a self and peer asssessment and have
the peer student initial the check-off.
6. Clean Build
As a final step, do a clean build to verify everything is working correctly.