Overview and Policy for ECE 5760 at Cornell University

Please note that I have borrowed these policies from Bruce Land, and they are largely identical to those provided on the previous course webpage.


Prerequisites

ECE 5725 will be useful for students taking this course

More specifically, you need to know:

Verilog: Students need to be comfortable with hardware design using Verilog HDL to construct sequential logic at the complexity level of a CPU. Some familiarity with concurrent computing techniques will be useful.

C: Every laboratory assignment involves writing C that runs on an ARM processor that interacts with your Verilog-constructed logic.

LINUX: Students should be familiar with basic concepts of LINUX. ECE 5725 will provide the background, but there are many other ways of gaining familiarity.

Mathematics: Students will be expected to understand the solution of ODEs, PDEs, and other iterated systems in order to implement them numerically and in parallel on the FPGA.

When in doubt, talk to the instructor.


Reading

The readings cover the theory required for each lab, as well as specific techniques necessary to implement the labs. The readings are a combination of research papers, vendor (Intel/Altera) manuals, and instructor-generated web pages. These materials are available at this link.


Purpose

Design of system-on-chip applications for hardware acceleration using FPGAs. Students working in groups of 2-3 design, debug, and construct several systems that illustrate the design of parallel FPGA hardware, linked to ARM processors running a LINUX operating system. The content focuses on laboratory work. The lectures are used primarily for the introduction of examples, description of specific modules to be designed, and instruction in the hardware and high-level design tools to be employed in the lab.

This is a design course. This means that we will expect you to show considerable creativity, flexibility, and motivation. In particular, you will need to:

  • Hit the web to find your own answers to questions you have.
  • Read and understand every aspect of manufacturer's data sheets for a variety of devices.
  • Use material from many of the courses you have taken.
  • Find solutions on your own from general, incomplete specifications. The lab assignments will be open-ended. Clever, efficient solutions will be rewarded. Detailed designs must be generated by the student teams before they get to lab. Designs will typically include C language code, digital circuitry designed in Verilog, and use of digital and analog peripherals.

We are trying to make this a little like the real world.


Grading

The policy

This class is composed of laboratory assignments and a final project. You will be graded on these tasks, plus some consideration of class participation. The final design project demonstration is due the last week of classes. The grade breakdown is as follows:

  • 50% for laboratory assignments

    For each laboratory assignment:

    • 10% for preparedness and participation
      • As determined by conversations with Hunter in the laboratory, lecture attendance, and occasional in-lecture quizzes.
      • These should be easy points, just come to class!
    • 20% for weekly progress deadlines (evenly distributed across all weeks for a particular lab)
      • To make these deadlines, you must come to lab prepared. If you do not do any out-of-class preparations, you will not be able to meet these deadlines.
      • Finishing a checkpoint on time will earn the student a 95% (A-equivalent). Finishing early will earn the student >95% (exceeds expectations). Missing milestones earns a 0.
      • If you checkoff on the required progress deadline before the end of lab, you are expected to stay and work on the next checkpoint.
      • A late progress checkoff receives a zero grade.
    • 30% for the final laboratory demonstration
      • The system must meet specifications and be usable.
      • Lab demos to TAs will be done before the end of each lab exercise, in lab.
      • There will be no late final demonstrations for any lab. This policy is to prevent any students from falling behind on subsequent lab exercises.
      • Your final demo may or may not include a code review to test for understanding.
      • A late demo receives a zero grade. If you run out of time, demonstrate the parts of the system that you've gotten working. These final demos are graded on the following scale:
