ECE383 Embedded Computer Systems II#
👨🏫 Instructors#
📝 Course information#
Course Goals:
Cadets shall design, build, and debug hardware / software to drive peripheral devices.
Cadets shall design, build, and debug an advanced digital system. Three different approaches will be taken: (a) a fully custom-built hardware solution, (b) using a general-purpose software processor, and (c) using a general-purpose software processor combined with custom-built hardware.
Express the tradeoffs between choosing a microcontroller versus a custom digital system
Course Text: RTL Hardware Design Using VHDL: Coding for Efficiency, Portability, and Scalability - Pong P. Chu (ISBN 0471720925). Available for free via DoD Libraries
Syllabus: Posted here.
Course Schedule: Posted here and subject to change.
📡 Communication and Control (C2)#
Microsoft Teams - The 383 Teams site and Outlook email will be used for course announcements. The virtual class sessions will be held your sections 383 Teams site when we do not have in person class
Blackboard - Blackboard will only be used at the “official” grades
Gradescope - Gradescope will be used to grade most assignments
Github - You will use github for your software repository.
All communication and announcement 📣 will be provided through MS Teams
All lecture 📓 materials will be provided through MS Teams.
Laboratory 🔬 work will be posted in this course web.
All assignments must be submitted in Gradescope
Github will be used for students to provide their source code 📄 for homework and laboratory assignments.
💯 Grading#
Grading will primarily be performed in Gradescope, with official grades listed in Blackboard.
Grade Distribution and Policy#
Prog |
Final |
|
|---|---|---|
GRs |
40 (1) |
25 (2) |
Lab 1 |
20 |
10 |
Lab 2 |
20 |
10 |
Lab 3 |
10 |
|
Lab 4 |
10 |
|
Quizzes / Assignments |
20 |
10 |
Final Project |
25 |
|
TOTAL |
100 |
100 |
Grade |
Max (Exclusive) |
Min (Inclusive) |
|---|---|---|
A |
100 |
93 |
A- |
93 |
90 |
B+ |
90 |
87 |
B |
87 |
83 |
B- |
83 |
80 |
C+ |
80 |
77 |
C |
77 |
73 |
C- |
73 |
70 |
D |
70 |
60 |
F |
60 |
0 |
⏰ Late Policy:#
If problems arise with graded assignments, see your instructor in advance
The cutoff for **on-time submission is 23:59 🕖 ** on the due date.
Late days are counted in 24-hour periods. Submitting between 23:59:01 on the due date and 23:59:00 the next day is one day late, and so on.
You are given 5 grace days (self-granted extensions) which you can use to give yourself extra time without penalty. No more than 2 grace days (calendar days) can used for each assignment.
Instructor-granted extensions are only considered after all grace days are used and only given in exceptional situations. Computer problems such as hard-drive reimaging are not considered as exceptional situations and you must use grace days.
Late work handed in when you have run out of grace days is 💥 discounted up to 20% for the first day late and up to 15% per day late thereafter.
Every assignment has a hard deadline; 4 calendar days past the original due date.
Late submissions (penalty or not) are not accepted after the hard deadline or after the solution to the assignment is published. No late submissions (penalty or not) will be accepted for the assignments right before GRs.
📄 Documentation Requirements#
All help received on work submitted for grading must be documented in accordance with the course documentation policy.
Each documentation statement must be specific enough that it explicitly describes what assistance was provided, how it was used in completing the assignment, and who provided the assistance.
If no help was received on this assignment, the documentation statement must state “None.”
If you checked answers with anyone, you must document with whom on which problems. You must document whether you made any changes or not. If you did make changes, you must document the problems you changed and the reasons why.
Vague documentation statements will result in a 5% deduction on the assignment.
Sample Documentation#
Consider the following examples when writing your own detailed documentation statements:
Bad Example: Cadet McFly explained how the factorial worked.
Good Example: Cadet McFly explained how a recursive function worked conceptually, using diagrams and the assignment materials. He did not look at my code nor did I look at his code during this discussion.
Bad Example: : Cadet McFly helped fix my factorial() method.
Good Example: Cadet McFly helped fix my factorial() method by looking at my code** and finding that I had n > 0 instead of n >= 0 on line 85. Note: A situation such as this may result in **less than full credit for the factorial() method, but due to the documentation statement there is no violation of the honor code.
Bad Example: : Cadet McFly and I worked together on the factorial() method.
Good Example: Cadet McFly and I worked together on the factorial() method, each contributing equally to its development. Prior to this help, neither of our factorial() methods was working. My factorial() method is now nearly identical to Cadet McFly’s factorial() method. Note: In a situation such as this, at most half-credit would be earned for the factorial() method, but due to the documentation statement there is no violation of the honor code.
Bad Example: : Cadet McFly showed me how the factorial() method works.
Good Example: Cadet McFly showed me how the factorial() method works by letting me look at his code. Prior to this help, my own factorial() method was not working. My factorial() method is now nearly identical to Cadet McFly’s factorial() method. Note: In a situation such as this, no points would be earned for the factorial() method, but due to the documentation statement there is no violation of the honor code.
Bad Example: : Cadet McFly showed me how the factorial() method works.
Good Example: Cadet McFly showed me how the factorial() method works by looking at my code and talking me through each line as I wrote it. Prior to this help my own factorial() method was wrong. My factorial() method is now nearly identical to Cadet McFly’s factorial() method. Note: In a situation such as this, no points would be earned for the factorial() method, but due to the documentation statement there is no violation of the honor code.
🧩 Miscellaneous#
This course is designed to help in your development as a computer or an electrical engineer. As such, we introduce economic considerations as well as manufacturability and sustainability during the first half of the semester and re-emphasize these as we progress through the semester. Feel free to provide feedback on the lessons and labs at any time. If you have ideas to improve or enhance the course, please let me know. The class builds on concepts from the prerequisites so it is important for you to seek help as soon as you need it. Procrastination is truly the enemy in a hardware design course. A little foresight and planning and a lot of effort will result in an extremely rewarding experience serving as the basis for future microprocessor design work.
Course Info
Labs