<p>Design Review Checklist Rev. 1.1 Page 1 CS-EE 480, Fall 2006</p><p>Design Review Checklist</p><p>CS-EE 480 Fall 2006 Directions</p><p> For each major checklist section (General, Software, Digital, Integrated Circuits, Control Systems), o Determine what collateral material will be prepared for the meeting and sent to the Industry Representative. Bring to the meeting all documentation needed to explain and justify your design decisions. o Review each item in the checklist for applicability and mark that field with a checkmark ().</p><p>NOTE: Not all items will be applicable to every project. If an item is not applicable, you may wish to enter an explanation in the comment field.</p><p> Add additional applicable checklist items using the Other field.  Review each applicable item in the checklist and verify that it has been met by your design. Mark the checked field with a checkmark ().</p><p>NOTE: An applicable item can only be verified or not verified (Boolean). You cannot have an item that is one-half verified.</p><p> Use the comment field to add information that elaborates on your decision to mark or not mark an item as checked.</p><p>Follow-Up</p><p> Prepare meeting minutes of your Design Review and post them along with the completed checklist on your web site.  Your design review is: Approved, Conditionally Approved, or Not Approved.</p><p>Approved: all checklist items verified. Conditional: one or two minor checklist items not verified (but easily fixed). Not Approved: major or several minor checklist items not verified.</p><p> Any applicable item not checked off may be grounds for not approving the design.  All applicable items not checked off require an Action Item with responsible individual and due date.</p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 2 CS-EE 480, Fall 2006  Conditionally Approved or Not Approved design reviews must be rescheduled and all non-verified items reviewed.</p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 3 CS-EE 480, Fall 2006</p><p>General Requirements</p><p>Collateral Material: situational and varies with technologies.</p><p>Applicable Description Checked Comments</p><p>Economic 1. Have all economic constraints been considered in the design? 2. Other</p><p>Environmental 1. Have all environmental constraints been considered in the design? 2. Other</p><p>Sustainability 1. Have all sustainability constraints been considered in the design? 2. Other</p><p>Manufacturability 1. Have all manufacturability constraints been considered in the design? 2. Other</p><p>Ethical 1. Have all ethical constraints been considered in the design? 2. Other</p><p>Health and Safety 1. Have all health and safety constraints been considered in the design? 2. Other</p><p>Social 1. Have all ethical constraints been considered in the design? 2. Other</p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 4 CS-EE 480, Fall 2006</p><p>Software Systems</p><p>Collateral Material  A pictorial representation of the architecture.  Traceability tables relating system components and data structures to software requirements.  Descriptions of data structures that are passed among components of the software or that are available to major portions of the architecture, including interim files. These might include: o UML or ER diagrams. o Data flow diagrams. o Database descriptions.  Descriptions of each component. These might include: o Processing narratives. o Description of input and output interfaces. o Algorithmic descriptions (activity diagrams, flowcharts, pseudocode, etc.). o Test cases needed to verify that the algorithm works and expected outcome for each case.  Descriptions of each user interface (screen, physical panel, voice, etc.). These might include: o Prototype (actual or paper) or screen image from the user point of view. o Interaction description (use cases, action sequence diagrams, swimlane diagrams, etc.).</p><p>Checklist</p><p>Applicable Description Checked Comments</p><p>General 1. Does the overall design implement all explicit, implicit, and Priority Level 1 requirements? 2. Does the design incorporate reusable abstractions and components? 3. Has the software architecture been partitioned for ease of implementation and for specific owners? 4. Have information hiding and functional independence been used throughout the design? 5. Are limitations or restrictions of the design identified? 6. Other</p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 5 CS-EE 480, Fall 2006 Applicable Description Checked Comments</p><p>Data Design 1. Have data objects defined in the analysis model been translated into appropriate data structures? 2. Do the data structures contain all attributes defined in the analysis model? 3. Have any new data structures and/or attributes been defined during design? If so, is their relationship to the analysis model and to overall user requirements clearly identified? 4. Can each data structure be implemented directly in a programming language? 5. Are data communications between software components defined? 6. Is a database to be used as part of the solution? If so, have all fields and keys been identified for each table, and has the expected size of each table been estimated? Have high-use and high- volume queries against the database been identified? 7. Other</p><p>Architecture</p><p>1. Have other architectures been considered, and has an architectural trade-off analysis been performed? 2. Is the software architecture a recognizable architectural style or does it match a design pattern? 3. Has the architecture been exercised against existing usage scenarios? 4. Has the analysis model been translated into the architectural model? 5. Other</p><p>User Interface Design 1. Have goals for each user task been identified? 2. Has an action sequence been defined </p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 6 CS-EE 480, Fall 2006 Applicable Description Checked Comments</p><p> for each user task? 3. Have various states of the interface been documented? 4. Has a prototype or layout for each interface been developed, including messages? 5. Have objects and actions that appear within the context of the interface been defined? 6. Have expert and novice modes of interaction been defined? Have administrator versus normal user modes been defined? 7. Have technical internals been hidden from the causal user? 8. Does the interface adhere to a consistent and standard convention for behavior and appearance? 9. Are icons and labels clear and understandable? 10. Are available user actions clearly indicated in every state? 11. Has a help facility been included in the design? 12. Are error messages helpful and easy to understand? 13. Other</p><p>Component-Level Design 1. Has each algorithm been “desk-tested” to uncover errors? Is each algorithm correct? 2. Is the design of the algorithm consistent with the data structures that the component manipulates? 3. Have algorithmic design alternatives been considered? 4. Has the complexity of critical algorithms been computed? 5. Have structured programming or object-oriented constructs been used throughout each component? 6. Other</p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 7 CS-EE 480, Fall 2006 Applicable Description Checked Comments</p><p>Test Plan 1. Does the overall design provide sufficient information for test case design? 2. Are tests specified in as much detail as is possible at this stage? 3. Are the expected results specified for each test? 4. Have critical components that will demand particular attention during testing been identified? 5. Other</p><p>Performance 1. What is the critical path? Does it support required latency and throughput? What are the margins? 2. Have potential bottlenecks been identified? 3. Is system response time consistent across all tasks? 4. Other</p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 8 CS-EE 480, Fall 2006</p><p>Digital Systems</p><p>Collateral Material  System-level block diagram.  B2Logic schematics & simulation traces.  Spreadsheet with DC (fan-out/in) and AC (setup/propagation/hold times) analysis.  Spreadsheet with power requirements analysis.  Finite state machines: state diagram, next state table.  Programmable logic (PAL, CPLD, etc.) source code.  Controller (PIC) pin definitions.  Controller software: initial conditions, data structures, interrupt definitions, and flow charts.</p><p>Checklist</p><p>Applicable Description Checked Comments</p><p>Architecture 1. Are all aspects of the requirements document (i.e., Functional Spec.) addressed in the design? 2. Is the architecture well defined and understood? 3. Are the inputs and outputs well defined and understood? 4. Are the interfaces between major blocks well defined and understood? 5. Are there any industry standard interfaces? If so, has the design been checked for compatibility? 6. Are all cables and connectors well defined and understood? 7. Other</p><p>DC Analysis 1. What voltages, currents, and regulation must the power supply provide? 2. Are there any logic level transitions? If so, have the logic level shifter circuits been thoroughly analyzed, simulated, </p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 9 CS-EE 480, Fall 2006 Applicable Description Checked Comments</p><p> or prototyped? 3. Can each output drive its load (fan-out)? What is the margin? 4. Other</p><p>AC Analysis 1. Is the power-on or reset state well defined and understood? Are all flip-flop elements reset? 2. Are there any asynchronous logic circuits? If so, have they been analyzed, simulated, or prototyped? 3. Have all setup times been analyzed, simulated, or prototyped? What is the margin? 4. Have all hold times been analyzed, simulated, or prototyped? What is the margin? 5. Any signal integrity concerns (overshoot, undershoot, cross- talk)? Have they been analyzed, simulated, or prototyped? 6. Are all finite state machines well defined and understood? Are the state transitions adjacent to avoid glitches? 7. Other</p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 10 CS-EE 480, Fall 2006</p><p>Integrated Circuits</p><p>Collateral Material  System-level block diagram showing embedded IC’s.  IC block diagram.  B2Logic schematics & simulation traces.  Listing of .edf file  Pin definitions: inputs, outputs, power  Finite state machines: state diagram, next state table.</p><p>Checklist</p><p>Applicable Description Checked Comments</p><p>1. Do "paper" digital chip circuit block diagram design. (Note: only 40 pins are available including power/ground and that this is a 5V CMOS technology. Do synchronous design only !). 2. Do "paper" digital chip circuit design (as much as possible). 3. Do B2Logic digital chip circuit simulation using B2Logic/BLT software. 4. Do design review/release of finalized B2Logic digital circuit design. 5. Create initial .edf file in B2Logic/BLT and email to Dr. Osterberg asap in early November. He will then run a preliminary BLT and SPR in L- EDIT. If chip properly fits within 2.2mm x 2.2mm (or 4.6mm x 4.7mm) standard padframe, then Dr. Osterberg will give you the greenlight to proceed to Step 6. If chip does not fit in one of these padframes, then he will return .edf file to you with suggestion on how many gates to remove in order to reduce size of chip and then GOTO step 3.</p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 11 CS-EE 480, Fall 2006 Applicable Description Checked Comments</p><p>6. Create final .edf file and email to Dr. Osterberg who will then re- run BLT and SPR in L-EDIT. Again, if chip properly fits within 2.2mm x 2.2mm (or 4.6mm x 4.7mm) standard padframe (which, of course, it sould due to Step 5) then Dr. Osterberg will, himself, go on to create .cif file and send onto MOSIS. Of course, if chip does not fit in one of these padframes, then he will return .edf file to you with suggestion on how many gates to remove in order to reduce size of chip. GOTO Step 3. Again, note that the odds of failure here is low due to Step 5. 7. Decide on how you wish to build your discreet macro-model (i.e.: CPLD, wire-wrap, plug-and-go protoboard, etc). Note that I suggest CPLD, but it's up to you. 8. Order your macro-model parts including devices, boards, wire- wrap gun, wire-wrap wire, etc. 9. Build and debug your macro- model. 10. Build and debug your overall project system using your macro- model. 11. Receive MOSIS chip. 12. Replace macro-model with chip in system and verify functionality (or not). 13. If chip works, hurray. If not, then just use macro- model in your system and demo with it.</p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 12 CS-EE 480, Fall 2006</p><p>Control Systems</p><p>Collateral Material  Feedback block diagram.  Transfer function.  Spreadsheet with power requirements analysis.  Matlab loop gain/margin analysis.  Matlab step and frequency response plots.</p><p>Checklist</p><p>Applicable Description Checked Comments</p><p>Architecture 1. Are all aspects of the requirements document (i.e., Functional Spec.) addressed in the design? 2. Is the transfer function of each component well defined and understood? 3. Has the system closed loop transfer function been defined? 4. Has the classic feedback diagram been constructed? 5. Has the feedback circuit design been completed? 6. Other</p><p>Stability Analysis 1. Are the physical dynamics of the system well defined and understood? 2. Has the step response analysis of the closed loop transfer function been completed in Matlab? 3. Has the margin analysis of the loop gain been completed in Matlab? 4. Other</p><p>AC Analysis 1. What voltages, currents, and regulation must the power supply </p><p>School of Engineering University of Portland checkList06.doc Design Review Checklist Rev. 1.1 Page 13 CS-EE 480, Fall 2006 Applicable Description Checked Comments</p><p> provide? 2. Other</p><p>School of Engineering University of Portland checkList06.doc</p>