Skip to content

Lab 3: Music Player
Part A: Note Player

Lab 3 will give you experience designing, implementing, testing, and prototyping combinational and sequential logic using the Verilog hardware description language. The lab will continue to leverage concepts from Topic 2: Combinational Logic, Topic 3: Boolean Algebra, and Topic 4: Combinational Building Blocks but will also leverage concepts from Topic 6: Sequential Logic, Topic 7: Finite-State Machines, and Topic 8: Sequential Building Blocks. More specifically, the lab will give students experience with: latches, flip-flops, and registers; Moore and Mealy FSMs; and counters. The lab will continue to reinforce three key abstraction principles: modularity, hierarchy, and regularity.

You will be implementing a music player that takes as input a song selection (via the switches) and a start song signal (via a push button). The music player will then play the chosen song by generating a square wave at appropriate note frequencies suitable for use with a piezoelectric buzzer. An idle signal is displayed using an LED so that user knows when the player is ready to play a new song. The music player will make use of the adders and muxes from Lab 2. The song selection and the current note are both displayed using seven-segment displays from Lab 1. This lab also serves as a transition from lower-level gate-level (GL) modeling to higher-level register-transfer-level (RTL) modeling. Some of parts of your design will use explicit GL modeling, while other parts of your design will use RTL modeling. Students will have a chance to appreciate how RTL modeling can improve productivity but with less control over the final hardware implementation. The lab includes five parts:

  • Part A: Note Player

    • Due 10/16 @ 11:59pm via GitHub
    • Students should work on Part A before, during, and after your assigned lab section during the week of 10/6
    • Pre-lab survey on Canvas is (roughly) due by end of lab section during the week of 10/6

  • Part B: Multi-Note and Music Player

    • Due 10/23 @ 11:59pm via GitHub
    • Plan to work on Part B after fall break and during the week of 10/20

  • Part C: FPGA Prototype v1

    • Due week of 10/20 during assigned lab section
    • This part will focus on prototyping the code developed in Part A
    • Even though completed with a partner, every student must turn in their own paper check-off sheet in their lab section!

  • Part D: FPGA Prototype v2

    • Due week of 10/27 during assigned lab section
    • This part will focus on prototyping the code developed in Part B
    • Even though completed with a partner, every student must turn in their own paper check-off sheet in their lab section!

  • Part E: Report

    • Due week of 10/27, three days after lab section @ 11:59pm via Canvas
    • Post-lab survey on Canvas is due at the same time as the report

All parts of Lab 3 must be done with a partner. You can confirm your partner on Canvas (Click on People, then Groups, then search for your name to find your lab group).

Both students must contribute to all parts!

It is not acceptable for one student to exclusively work on the code while the other student exclusively works on the report. It is not acceptable for one student to exclusively work on hardware design while the other student exclusively works on testing. Both students must contribute to all parts. Student understanding of Verilog design and testing will be assessed on the prelim exams, final exam, and Verilog coding exam. The instructors will also survey the Git commit log on GitHub to confirm that both students are contributing equally. If you are using pair programming, then both students must take turns using their own account so both students have representative Git commits. Students should create commits after finishing each step of the lab, so their contribution is clear in the Git commit log. A student's whose contribution is limited as represented by the Git commit log will receive a significant deduction to their lab score.

This handout assumes that you have read and understand the course tutorials and that you have attended the discussion sections. To get started, use VS Code to log into a specific ecelinux server, source the setup script, and clone your remote repository from GitHub:

 % source setup-ece2300.sh
 % mkdir -p ${HOME}/ece2300
 % cd ${HOME}/ece2300
 % git clone git@github.com:cornell-ece2300/groupXX
 % cd ${HOME}/ece2300/groupXX
 % tree

where XX should be replaced with your group number. You can both pull and push to your remote repository. If you have already cloned your remote repository, then use git pull to ensure you have any recent updates before working on your lab assignment.

 % cd ${HOME}/ece2300/groupXX
 % git pull
 % tree

where XX should be replaced with your group number. Go ahead and create a build directory, run configure to generate a Makefile, and run all of the tests.

% cd ${HOME}/ece2300/groupXX
% mkdir -p build
% cd build
% ../configure
% make check

Your repo contains the following files which are part of the automated build system:

  • Makefile.in: Makefile for the build system
  • configure: Configure script for the build system
  • configure.ac: Used to generate the configure script
  • scripts: Scripts used by the build system

The following table shows all of the hardware modules you will be developing in Lab 3.