Technical specifications met Score Comments
< Week 1 checkoff 0
= Week 1 checkoff 50%
<= Week 2 checkoff 50-75% Directly proportional to number of
specifications met, weighted by
relative difficulty of those specifications
<= Week 3 checkoff 75-96% Directly proportional to number of
specifications met, weighted by
relative difficulty of those specifications
> Week 3 checkoff 96-100% Students that exceed expectations
on a laboratory assignment will
receive A+ equivalent scores
    • 40% for the laboratory report
      • Lab reports are due before the start of your next lab period.
      • Please see the Laboratory reports section of this webpage for information on content.
      • All submissions will be electronic to your TA, via Canvas
      • You must attend your weekly scheduled lab period, even if you have finished the lab assignment early!
      • No late assignments will be accepted without prior permission (excepting reasonable extenuating circumstances)
      • You will turn in one lab report per team. No written collaborations between groups is permitted. You are (of course!) encouraged to help anyone in lab.
      • For some information about how these reports are graded, please see here.
      • A late report receives a zero grade.
  • 50% for the final project

    This is further broken down similarly to the laboratory assignments:

    • 10% for preparedness and participation
      • As determined by conversations with Hunter in the laboratory, lecture attendance, and occasional in-lecture quizzes.
      • These should be easy points, just come to class!
    • 20% for weekly progress deadlines (evenly distributed across all weeks of the final project)
      • For the final project you are responsible for establishing these weekly milestones.
      • Meeting milestones on time will earn the student a 95% (A-equivalent). Finishing early will earn the student >95% (exceeds expectations). Missing milestones earns a 0.
      • You will report your progress to me in a weekly update (which may be either written or verbal)
      • A late progress checkoff receives a zero grade.
      • NOTE: I know that plans change, and that sometimes things are harder than you think they might be!! As long as you are communicating with me and working at a reasonable rate, your grade will not be adversely affected by changes of plan.
    • 30% for the final laboratory demonstration
      • The system must meet the specifications that you set at the beginning of the project (i.e., did you build what you said you were going to build?)
      • The system must be usable.
      • Your final demo may or may not include a code review to test for understanding.
      • For the final project, your demo will also be evaluated on its sophistication relative to other final projects. This is to prevent gaming the system by choosing an easy project.
    • 40% for the final report
      • Please see this webpage for information on content.
      • For some information about how these reports are graded, please see here.
      • You will create a webpage for your final project.

Hunter reserves the right to make small adjustments to your grade. You may help your grade by participating in class discussions. Excessive nonattendance of lecture may lower your grade. If you feel that you have been unfairly graded, you have one week from the time the assignment is handed back to request a regrade. To request a regrade, you must submit the assignment with a written description of your concern attached to the instructor (not the TA).

Reflecting on this policy

Building things is difficult, and sometimes unpredictable. It may be the case that you don't make a weekly checkpoint. This can sometimes cause students to panic, and sometimes doing the math to determine how much of your final grade each component of the course is worth can alleviate that panic. The contribution to your final grade (as a percentage) of each assignment and checkout is listed below.

Lab 1

  • Preparedness/participation: 1.7
  • Checkout 1: 1.1
  • Checkout 2: 1.1
  • Checkout 3: 1.1
  • Final demo: 5
  • Lab report: 6.7

Lab 2

  • Preparedness/participation: 1.7
  • Checkout 1: 1.1
  • Checkout 2: 1.1
  • Checkout 3: 1.1
  • Final demo: 5
  • Lab report: 6.7

Lab 3

  • Preparedness/participation: 1.7
  • Checkout 1: 1.1
  • Checkout 2: 1.1
  • Checkout 3: 1.1
  • Final demo: 5
  • Lab report: 6.7

Final Project

  • Preparedness/participation: 5
  • Weekly progress: 10
  • Final demo: 15
  • Final report: 20

Laboratory policies

If you are in the laboratory during ECE 2300 class time, you automatically receive a 0 for that week's checkoff and you lose access to the lab.

You are expected to attend your assigned lab period every week and to finish the lab assignment in the alloted time. You must finish the assignment before the end of the alloted time. You can, of course, start early on an assignment. All negotiations concerning lab absences due to planned trips or sickness are to be conducted with your lab instructor. For planned trips you must notify your instructor in advance.

During the lab sections in which there is project checkoff:

  • TAs first priority is to check people off.
  • TAs can help people only if there is no one waiting to be checked off.
  • If there are too many people to help, then the TAs will help students in the current section who are trying to finish on time.
  • Only then will there be time to help people from other sections.

Lab work will be in groups of 2 or 3. All members are expected to become proficient with all aspects of the lab. Where each has prepared design work or code assigned as homework, the group design will involve negotiation. The members of a group may be graded differentially if it becomes obvious that one person is doing the bulk of the work.

Each student in this course is expected to abide by the Cornell University Code of Academic Integrity.

Any work submitted by a student in this course for academic credit will be the student's own work. For this course, collaboration is allowed between partners in a group. Students agree that by taking this course all required papers may be subject to submission for textual similarity review to Turnitin.com for the detection of plagiarism. All submitted papers will be included as source documents in the Turnitin.com reference database solely for the purpose of detecting plagiarism of such papers. Use of Turnitin.com service is subject to the Usage Policy posted on the Turnitin.com site.

Examples of allowed/not allowed collaboration:

  • Allowed: All homework and code must be shared within a group.
  • Not Allowed Sharing of any material between groups. This includes unprotected GitHub or other code repositories. Unprotected code online will be considered a violation of Cornell academic integrity policy!
  • Allowed: Talking in lab about code with another group.
  • Not Allowed: Emailing code to another group or using another group's keyboard to type code.
  • Allowed: Showing another group your circuit.
  • Not Allowed: Wiring for another group, or lending them your circuit.
  • Allowed: Talking about the contents of a lab report to another group.
  • Not Allowed: Copying anything (even one sentence) from any web or print document, unless the source is stated and the quote is short.
  • Allowed: Using code from previous final projects or web sources with detailed attribution.
  • Not Allowed: Using code from previous final projects or web sources without attribution.

