Documentation To-Do

• Finite state machine interface specification (Ben)
• Cross-reference test plan with requirements document (Tom)
• Overall system tests and unit tests in acceptance test plan (Jeff)
• Draft GUI class design for design document (Ben)
• Custom test bench documentation in requirements and acceptance test plan (Tom)
• Acceptance test plan to LaTeX (Jeff)

Presentation To-Do

• Background of project (Tom)
• VHDL and sysarc background information
• Purpose of project
• Related products
• GUI Walkthrough (Ben)
• How users interact
• Screenshots
• Component Abstraction (Jeff)
• "Blackbox" concept overview
• Component generation
• Algorithmic
• General
• Design Methodology (Iris)
• Development schedule overview
• Discussion of development model

Requirements Document Status

• Requirements document has near-completed GUI section
• Iris is working on Use Cases
• Other aspects of requirements document have remained unchanged

For Tuesday's Deadline

• Add Iris's use cases to requirements document draft
• Remove stubs for "to-do" from the draft
• Submit requirements document draft to BBVista

Post-submission Requirements

• Finish use case section
• Add use cases to the "to-do" stubs
• Provide graphical representations of use cases
• Finish GUI section
• Create diagrams of dialogs for component properties
• Update functional and nonfunctional requirements
• Fill in all stubs
• Elaborate on requirements where applicable
• Review document
• Ensure that requirements are consistent with GUI design
• Ensure that use cases cover all specified requirements
• Check spelling and grammar
• Resubmit document to Dr. Johnson

Acceptance Test Plan

• Tom to begin work on draft
• Develop testing scenarios from Iris's provided use cases
• Update document as Iris updates use cases

• Dr. Johnson skimmed the draft of the requirements document
• The group discussed a user scenario, for gaining better understanding of the project
• Moving meetings to Monday at 10am, instead of Friday

About the Requirements Document

• Use a sample requirements document
• See the Senior Design website (sample Requirements Documents from last year)
• Needs to be polished for the requirements presentation early next quarter

About the Abstract

• gate level + higher level components
• "blackbox components" --> make your own, or use the library
• data memory
• registry file
• clock
• how it all fits together
• what we want to emphasize
• how to do control? a state machine or mini-language
• look through the SysArch textbook

Post-Meeting

Where we discussed a scenario involving a full adder

• http://www.cs.drexel.edu/~wmm24 for SysArch lecture notes/graphics
• Double-click an item to view it
• If you double-click a blackbox in view mode, focus in on those details
• Up/down hierarchy
• If an item is not viewable (not made in our program), then display VHDL code
• Right-click to modify an item
• Copy/paste functionality
• Undo/redo: at least 6 undo stack
• Default ALU has every option enabled
• How many registries in the registry file?
• Structural view- how do we get to it
• all dynamics
• Implement functionality for the SysArch assignments

For next meeting

• (3 or 4) user scenarios: Iris
• requirements document: Jeff
• specs for library components: Tom
• GUIs: Ben
• Add meeting minutes to the website

fPGA

field programmable gate array

• 4-input lookup table
• flip-flop (store)
• interconnect --> millions of logic styles
• block RAM (registry)
• multiplier units
• carry propagation logic
• 64 floating input units

Hardware Design

• timing errors- debugging tools aren't great

What would be nice

• how it all fits together
• plug-and-play
• converts to VHDL with correct logic
• a set of usable components (ideally parametrizable)
• existing visuzalization tools
• ModelSim
• N-bit adder (parameterizable)
• hierarchically open up --> levels are good!
• low overhead production (entrypoint to use)
• metrographics/modelsim takes a long time to learn

For next meeting

• Update project dewscription
• agree on this
• then work on system requirements
• team lead + docs + testing
• break it up
• how to make sure stuff is done
• website- wiki, something