Chapter 3: 3.1, 3.2 (do this using theorems, as stated, but ALSO do it using K-Maps), 3.39, 3.51 (pp. 186, 187, 193, 195).  Undergrad students can omit problem 3.51.

Chapter 5: 5.3, 5.4, 5.5, 5.6, 5.7, 5.15, 5.18, 5.20a.  Everyone does all of these.  Many of these are written answers, in your own words.  I want to make sure everyone has the basics before we move more deeply into high-level design.  Please write clearly (or type your answers to these questions).  Submit as hardcopy only, on due date.

Chapter 6: 6.3 (do for both State Diagram and ASM Chart, so you will have two versions of the model), 6.6 (You may not need all of the steps laid out in Problem 6.4, only those which are relevant to design the model, namely Steps 1-12 on page 354, but target D-Flip Flops only; also develop the model for both State Diagram and ASM Chart), and 6.10 (State Diagram and ASM Chart, in addition to block diagram).  Note that these state machine models are very basic, and incorporate no data path directly into them.

flowHDL Design Modeling: UART Example.  Using Lecture 17-B (Lab) Notes (PDF), also linked from the Lecture Notes page, create the model of the UART using the version shown in the figures in the notes.  You will create a New flow diagram file, create the entries in the Bus Table (which we'll discuss in Lecture 17), and then create the models for each of the threads.  Once created, you'll Compile/Check the created model and insure that there are no errors.  We'll save the simulation of the model for another homework assignment.   The purpose is to get you comfortable using the flowHDL environment to model synchronous sequential state machines and their associated data path.  The flowHDL tools can do more than this, but we'll start with something close to what we've been discussing out of Fletcher.

Fletcher Chapter 6:  6.12 - 6.14, taking the single-mode and multi-mode architectures for the Modulo-6 counter example, create 2 versions of the single-mode model, and 2 versions of the multi-mode model, using flowHDL.  Then take the VHDL-generated output and synthesize in Synopsys.  Once in Synopsys' Design_Analyzer, generate the schematics, carry out optimization, and generate reports for area and timing--thus comparing the 2 architecture styles for each of the two counter types.  Turn in the following artifacts: (1) flowHDL ASM diagram "threads" and Bus Table for signal declarations, (2) Synopsys schematics diagrams for each resultant synthesized circuit, (3) Synopsys-generated reports on area and timing for each design architecture, and (4) an answer to the question: "For each of the given counter architectures, which is them is 'best', in terms of area, and in terms of timing?"  Show support by plotting the choices for each architecture on an X-Y chart (similar to the one we discussed for the FIR Filter design back in Lecture 11 Notes, page 16).

Fletcher Chapter 6:  Problems 6.37 (use D-FFs), 6.40 (involves using a Timing Diagram as the design specification), and 6.44 (the Counter to 7-segment LCD display problem--but don't pay any attention to the discussion about available off-the-shelf parts, since we want to design a custom-logic solution). Pages 436-437.

flowHDL and Synopsys Lab (see notes for Lecture 24 for the assignment.

Fletcher Chapter 7:  TBA.

CPU Example #2 (from Carpinelli, Chapter 6).  This is the handout chapter from Lecture 30 (11/6/02), of which I'd like you to create an ASM model (a set of threads) for the second CPU example in the class.  This means you need to model the instruction fetch, decode and execute components of the CPU's work cycle.  You should also plan to simulate several instructions.  Since we discussed using memory in Lecture 31, you can create a flowHDL memory, set up some values for the instructions to execute (i.e., opcode and data) encoded as Hex values in the array locations.  If possible, please turn in simulation waveforms indicating how you verified the execution of your model.  Note that I am not asking for synthesis for this assignment, but, rather, simulation verification results.

flowHDL Project:  This assignment consists of producing the following project deliverables: (1) For your respective project (working with your project team members), you should have a block diagram description of your design.  (2) You should also have a description of the input/output signal interfaces between the blocks, if possible.  If you want to use blockHDL to create the block diagram, see this link.  (3) Finally, you should have identified the major concurrent threads for your blocks (of which you may have one thread per block, or more than one thread per block); you can create abstract state diagrams, on paper, for these thread behaviors, if you like.  (4) Or, if your design is predominately data path, you'll want to draw a dataflow graph for this.  (See Lecture 11 notes on the use of a dataflow diagram with the FIR Filter example); also note the figure on Page 4 of these notes for the sequence of steps I'd like you to be able to move through for this assignment).  NOTE: The intent of this assignment is to pace the project activities, so that you are not caught at the end of the semester without the proper foundation to complete the project work.  NOTE ALSO:  We will spend the remaining lectures discussing the design projects in detail, taking extra meeting time as needed.

flowHDL Project:  For those whose projects consist of creating ASM models of the different project domains, you should have made a first pass through the major portion of the modeling by this date.  You should plan on turning in the following project artifacts: (1) flowHDL output, consisting of design sheets for each of the threads in your design, (2) Bus Table, showing all of your declared signals and buses, (3) A one-to-two page description (in a Word document) of your verification test scenarios, (4) flowHDL simulation output (waveforms) for the test cases you have executed on your design up to this point. (5) Logic Synthesis schematics for the designs, and (6) Reports from Synopsys.  Note, the intent of most of these projects is to devise different data path architectures for the various algorithms that comprise your project.  For others of you, however, the project is an exercise in complex controller design, for which you may need to carry out some analysis to insure you have an optimal architecture.

flowHDL Project:  Revised pass through all the artifacts, with more detailed modeling, and additional verification scenarios tested and simulation output turned in.  If alternate architectures are being considered, then these alternates will need to be synthesized, with schematics and reports due on this date.

flowHDL Project - Due Date:  Projects should be completed by this time.  I will accept project submissions up to the final day of class.  However, you should be prepared to make a presentation of your project results on Wed 11/4 and/or Fri 11/6 (schedule to be posted on Lectures page).   NOTE: if you are planning to leave campus prior to the end of classes, you will need to make arrangements with your team members to present your part of the project.  Work this out with them, and don't leave them holding the bag.  If they complain to me, I'll whack some points off your grade.