Lab 3 requires implementing and verifying 22 hardware modules. While this might seem like a daunting task, many of these hardware modules require less than five lines of Verilog code. For many of the test benches we provide students with a template so they need only enter the expected outputs. Test cases are reused across the GL and RTL versions of the same hardware module. Start from the D latch and systematically work your way down the table. Implement the GL and RTL versions at the same time. Never move on to the next row in the table until you have thoroughly tested the previous row.

GL modules must be implemented using explicit gate-level modeling. This means students are only allowed to use these Verilog constructs in their Verilog hardware designs:

  • wire (single bit and multiple bit)
  • not, and, nand, or, nor, xor, xnor
  • literals (e.g., 1'b0, 1'b1)
  • wire slicing (e.g., x[0], x[1:0])
  • assign for connecting wires (e.g., assign x = y;);
  • assign for setting a wire to a constant value (e.g., assign x = 1'b0;)
  • module instantiation

RTL implementations can use the following Verilog constructs.

  • logic
  • +, -, *
  • >>, <<
  • ==, !=, <, >, <=, >=
  • &&, ||, !
  • &, ~&, |, ~|, ^, ^~ (reduction operators)
  • ?: (ternary operator)
  • always_comb, always_ff @(posedge clk)
  • if, else if, endif
  • case, default, endcase

Note that some hardware modules have more specific restrictions; see the source comments for more details. Using unallowed Verilog constructs will result in significant penalties for code functionality and code quality. If you have any questions on what Verilog constructs can and cannot be used, please ask an instructor. There are no restrictions on Verilog constructs in test benches or interactive simulators.

1. Pre-Lab Survey

Take some time to meet with your partner to discuss the pre-lab survey which is on Canvas. The pre-lab survey includes questions on your learning outcomes, workload distribution, workload roadmap, communication, and collaboration. The survey is due (roughly) by the end of your assigned lab section the week of 10/6. Students with an early lab section on Monday might want to complete the pre-lab survey right after their lab section, while students with a late lab section on Wednesday should meet earlier in the week and complete the pre-lab survey then. A student will not receive a grade for the lab unless the pre-lab survey is completed.

2. Interface and Implementation Specification

You will be implementing and composing a variety of combinational and sequential hardware modules including adders, muxes, latches, flip-flops, registers, comparators, and counters; ultimately you will be composing these hardware modules to implement a note player. This section describe the required interface (i.e., the ports for the module and the module's functional behavior) before describing the required implementation (i.e., what goes inside the module) for each hardware module.

2.1. Latches and Flip-Flops

You will need to implement a GL latch and three GL/RTL flip-flops:

  • DLatch: D latch (level high, transparent when clock is one)
  • DFF: D flip-flop (positive edge triggered)
  • DFFR: D flip-flop with reset signal
  • DFFRE: D flip-flop with reset and enable signals

You should consult the lecture notes for the GL implementation of these latches and flip-flops. You just need to directly map the implementation from the lecture notes using explicit gate-level modeling.

Recall from the discussion sections that we will need to make use of an always_ff block for RTL modeling of sequential logic. Here is an example of how to implement a D flip-flop using an always_ff block:

1
2
3
always_ff @( posedge clk ) begin
  q <= d;
end

This always_ff block will execute on the positive edge (posedge) of the clock signal (clk). We are using a special non-blocking assignment (<=) which is meant to be used in always_ff blocks. The semantics of a non-block assignment are: (1) right before the rising edge, the right-hand side of every non-blocking assignment in the entire design is evaluated and the result is saved; (2) right after the rising edge, the saved values are assigned to the signal on the left-hand side. This enables us to model flip-flops.

Note that this the only form of an always_ff block you are allowed to use in this course. You are not allowed to use negedge and you are not allowed to trigger an always_ff with any other signals (e.g., in this course, you are not allowed to include reset (rst) in the sensitivity list for an always_ff).

You can use other RTL operations within an always_ff block. For example, you can use an if/else conditional operation within an always_ff block to model a D flip-flop with a (synchronous) reset signal:

1
2
3
4
5
6
7
8
9
always_ff @( posedge clk ) begin

  if ( rst )
    q <= 1'b0;
  else
    q <= d;

 `ECE2300_SEQ_XPROP( q, $isunknown(rst) );
end

Notice the need to explicitly propgate X values to avoid X-optimism. If the rst signal is X we need to make sure that the output q is also X. You can use a more complicated conditional to implement a D flip-flop with a reset and enable signal:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
always_ff @( posedge clk ) begin

  if ( rst )
    q <= 1'b0;
  else if ( en )
    q <= d;

  `ECE2300_SEQ_XPROP( q, $isunknown(rst) );
  `ECE2300_SEQ_XPROP( q, (rst == 0) && $isunknown(en) );
end

So the output q will not change if en is zero. Again, notice the need to explicitly propgate X values to avoid X-optimism. Here we must be very careful in how we propagate X values. If rst signal is X then the output q is also X. We only care if the en signal is X is rst is zero.

Note that in this course we will only allow using an always_ff block in very specific modules. Namely within the implementation of single-bit flip-flops (i.e., DFF_RTL, DFFR_RTL, DFFRE_RTL) and within the implementation of the multi-bit register (e.g., Register_16b_RTL). Students are not allowed to use an always_ff anywhere else in their hardware designs. If a hardware design needs sequential logic, then the design should instantiate one of these single-bit flip-flops or multi-bit registers. This restriction is critical to enabling new Verilog designers to know exactly what hardware is being implemented. Arbitrarily using always_ff blocks can quickly lead to incredibly complicated hardware models with no hope of understanding what hardware we are actually implementing.

Once you have finished implementing all of the latches and flip-flops, take a minute to appreciate the relationship between the GL and RTL implementations. The RTL implementations are just a different way of modeling the hardware within the GL implementation. The FPGA tools will synthesize the RTL implementation into hardware very similar to what is in the GL implementation.

2.2. Register

As discussed in lecture, we can create a GL multi-bit register by simply instantiating a number of GL flip-flops in parallel. The data input (d) and data output (q) of each flip-flop should be connected to their corresponding bit of the register's multi-bit input and output ports. The clock, reset, and enable signals should be connected to each flip-flop.

For RTL multi-bit registers there is no need to instantiate a number of RTL flip-flops. We can instead model a multi-bit register using a single always_ff block. A single non-blocking assignment can be used to assign the multi-bit input to the multi-bit output on the rising edge of the clock.

2.3. Equality Comparator

We need a GL 16-bit equality comparator to implement the counter. You will need many XNOR or XOR gates depending on how you want to immplement your comparator. You are allowed to use logic gates with many inputs if you like. So for example, it is fine to use a 16-input AND gate or a 16-input OR gate.

2.4. Counter

We will be implementing a relatively general-purpose count-up 16-bit counter that can support starting and finishing from arbitrary values, incrementing by an arbitrary value, and pausing the counter. We will unit test the counter and then reuse it in several places in both Lab 3 and Lab 4. The counter has the following interface:

When load is high, the counter should register the start and finish values at the end of the cycle. If start or finish change while load is low, then these changes should be ignored.

When enable (en) is high, the counter increments from the registered start value up to the registered finish value in incr steps, checking for equality on each cycle. Once the finish value is reached the counter holds at the finish value. When enable is low, the counter holds its current value and should not increment.

The count output should always reflect the current count (i.e., it should not reflect the next count).

The done signal should always reflect whether or not the current count and the registered finish values are equal. If they are equal then the done signal should be high. If they are not equal then the done signal should be low. If start equals finish, the counter immediately asserts done after loading, since the initial count matches finish.

The counter assumes the following about the inputs; behavior is undefined if any of these conditions is not satisfied.

  • incr must not change while the counter is counting
  • start, finish, and incr are 16-bit unsigned binary values
  • start must be less than or equal to finish
  • difference between finish and start must be divisible by incr

Here is a trace of the expected output when counting from 2 to 4 twice.

cyc  en ld start  incr   finish   count done
  0: 1  1 (0002, +0001 -> 0004) > 0000  1
  1: 1  0 (0002, +0001 -> 0004) > 0002  0
  2: 0  0 (0002, +0001 -> 0004) > 0003  0    # counter disabled
  3: 0  0 (0002, +0001 -> 0004) > 0003  0    # counter disabled
  4: 1  0 (0002, +0001 -> 0004) > 0003  0
  5: 1  0 (0002, +0001 -> 0004) > 0004  1
  6: 1  0 (0002, +0001 -> 0004) > 0004  1
  7: 1  0 (0002, +0001 -> 0004) > 0004  1
  8: 1  1 (0002, +0001 -> 0004) > 0004  1
  9: 1  0 (0002, +0001 -> 0004) > 0002  0
 10: 0  0 (0002, +0001 -> 0004) > 0003  0    # counter disabled
 11: 0  0 (0002, +0001 -> 0004) > 0003  0    # counter disabled
 12: 1  0 (0002, +0001 -> 0004) > 0003  0
 13: 1  0 (0002, +0001 -> 0004) > 0004  1

Pay careful attention to the exact cycle the output count is set to four and the exact cycle the done signal is set to one. Your counter must produce the exact same cycle-level behavior.

You are responsible for designing your own GL 16-bit counter that meets this specification. Your GL implementation must only use GL modules or explicit gate-level modeling. Do not put any logic on the reset signal. The reset signal should be directly attached to the reset input port of the register without any logic. Do not put any logic on the clock. The clock signal should be directly attached to the clock input port of the register without any logic. You must draw a block diagram of your final counter. You will need this diagram for later parts of the lab.

You are also responsible for designing your own RTL 16-bit counter that meet this specification. Your RTL counters must explicitly instantiate an RTL register for the sequential logic, and then use a single always_comb block for your combinational logic. You cannot directly use an always_ff block in your RTL counter. You must explicitly instantiate an RTL register. Do not put any logic on the reset signal. The reset signal should be directly attached to the reset input port of the register without any logic. Do not put any logic on the clock. The counters are examples of flat RTL modules, since they do not instantiate any hardware modules other than the a register.

Use an incremental design approach!

This is a relatively complex hardware module that students must implement from scratch. We strongly discourage using a big bang design approach. Do not just start writing code, try to implement the entire specification in one shot, and then see if you can get it to work. This approach can easily take 3+ hours. Instead, use an incremental design approach. Start by implementing a simple, incomplete version of the counter, get that passing simple tests, then add one piece of functionality, get that passing more complicated tests, and so on.

To help students learn an incremental design approach we recommend using the following five incremental steps. Draw a block diagram for each step before writing any code! We have included five basic test cases that correspond to these five steps.

  • Step 1: Implement a counter that is reset to zero and then simply counts up forever. This incomplete counter can mark the start, finish, load, and en inputs to the counter as unused and leave the done output of the counter undriven. This incomplete design should pass the basic_v1 test case. Here is the corresponding block diagram.

  • Step 2: Extend the counter from step 1 to support loading in a new start value but ignore the finish and en inputs to the counter. Leave the done output of the counter undriven. This incomplete design should pass the basic_v2 test case. Remember to draw a block diagram before writing any code.

  • Step 3: Extend the counter from step 2 to support loading in a new finish value but ignore the en input to the counter. The incomplete counter should set the done output correctly, but does not need to stop when done. This incomplete design should pass the basic_v3 test case. Remember to draw a block diagram before writing any code.

  • Step 4: Extend the counter from step 3 to support stopping when done. Continue to ignore the en input. This incomplete design should enable counting, stopping when done, and then counting again. This incomplete design should pass the basic_v4 test case. Remember to draw a block diagram before writing any code.

  • Step 5: Extend the counter from step 4 to support the en input to the counter. The counter should hold the current count when en is zero. This is the complete counter and should pass the basic_v5 test case. Remember to draw a block diagram before writing any code.

Follow these five steps for the GL implementation, then follow the exact same five steps for the RTL implementation. Although you don't need to draw block diagrams for your RTL implementations, you should still understand the hardware your RTL represents. If you follow this process you will always be making progress; the entire experience will be less frustrating and take less time.

2.5. Note Player

The note player generates a square wave at a given frequency forever. It includes a control unit and a counter.

The clock and reset signals are not shown in the above block diagram. The period is provided as an input port and is assumed to never change after reset. The control unit should be implemented using the following four-state Moore FSM.

The outputs are specified in each state: cl stands for count_load and n stands for note. The FSM must use the following state encoding:

 State      Encoding
---------------------
 LOAD_HIGH  2'b00
 WAIT_HIGH  2'b01
 LOAD_LOW   2'b10
 WAIT_LOW   2'b11

In the LOAD_HIGH state, the FSM should load the period into the counter, set the note output to be high, and move into the WAIT_HIGH. In the WAIT_HIGH state, the FSM should continue to set the note output to be high. Once the counter is done, the FSM should move into the LOAD_LOW state. In the LOAD_LOW state, the FSM should load the period into the counter, set the note output to be low, and move into the WAIT_LOW. In the WAIT_LOW state, the FSM should continue to set the note output to be low. Once the counter is again done, the FSM should move back to the LOAD_HIGH state to repeat the sequence. LOAD_HIGH is the reset state.

Here is a trace of the expected output when the period is five.

cyc rst period     state          note
------------------------------------------
  0: 0  00000101 > 00 (LOAD_HIGH) 1
  1: 0  00000101 > 01 (WAIT_HIGH) 1
  2: 0  00000101 > 01 (WAIT_HIGH) 1
  3: 0  00000101 > 01 (WAIT_HIGH) 1
  4: 0  00000101 > 01 (WAIT_HIGH) 1
  5: 0  00000101 > 01 (WAIT_HIGH) 1
  6: 0  00000101 > 01 (WAIT_HIGH) 1
  7: 0  00000101 > 10 (LOAD_LOW ) 0
  8: 0  00000101 > 11 (WAIT_LOW ) 0
  9: 0  00000101 > 11 (WAIT_LOW ) 0
 10: 0  00000101 > 11 (WAIT_LOW ) 0
 11: 0  00000101 > 11 (WAIT_LOW ) 0
 12: 0  00000101 > 11 (WAIT_LOW ) 0
 13: 0  00000101 > 11 (WAIT_LOW ) 0
 14: 0  00000101 > 00 (LOAD_HIGH) 1

Pay careful attention to the exact cycle of each state transition and the exact cycles the note is high and low. When you load the counter with the value five it will be done on the cycle 6. Your note player must produce the exact same cycle-level behavior.

The GL version of the note player control unit should instantiate two DFFRE_GL modules to store the two-bit FSM state. The next state combinational logic and output combinational logic should be implemented using explicit gate-level modeling. The GL version of the note player just composes the GL note player control unit with the GL counter.

The RTL version of the note player control unit should instantiate two DFFRE_RTL modules to store the two-bit FSM state. The next state combinational logic should be implemented using a single, dedicated always_comb block. The output combinational logic should be implemented using a separate always_comb block. The control unit is an example of a flat RTL module, since it does not instantiate any hardware modules other than the flip-flops. The RTL version of the note player just composes the RTL note player control unit with the RTL counter.

3. Testing Strategy

You are responsible for developing an effective testing strategy to ensure all implementations are correct. Writing tests is one of the most important and challenging aspects of designing hardware. Hardware engineers often spend far more time implementing tests than they do implementing the actual hardware design.

3.1. Basic Testing

We will be using the same lightweight testing framework from the previous labs. For each hardware module, we provide a test bench for you to use along with one basic test case. You can run the basic tests for all hardware modules using the generated Makefile.

% cd ${HOME}/ece2300/groupXX/build
% make check-lab3-partA
% make check-lab3
% make check

You can also build and run a single test simulator.

% cd ${HOME}/ece2300/groupXX/build
% make DLatch_GL-test
% ./DLatch_GL-test

You can specify which specific test case to run on the command line and also dump waveforms that can be viewed using Surfer.

% cd ${HOME}/ece2300/groupXX/build
% make DLatch_GL-test
% ./DLatch_GL-test +test-case=1
% ./DLatch_GL-test +test-case=1 +dump-vcd=waves.vcd

3.2. Exhaustive Testing

The following test benches are for hardware modules with a limited number of inputs, and thus you can (and should) use exhaustive testing:

  • DLatch_GL-test.v
  • DFF_GL-test.v, DFF_RTL-test.v

We provide test case templates for these test benches so all you need to do is fill in the expected output. You do not need to add any more test cases. Notice that DFF_GL and DFF_RTL have the exact same interface and thus will use the exact same test cases. We have refactored the test cases for these hardware modules into DFF-test-cases.v and then included these test cases in DFF_GL-test.v and DFF_RTL-test.v. This way we only need to write the test cases once.

3.3. Directed Testing

The remaining hardware modules all have many more inputs and thus would required hundreds or even thousands of checks to implement exhaustive testing. So for the remaining hardware modules you can use directed testing to check for specific corner cases.

We provide test case templates for the following test benches so all you need to do is fill in the expected output. You do not need to add any more test cases.

  • DFFR_GL-test.v, DFFR_RTL-test.v
  • DFFRE_GL-test.v, DFFRE_RTL-test.v
  • Register_16b_GL-test.v, Register_16b_RTL-test.v

For some of these these we have again refactored the test cases for these hardware modules into a separate -test-cases.v file. You must write your own directed test cases for the following test benches:

  • EqComparator_16b_GL-test.v
  • Counter_16b_GL-test.v, Counter_16b_RTL-test.v
  • NotePlayerCtrl_GL-test.v, NotePlayerCtrl_RTL-test.v
  • NotePlayer_GL-test.v,NotePlayer_RTL_RTL-test.v

Remember, each directed test case should focus on testing a very specific kind of functionality and they should contain 2-10 checks. Be sure to add your tests cases to the list in the initial block and to check the output of the test simulator to confirm that your directed test cases are running and testing what you expect them to. Consider purposefully inserting a bug in your designs to see if your directed test cases will catch the bug.

3.4. Random Testing

Directed testing is useful for testing the known unknowns, but what about the unknown unknowns? How should we test for corner cases we have not even thought of yet? Random testing can help increase our testing coverage and increase our confident that our hardware design is functionally correct. You should implement one random test case for each of the following hardware modules:

  • EqComparator_16b_GL-test.v
  • Counter_16b_GL-test.v, Counter_16b_RTL-test.v

Random test cases should include a for loop. Each iteration should: (1) generate random input values; (2) use Verilog test code to programmatically determine the correct output values; and (3) use the check task to ensure the design-under-test produces the correct outputs give the corresponding random inputs.

3.5. X-Propagation Testing

You must also include one X-propagation test case for the following modules.

  • DLatch_GL-test.v
  • DFFR_GL-test.v, DFFR_RTL-test.v
  • DFFRE_GL-test.v, DFFRE_RTL-test.v
  • Register_16b_RTL-test.v, Register_16b_RTL-test.v
  • EqComparator_16b_GL-test.v
  • Counter_16b_GL-test.v, Counter_16b_RTL-test.v

Some of these test benches already include a template that you just need to fill in. If nothing else, check that if all of the inputs are X then all of the outputs are X.

3.6. Interactive Simulators

We have provided you two interactive simulators which will emulate the FPGA prototype you will be demoing in the lab. After finishing implementing and thoroughly testing your RTL counter, you can build and run the simulator for the counter like this:

% cd ${HOME}/ece2300/groupXX/build
% make counter-sim
% ./counter-sim +switches=00111

The switches are connected to the counter input. The counter simulator will display the input and the output of the count-down counter by showing what the four seven segment displays would look like on the FPGA prototype. You can press enter to emulate the clock toggling.

After finishing implementing and thoroughly testing your RTL note player, you can build and run the simulator for the note player like this:

% make note-player-sim
% ./note-player-sim +switches=0100_0100

The switches will set the period of the note player. Here is a table showing the mapping from inputs to notes.

                   period period    freq
switches  hex  dec (cycs)   (ms)    (Hz) note
0111_1011 0x7b 123    250   5.12  195.31 G3
0110_1101 0x6d 109    222   4.55  219.95 A3
0110_0001 0x61  97    198   4.06  246.61 B3
0101_1011 0x5b  91    186   3.81  262.52 C4
0101_0001 0x51  81    166   3.40  294.15 D4
0100_1000 0x48  72    148   3.03  329.92 E4
0100_0100 0x44  68    140   2.87  348.77 F4

The simulator will generate a VCD file that you can then open using Surfer to look at the note output waveform. You can measure period between rising edges of the note output to verify that the note player is indeed generating the note at the proper frequency. For example, this is what the output looks like when setting the switches to 0100_0100. The period is 2.86ms which is 348Hz or the note F4. Try other notes!

4. Lab Code Submission

To submit your code you simply push your code to GitHub. You can push your code as many times as you like before the deadline. Students are responsible for going to the GitHub website for your repository, browsing the source code, and confirming the code on GitHub is the code they want to submit is on GitHub Be sure to verify your code is passing your tests both on ecelinux and on GitHub Actions. Your design code will be assessed both in terms of code quality, verification quality, and functionality.

5.1. Code Quality

Your code quality score will be based on how well you follow the course coding conventions posted here:

Code quality for Part A will be assessed after the Part B deadline.

5.2. Verification Quality

Verification quality is based on how well your testing enables making a compelling case for correctness. You will need to write compelling directed test cases, use reasonable randomg testing, and include a simple X-propgation test case. Use comments appropriately to describe your test cases. Verification quality for Part A will be assessed after the Part A deadline.

5.3. Functionality

Your functionality score will be determined by running your code against a series of tests developed by the instructors to test its correctness. Note that we will be using the automated build system to test your final code submission as shown below.

% mkdir -p ${HOME}/ece2300
% cd ${HOME}/ece2300
% git clone git@github.com:cornell-ece2300/groupXX
% cd groupXX

% mkdir -p build
% cd build
% ../configure
% make check-lab3-partA