EE 560 - Summer 2024 Digital Systems Design

Labs

Policies

Academic Integrity

Please watch the video. To access the video, you need to first login to myviterbi using your USC login and click on Academic Integrity Introduction. Please go through the guidelines for academic integrity review process, which can be found in the Student Conduct Code in the current SCampus, Part B, Section 13. Please familiarize yourself with these standards and expectations concerning academic integrity.

We wish to clarify what kind of submissions will be considered as cheating and what are not considered as cheating.

  1. Obviously if you copy the code and submit, it is cheating. Both teams involved will be reported to University. Some students copy from their seniors. Some students copy and add white spaces here and there. We look for all these incidences. You should not have access to (or in possession of) solutions for your assignments (even as reference material).
  2. Submitting an obviously non-working design (such as a design which does not even compile, or which gets stuck in an infinite loop at run time during simulation, or does not obviously produce the required results is considered as cheating and I think that is fair.
  3. However submitting a suboptimal design (that takes a few extra clocks) is not considered as cheating.
  4. Submitting a Verilog/VHDL design along with an output file which is not produced by that Verilog/VHDL file is clearly cheating.
  5. You are required to hold your files in two places (so that at least one is available, if we want you to show it to us later) until the end of the semester: (a) on the PC of one of the two lab partners and also (b) on one of the UNIX scf accounts of the two lab partners. We cannot accept excuses such as “my hard-drive crashed”, “I deleted them by mistake”. We will then consider that you have submitted someone’s files.
  6. Team members are not expected to divide labs between the two of them. Both partners should work together on each design / each part of a lab for most of the time (say, at least for 70% of the time). Exact 50% contribution by each member to each part may not be practical. But we expect each member to contribute about 30% to 40% at minimum in each part of the lab. We can ask each of the two team members to explain any submitted design. If one of the two did not work on the lab but both names appear on the lab (say in names.txt), we will treat both as cheating. So, if your partner did not work on it or cannot stand questioning, then refuse to put his/her name on the lab.
  7. A team of two students shall make only one submission from one of the teammates’ UNIX account. Never make two submissions. Making duplicate submissions is like writing two answers for a single question in an exam and asking the professor to choose the right one to grade.
  8. Ask us when in doubt. Frankly, if you are not able to do the lab and you had already put-in a good-faith effort, then come to us and we will help you to finish your lab! So, there is absolutely no need to cheat! We want you to learn.

Checking For Success

If your lab submission passed our tests, you will find your team names in the Congratulations file posted on our status website. Please choose the file corresponding to the lab you submitted.

Lab Schedule

This schedule is subject to change anytime before the Monday of the week of the assigned lab.

Week Title Due (Code) Due (Demo/Review)
0 Lab 0 - Synthesis and Simulation Tools Wed. May 15 Fri. May 17
1 VHDL, Parity, Special Counter, Yard-feet Wed. May 22 Fri. May 24
1 Divider Debouncing and Single-Stepping, Timing Constraints Wed. May 22 Fri. May 24
2 Gray Code Counter, Divider with Cache Wed. May 29 Fri. May 31
3 CPU and FIFO with BRAM Wed. June 5 Fri. June 7
4 Tomasulo (FRL, BPB, SAB, SB, and CFC) Wed. June 12 N/A
5 Tomasulo (IU, ROB, Dispatch) Fri. June 21 N/A
5 AXI Fri. June 21 (28th allowed) N/A
6 CMP lab Fri. June 28 N/A
7 PCIe lab Wed. July 10 Fri. July 12
7 Code Coverage TBD TBD
8 GPGPU Lab Fri. July 12 Fri. July 12