This document is written under the assumption that you would like to minimize debugging time. Minimizing debugging time requires thought, effort, hard work, and being well rested. You may be able to get your project working by spending lots of time and trying random things without thinking very hard. (If you would prefer not to think in depth about your design, this document won't be very helpful to you).
Before starting your next session of simulating and debugging, re-read Synchronous Design Rules. Sure you just read them before your last session, but hasn't your design changed a little bit? Did that quick fix your partner put in on page 7 without telling you violate one of the design rules?
There is no point trying to debug your design if you
violate any of the Synchronous Design Rules listed below. In past semesters
students have said things like
``I know I am not supposed to have coupled Mealey machines
``I am just trying to get this module working first, then I will fix it'' or
``I am too busy/tired to take care of that now''.
Hardware won't let you get away with this approach. Poor software debugging techniques, such as changing a line of code, recompiling, praying, and seeing what happens, won't get you very far, because in hardware, local modifications aren't necessarily local.