Section 6: Lab 3 Head Start
In this discussion section you will get started on Lab 3, implementing a D latch, D flip-flop, and D flip-flop with reset. You will implement all of these (except the D latch) two ways: first using gate-level modeling and then using register-transfer-level modeling. Feel free to copy code from this discussion section into your lab group repo.
Previously, we focused on how to use Verilog to model combinational logic at both the gate-level and register-transfer-level (RTL). Today we will learn how to use Verilog to model sequential logic. Gate-level modeling of sequential logic largely uses similar syntax and semantics to gate-level modeling of combinational logic. RTL modeling of sequential logic requires new syntax and semantics which we need to understand and use carefully. It is critical that students always know what hardware they are modeling and 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. Simple clone the repo as follows.
% source setup-ece2300.sh
% mkdir -p ${HOME}/ece2300
% cd ${HOME}/ece2300
% git clone git@github.com:cornell-ece2300/ece2300-sec06-lab3-head-start sec06
% cd sec06
% 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 macroslab3/DLatch_GL.v: 1-bit D latch at gate-levellab3/DFF_GL.v: 1-bit D flip-flop at gate-levellab3/DFF_RTL.v: 1-bit D flip-flop at RTLlab3/DFFR_GL.v: 1-bit D flip-flop with reset at gate-levellab3/DFFR_RTL.v: 1-bit D flip-flop with reset at RTLlab3/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. D Latch
We will start by exploring how to implement a D latch which has a data
input (d) and a clock input (clk) and one output (q). Here is the
gate-level implementation of a DLatch shown in lecture.
A D latch is transparent when the clock is one (i.e., the input passes directly to the output) and is opaque with the clock is zero (i.e., the latch "remembers" the value right before the clock transitioned to zero and holds this value while the latch is opaque).
We have provided you the interface a D latch in DLatch_GL.v and a test
bench in DLatch_GL-test.v. For the test bench, we have provided you a
template for an exhaustive test case; all you need to do is fill in the
correct output values for each provided check. Notice that our checks
look exactly like an explicit-clock simulation table we discussed
lecture. You can test the D latch as follows.
Once your design is passing all your tests generate waveforms and take a look using Surfer.
% cd ${HOME}/ece2300/sec06/build
% ./DLatch_GL-test +test-case=2 +dump-vcd=waves-dlatch.vcd
% code waves-dlatch.vcd
Discussion Check-Off Task 2: Verify D Latch
Show a peer student your implementation for the gate-level D latch. Compare your exhaustive test case with the peer student's test case and discuss any discrepancies. Then show a peer student your waveforms and discuss how the waveforms illustrate memory. Identify exactly where in the waveforms the D latch is "holding a previous value" (i.e., "remembering).
3. D Flip-Flop
A D flip-flop has a data input (d) and a clock input (clk) and one
output (q). Here is the gate-level implementation of a D flop-flop
shown in lecture.
Unlike a D latch, a D flip-flop is never transparent. A D flip-flop samples its input right before the positive edge of the clock and then holds this value for the entire clock period until the next rising edge. We can implement a D flip-flop with two latches: a leader latch and a follower latch. The leader latch uses the complement of the clock so that only one latch is ever transparent on either phase of the clock.
We have provided you the interface a D flip-flop in DFF_GL.v, a test
bench in DFF_GL-test.v, and test cases in DFF-test-cases.v. Go ahead
and implement this module. For the test cases, we have provided you a
template for directed test cases; all you need to do is fill in the
correct output values for each provided check. You can test the D
flip-flop as follows.
We can also use RTL modeling to implement a D flip-flop. We will need to
use an always_ff block, a new Verilog construct specifically design for
RTL modeling of sequential logic. Here is an example of how to use such
an always_ff block.
module DFF_RTL
(
input logic clk,
input logic d,
output logic q
);
always_ff @( posedge clk ) begin
q <= d;
end
endmodule
An always_comb block executes whenever any of the inputs to that block
change. An always_ff @(posedge clk) block only executes on the rising
edge of the clock. Notice how we are using a non-block assignment (<=)
instead of a blocking assignment (=). A non-block assignment has very
different semantics to a blocking assignment. In a non-blocking
assignment, the right-hand side (i.e., d) is evaluated and saved
before the rising clock edge and the left-hand side (i.e., q) is only
updated after the rising clock edge. Critically, the right-hand side is
evaluated and saved in every always_ff across the entire hardware
design before updating any left-hand side. This effectively models all
of these assignments happening concurrently on the rising edge of the
clock which is exactly what happens in hardware. We should only use
non-blocking assignments in always_ff blocks, and we should only use
blocking assignments in always_comb blocks. We should never mix these
up!
We have provided you the interface a D flip-flop in DFF_RTL.v and a
test bench in DFF_RTL-test.v. Go ahead and implement this module. The
test bench includes the same test cases you developed for the gate-level
implementation, so you should be able to go ahead and test the D
flip-flop as follows.
Once your design is passing all your tests generate waveforms and take a look using Surfer.
% cd ${HOME}/ece2300/sec06/build
% ./DFF_RTL-test +test-case=2 +dump-vcd=waves-dff.vcd
% code waves-dff.vcd
Discussion Check-Off Task 3: Verify D Flip-Flop
Show a peer student your implementation for the gate-level and RTL D
flip-flop. Compare your exhaustive test case with the peer student's
test case and discuss any discrepancies. Then show a peer student
your waveforms and discuss how the waveforms illustrate memory.
Identify exactly where in the waveforms the D flip-flop is "holding a
previous value" (i.e., "remembering). Discuss with the peer student
what the non-blocking assignment (<=) does and how it is different
from the continous assignment (=) we use with assign statements.
4. D Flip-Flop w/ Reset
We can add a reset (rst) to our D flip-flop. Here is the gate-level
implementation of a D flop-flop with reset shown in lecture.
The reset signal is used to reset the D flip-flop to a known value. In
our case we will reset the flip-flop to zero. To implement a D flip-flop
with reset, you will need to instantiate a DFF_GL and then add an AND
gate and NOT gate as shown in lecture.
We have provided you the interface a D flip-flop with reset in
DFFR_GL.v, a test bench in DFFR_GL-test.v, and test cases in
DFFR-test-cases.v. Go ahead and implement this module. For the test
cases, we have provided you a template for directed test cases; all you
need to do is fill in the correct output values for each provided check.
You can test the D flip-flop with reset as follows.
To implement a D flip-flop with reset using RTL modeling, we will again
need to use an always_ff block and an if statement to set the output
to zero if the reset input is one. Here is an example of how to use such
an always_ff block.
module DFFR_RTL
(
input logic clk,
input logic rst,
input logic d,
output logic q
);
always_ff @( posedge clk ) begin
if ( rst )
q <= 1'b0;
else if ( !rst )
q <= d;
else
q <= 'x;
end
endmodule
Notice that we explicitly set the output to 'x' if rst is neither zero
nor one. This will only happen if rst is also 'x'. We have provided you
the interface a D flip-flop with reset in DFFR_RTL.v and a test bench
in DFFR_RTL-test.v. Go ahead and implement this module. The test bench
includes the same test cases you developed for the gate-level
implementation, so you should be able to go ahead and test the D
flip-flop as follows.
Once your design is passing all your tests generate waveforms and take a look using Surfer.
% cd ${HOME}/ece2300/sec06/build
% ./DFFR_RTL-test +test-case=2 +dump-vcd=waves-dffr.vcd
% code waves-dffr.vcd
Discussion Check-Off Task 4: Verify D Flip-Flop w/ Reset
Show a peer student your implementation for the gate-level and RTL D
flip-flop with reset. Compare your directed test cases with the peer
student's test cases and discuss any discrepancies. Then show a peer
student your waveforms and discuss how the waveforms illustrate
reset. Identify exactly where in the waveforms the D flip-flop is
being reset to zero. Also discuss with the peer student why we need
the final else to force the output to x. Won't the output
automatically be x if the inputs are x?
5. Clean Build
As a final step, do a clean build to verify everything is working correctly.