Ece241 Project

Recommended Design Techniques for ECE241 Project Franjo Plavec Department of Electrical and Computer Engineering University of Toronto DISCLAIMER: The information contained in this document does NOT contain official grading policy. The information provided here is based on my personal experience with ECE241 course projects in the previous years. Its purpose is to warn you of some common mistakes and answer some common questions student in earlier years had. As grading policies and project requirements change from year to year, please consult course web site or your instructor for official policies. THIS DOCUMENT MAY CONTAIN SOME MISTAKES. I will do my best to point those mistakes to you if I discover any, but I cannot make any guarantees. All information in this document is MY PERSONAL PREFERRED WAY OF DOING VARIOUS TASKS RELATED TO HARDWARE DESIGN. It is by no means the only possible way to perform these tasks. Also, this document does not cover, nor does it attempt to cover all aspects of various problems discussed. Therefore, you should not make any implications on aspects of the problems not mentioned in this document. In other words, if the document states X, and you try to do Y, which is “very similar to X”, do not assume that statements this document makes for X necessarily hold for Y. CHECK YOUR ASSUMPTIONS against your textbook, course notes, your instructor’s and/or TA’s advice, compilation and simulation results from Quartus, and finally, common sense. Verilog and Quartus Issues When using Verilog for the first time in a real project, users are often tempted to use fancy features of the language to make their lives easier. Unfortunately, if one succumbs to those temptations, they usually make their lives harder. The main reason for that is that Verilog, the way it is used in ECE241 labs and the way Quartus II interprets it, is not a programming language. Verilog is a hardware description language, meaning that various blocks of code directly map into