All students will abide by Cornell policy on Equal Education and Employment Opportunity. Exerpt:

Association with Cornell, either as a student, faculty, or staff member, involves participation in a free community where all people are recognized and rewarded on the basis of individual performance rather than personal convictions, appearance, preferences (including sexual or affectional orientation), or happenstance of birth. Cornell University's history of diversity and inclusion encourages all students, faculty and staff to support a diverse and inclusive university in which to work, study, teach, research and serve. No person shall be denied admission to any educational program or activity or be denied employment on the basis of any legally prohibited discrimination involving, but not limited to, such factors as race, color, creed, religion, national or ethnic origin, marital status, citizenship, sex, sexual orientation, gender identity or expression, age, disability, or protected veteran status.


AI policies

For lab reports

For your lab reports, you must cite and quote AI-generated content in an identical fashion to that with which you must cite and quote human-generated content. Failure to do so will be considered plagiarism.

For your code

You may use AI-generated code at your own risk, subject to the following requirements and conditions.

  • Any AI-generated code must be clearly labeled as such. Please see the example below. Failure to label any AI-generated code will be considered plagiarism.
  • The course staff will not help you debug AI-generated code.
    ################## BEGIN AI-GENERATED CODE ##################
    void foo() {
      printf("Hello, humans.") ;
    }
    ################### END AI-GENERATED CODE ###################
    
  • Along with your lab reports, you must turn in your prompt log. You can generate this prompt log with the following command to Copilot:

Generate a prompt log of this conversation. For each prompt, include the time/date, the number of edits suggested, and the number of code insertions, deletions, and modifications accepted.


Laboratory reports

Each laboratory assignment requires a written report. You will submit a single report for your group. The report should be submitted as an electronic document via Canvas.

The report should be a thorough documentation of the project assigned. The presentation should be arranged so that any reader with technical competence in the subject can easily understand what was done and how it was done. You should write to a level of detail that, in 2 years, you could recreate your project (and understand the methodology!) using only your report. The following report organization is suggested:

  1. Introduction: Give a short explanation of what was done.
  2. Describe the role of the ARM and FPGA sides in your design
  3. RTL level description of your project and any relevant state machines.
  4. Design and Testing Methods: Explain the approach you used for both software and hardware aspects of the assignment. Be sure to include the design of tests whose outcome are convincing to the reader (or to the instructor in the lab) that the requirements of the assignment have been met.
  5. Results: Screen shots, videos, sound recordings, frequency analysis or what ever is necessary to document the functioning of your project.
  6. Documentation: Include here drawings and program listings, together with any explanatory comments needed.
  7. Answers to specific questions given in the lab writeups.
  8. Comments: This optional section is for any comments the authors may wish to make concerning the assignment, including suggestions for improvement, excuses, and complaints. The purpose of this section is to encourage the writer to make the other sections clear, concise and understandable, and to reserve this section for creative comments.

Here and here (and here and here) are some well done example reports from 4760. Note that these do not include discussion of AI, which is now a requirement. Aim for this level of depth, but for your DE1 projects.


Access to computers

You and your partner(s) will have use of a PC, FPGA, etc. in Phillips 238 during your assigned lab period. Students from other lab periods may use setups not needed by students attending their assigned lab.

Machines and file systems sometimes die. You should always back up all your work. There is no excuse for lost work, even if it is because of a compiler or other system error.


Academic concerns

If you are experiencing undue personal or academic stress at any time during the semester or need to talk with someone about a personal problem or situation, I encourage you to seek support as soon as possible. I am available to talk with you about stresses related to your work in my class. Additionally, I can assist you in reaching out to any one of a wide range of campus resources, including:

  • Your college’s Academic Advising or Student Services Office
  • Cornell Learning Strategies Center at 255-6310, http://lsc.sas.cornell.edu
  • Gannett Health Services at 255-5155, www.gannett.cornell.edu
  • Let’s Talk Drop–In Consultation and Support www.gannett.cornell.edu/Let’sTalk
  • Peer Support provided by Empathy Assistance and Referral Service at 255-EARS

DISABILITY-RELATED CONCERNS: Students with either an ongoing or short-term disability are encouraged to contact Student Disability Services (SDS) for a confidential discussion of their need for academic accommodations.SDS is located in 420 CCC building; phone number is 254-4545.