Proposal Document
Total Page:16
File Type:pdf, Size:1020Kb
![Proposal Document](http://data.docslib.org/img/e632884c72886d3ab3a05af4d6c162f4-1.webp)
Proposal Document
Team SSEI_FPGA2USB
Nathan Ball (Electrical Engineering) Mark Steddom (Electrical Engineering) David Penick (Electrical Engineering) Norman Heath (Computer Science and Engineering) Douglas Pace (Computer Science and Engineering)
Revision 1.3
December 11, 2000 Table of Contents
1 Executive Summary...... 5 2 Problem Statement...... 6 2.1 Background...... 6 2.2 Business Issues...... 6 2.3 Value of a Technology Solution...... 6 2.4 Business Environment...... 6 3 Product Statement...... 7 4 Requirements...... 8 4.1 Functional Requirements...... 8 4.1.1 The USB interconnect...... 8 4.1.2 The USB Device Driver...... 8 4.1.3 The Demonstration Device...... 8 4.2 Non-Functional Requirements...... 9 4.2.1 The USB Interconnect...... 9 4.2.2 The USB Device Driver...... 9 4.2.3 Software Compilers...... 9 4.2.4 FPGA or Hardware Programming...... 9 4.2.5 Electrical Documentation...... 9 5 Specifications...... 10 5.1 Hardware Specifications...... 10 5.1.1 USB interface device...... 10 5.1.2 The LCD screen...... 10 5.1.3 The GPS unit...... 10 5.2 Software Specification...... 11 5.2.1 USB Driver...... 11 5.2.2 Demonstration Device Software...... 11 6 Cost Analysis...... 12 6.1 Estimated Life Cycle Costs...... 12 6.2 Tangible Benefits...... 12 6.3 Intangible Benefits...... 12 7 Risk Assessment...... 13 7.1 FPGA...... 13 7.1.1 Description...... 13 7.1.2 Possible Resolution...... 13 7.2 EZ-USB Chipset...... 13 7.2.1 Description...... 13 7.2.2 Possible Resolution...... 13 8 Organization and Management...... 14 8.1 Team Roles...... 14 8.2 Management...... 14 8.2.1 Reporting...... 14 8.2.2 Meetings...... 14
2 8.2.3 Attendance...... 14 8.2.4 Personal Conflict...... 14 8.2.5 Decision Making...... 14 9 Design Process...... 14 9.1 Design Philosophy...... 14 9.2 Design Approach...... 15 9.3 Deliverables...... 15 10 Resources and Schedule...... 16 10.1 Budget...... 16 10.2 Schedule...... 16 11 Design Section...... 17 11.1 Overall...... 17 11.1.1 Overview...... 17 11.1.2 Diagrams...... 17 11.2 Hardware Design...... 17 11.2.1 Overview...... 17 11.2.2 Diagrams...... 18 11.3 Software...... 19 11.3.1 Overview...... 19 11.3.2 Diagrams...... 20 11.4 Schedules...... 22 11.4.1 Narrative Highlights...... 22 11.4.2 Gantt Chart...... 22 11.4.3 Pert Chart...... 23 12 Appendix B...... 24 12.1 Schematics...... 24 12.1.1 FPGA_EB1 schematics...... 24 12.1.2 LCD Specification Sheet...... 25
3 List of Tables Table 1...... 12 Table 2...... 16
List of Figures Figure 1...... 17 Figure 2...... 18 Figure 3...... 19 Figure 4...... 19 Figure 5...... 20 Figure 6...... 21
4 1 Executive Summary
We have been presented by Systems and Software Engineering Inc., also known as SSEI, with the task of constructing a Universal Serial Bus (USB) interface to SSEI’s fpga_eb1. We are positive SSEI will not be disappointed in the end product.
We will design and build a superior USB interface for the fpga_eb1 board. SSEI will be rewarded by the following benefits: An increased ability to control the fpga device via the new (USB) computer interface. Greater value to the fpga_eb1 because it will have significantly enhanced capabilities The USB interface will be simple to use on any modern PC, while at the same time having the advantage of full USB capabilities such as hot-swapping. Future proof expandability through the use of driver and firmware revisions.
SSEI will be responsible for any material costs required for this project. Exceptions include: Any materials donated by or on loan from external companies. All resources and materials provided by NAU. All equipment purchased by SSEI will be returned to the company after completion of the project. A detailed list of materials is included in this document. Please reference it for any specific questions.
All time spent by the team on the above mentioned project is free of charge. Any material costs incurred will be reimbursed by SSEI to the respective student(s) in the form of a check after supporting documentation is provided.
5 2 Problem Statement 2.1 Background
Digital Logic is a very important part of most Electrical Engineering and Computer Science curriculums. In today’s age of technology older methods of teaching and prototyping Digital Logic projects can be replaced by newer teaching methods, using products like the fpga_eb1 board created by Systems and Software Engineering Inc. or SSEI. This board allows for many digital logic laboratory experiments and projects to be done without a breadboard or a single copper wire.
2.2 Business Issues
SSEI is currently planning to market the fpga_eb1 to educational institutions, which teach digital logic labs. Currently the product is of the most use in introductory classes. To assist in marketing the product and possibly increase the range of classes in which it can be used we will be providing a new interface. This new interface will utilize USB to communicate with any USB compliant computer. This will hopefully increase sales and extend moneymaking opportunities to SSEI.
2.3 Value of a Technology Solution
Although the fpga_eb1 has many uses without any additions, the current manual inputs to the fpga_eb1 are slow and sometimes difficult to use. Also, because these inputs are buttons, switches and dials, the number of them is limited to the size of the board. To increase the speed and the input options available to users of the fpga_eb1, we must utilize a computerized solution of some sort. Because the fpga_eb1 will already require a computer to design the logic and program the FPGA, the obvious solution is to create a device that will attach the fpga_eb1 to the already present computer. The somewhat obvious solution to this is USB. This will allow bandwidth and speed in excess of what the FPGA can utilize. It will allow hot-swappable operation and ‘plug and play’ detection. This will make utilizing the add-on board extremely simple. Also, software applications can be easily written to take advantage of this add-on board using a straightforward API. All that is required past what we can provide is simply a teacher and a classroom.
2.4 Business Environment
As mentioned above, the fpga_eb1 will be marketed towards educational institutions. Thus the primary users of this product will be students and professors or lab directors. These users will use the system in a variety of different ways.
6 Students could use this system in order to complete a specific set of instructions provided by the laboratory instructor. This will require that the system be easy to use and need little explanation.
The professors will use the system in a completely different way. They will be writing labs, which will utilize the fpga_eb1, and programming simple applications that will communicate with the fpga_eb1. This will require well- documented interfaces and protocols, along with the fpga_eb1 device driver. 3 Product Statement
The project will center on designing and building a Universal Serial Bus (USB) interface for the SSEI fpga_eb1 board. This will include design and implementation of a USB interconnect and device driver developed to handle communications. In addition to this, a way to demonstrate the USB device and device driver must be included that will display the usefulness and workings of the new USB interconnect.
7 4 Requirements 4.1 Functional Requirements 4.1.1 The USB interconnect 4.1.1.1 The USB interconnect device must interface with the SSEI fpga_eb1 board and any USB compliant USB controller. 4.1.1.1.1 It will connect to the fpga_eb1 board using preexisting I/O connections without modification to the existing design. 4.1.1.1.2 The USB interconnect will allow for bi-directional transfer between the fpga_eb1 board and the USB controller on the computer. 4.1.1.1.3 The interconnect will remain separate from any other connections that the fpga_eb1 board may have. This includes the parallel interface used for programming FPGA itself. 4.1.1.1.4 The USB interconnect will have the ability to power the fpga_eb1 using power sourced from the USB controller and delivered to the preexisting fpga_eb1 DC input. 4.1.2 The USB Device Driver 4.1.2.1 The device driver will be written to communicate with USB interconnect and the fpga_eb1 board. 4.1.2.1.1 The USB device driver will conform to USB 1.1 specification. 4.1.2.1.2 The device driver will allow for bi-directional communication from any application on the computer and the fpga_eb1 board. 4.1.3 The Demonstration Device 4.1.3.1 A demonstration device will be built to demonstrate the USB interconnect and device driver. 4.1.3.1.1 This device will consist of a LCD screen, GPS unit and an application. 4.1.3.1.2 The LCD will be used to display information sent from the computer, or information sent from the fpga_eb1 directly. 4.1.3.1.3 The GPS unit will be a modern day OEM GPS system. 4.1.3.1.4 The GPS will be directly connected to the fpga_eb1. 4.1.3.1.5 It will optionally allow for bi-directional communication in order to modify options. 4.1.3.1.5.1 It will send latitude and longitude information such that the fpga_eb1 can determine the latitude and longitude easily and in real time. 4.1.3.1.5.2 The GPS will possibly be replaced during demonstrations with a test program. This will need to be done because of the restraints of GPS in large buildings and limited movement capabilities during presentations.
8 4.1.3.2 The “toy” will include an application that will interface with the fpga_eb1 utilizing the USB interconnect device and the USB device driver. 4.1.3.2.1 This application will optionally render topographical maps to both the computer screen and the LCD attached to the fpga_eb1. 4.1.3.2.2 The application will have the ability to read information from the GPS device and display it to the screen as well as the LCD. 4.2 Non-Functional Requirements 4.2.1 The USB Interconnect 4.2.1.1 The USB interconnect will comply with all industry prototyping standards. 4.2.1.1.1 The USB interconnect will be prototyped on a breadboard if at all possible. 4.2.2 The USB Device Driver 4.2.2.1 All applications and drivers will be developed for primarily Windows based operation systems. 4.2.2.1.1 Windows 98 SE will be the main target. 4.2.2.1.2 Possible additional support may include: Windows2000, WindowME, WindowsNT, Windows95 and Linux. 4.2.3 Software Compilers 4.2.3.1 All applications and drivers will be cross developed using Microsoft Visual C++ 6.0 and Borland C++ Builder 5. 4.2.3.1.1 While this is done, notes and documents will be kept recording the differences between the two compilers. 4.2.3.1.2 With the final deliverable, a comparison of all compilers will be included. 4.2.3.1.3 If support is included for alternate operating systems, other compilers will be used for driver and application development. These compilers will be included in the comparison document. 4.2.4 FPGA or Hardware Programming 4.2.4.1 All fpga based coding will be done using VHDL. 4.2.4.1.1 Altera Programmable Logic Devices (PLD) development tools will be used to develop any and all embedded FPGA based code. 4.2.5 Electrical Documentation 4.2.5.1 All schematics will designed and documented using OrCAD version 9.1. 4.2.5.1.1 Each small device will be separately documented and analyzed. 4.2.5.1.2 As each device is integrated, the interface between the two will be also be documented. 4.2.5.1.3 The final project schematic will encompass all sub-devices at the device interface level.
9 5 Specifications 5.1 Hardware Specifications 5.1.1 USB interface device 5.1.1.1 All USB devices and drivers will conform to the USB 1.1 specification. 5.1.1.2 Utilize typical USB cable (Type A – Type B) to connect to USB host controller as outlined in USB 1.1 specification. 5.1.1.3 Breadboard design will have no size requirements except those imposed by the breadboard. 5.1.1.4 Possible surface mount design will fit within a 6”x6”x3” area. 5.1.1.5 All embedded code included in the USB device will be upgradeable using the USB bus. 5.1.1.6 USB microcontroller 5.1.1.6.1 The microcontroller will have an available I2C/SPI port available for connection to the fpga_eb1. 5.1.1.6.2 The microcontroller must have a minimum of 8 data lines, excluding the I2C/SPI connection. 5.1.1.6.3 Must have the ability to access a minimum of 2Kbytes of memory either internally or externally. 5.1.1.6.4 The USB hardware protocol described in the USB specification 1.1 document is incredibly complex. Thus the microcontroller(or another external chipset) must have the ability to perform the basics of this software protocol internally. 5.1.1.7 The USB bus itself will power the USB device and the fpga_eb1. 5.1.1.8 The USB device will regulate power before delivering it to the fpga_eb1.0 5.1.1.9 A switch included on the USB device will determine the interface to the fpga_eb1. This switch will allow the device to connect to the fpga_eb1 using either a serial or parallel connection. 5.1.1.10 The USB device components are targeted for a total cost for under $30. 5.1.1.11 The USB firmware version number will be available via USB software drivers. 5.1.1.12 Connection status with the fpga_eb1 will be available via USB software drivers. 5.1.2 The LCD screen 5.1.2.1 The LCD screen will utilize a maximum of 10 connections on the fpga_eb1 board. 5.1.2.2 The LCD screen will optimally be black pixels on white background. 5.1.2.3 It will have a minimum resolution of 200 by 200 pixels. 5.1.2.4 It will allow for pixel drawing and optionally include an alphanumeric character driver. 5.1.3 The GPS unit
10 5.1.3.1 The GPS will utilize either the I2C/SPI interface or a maximum of 10 connections on the 20 pin connector. 5.1.3.2 The GPS will support the NMEA protocol. 5.2 Software Specification 5.2.1 USB Driver 5.2.1.1 The USB driver will utilize the format set by Microsoft’s bulk USB driver. 5.2.1.2 The driver will be fully compatible will all USB 1.1 specification. 5.2.1.3 The driver will utilize USB and Plug and Play technology to automatically install itself when the USB device is detected on the bus. 5.2.1.4 The driver will control contention between programs for use of the driver and USB device. 5.2.1.5 The driver will be fully compatible with Windows 2000.
5.2.2 Demonstration Device Software 5.2.2.1 This software will be utilized for demonstration of the USB driver and device working with the fpga_eb1 board. 5.2.2.2 The software will utilize the driver to communicate with both the GPS and the LCD. 5.2.2.3 The software will acquire any data available form the GPS to display position and possibly velocity. 5.2.2.4 The software will optionally have the ability to display topographical maps to display on the monitor. 5.2.2.5 The software will have the ability to display words or pictures on the LCD based on information acquired from the GPS. 5.2.2.6 The software will optionally have the ability to display topographical map data on the LCD screen. 5.2.2.7 The software will be fully compatible with Windows 2000. 5.2.2.8 The software will be designed to utilize Object-Oriented programming.
11 6 Cost Analysis 6.1 Estimated Life Cycle Costs
The upkeep costs on this product can be minimal or expanded to include other services. The minimal upkeep is simply writing firmware revisions and driver updates for the USB interface. Other services can be extended to include technical support, software support for additional systems, specific solutions for laboratory experiment development.
Estimated Costs:
Per Year Life Cycle(3 years) Technical Support Group $100,000 $300,000 Systems Programmer $50,000 $150,000 Lab Instruction Developer $40,000 $120,000
$190,000 $570,000 Table 1
Estimated Life Cycle Costs
These are only estimates and upkeep costs could be taken to zero with the absence of support. And support could be reduced to a minimum which would mean possibly the owner simply answers email when time allows.
6.2 Tangible Benefits
The estimated returns on a product like this are expected to be low. The USB device alone will return very little profits.
6.3 Intangible Benefits
There is a big bonus of offering an item like this. Marketing of the fpga_eb1. This product would allow for demos to be created that would amaze students and teachers alike. It also offers expandability to the fpga_eb1. This means that many professors will see the fpga_eb1 as one that can grow with their institution as the curriculum progresses. Having a highly marketable upgrade like this could be quite valuable in this sense.
12 7 Risk Assessment 7.1 FPGA 7.1.1 Description
The single largest risk is the FPGA and what it is capable of. With little knowledge of FPGAs coming into the project and little time to truly experiment with them, the FPGA is still quite an enigma. There is little known of how much processing the FPGA is going to be able to handle when we begin implementation.
7.1.2 Possible Resolution
We have already begun to reduce the possibility of failure in this area. As the high level architecture has been pulled together, the FPGA has been left out of as much data processing as possible. If necessary the FPGA would act only as a connector between the USB interface and external demonstration devices. The small problem with this, and the only reason this remains a risk, is that the GPS is going to require serial flow control of some sort. All GPS units we have been able to find specifications on, utilize a serial protocol of some sort. Flow control is going to be the biggest challenge of the FPGA. 7.2 EZ-USB Chipset 7.2.1 Description
The next possible risk is the EZ-USB chipset. Since finding this product and understanding its use, little time has been available to research the 8051 language it utilizes. The EZ-USB chipset also expands upon the 8051 language to allow for complex USB protocol operations to be performed automatically. Although this is the reason for choosing this chipset, this still remains a risk. Without knowing more about what is being offered, little can be said about the feasibility and simplicity of writing the firmware for this chipset.
7.2.2 Possible Resolution
At this time little can be done to resolve this risk. Research has yielded that there are several tutorials and code samples that can be used which helps to minimize the risk. Until more time becomes available for more extensive research in this area, this will remain a risk.
13 8 Organization and Management 8.1 Team Roles Mark Steddom – Team Leader Douglas Pace – Communicator David Penick – Secretary Nathan Ball – Treasurer Norman Heath – Researcher, Webmaster 8.2 Management 8.2.1 Reporting A weekly status report will be mailed Monday before 12:00AM. This status report will include minutes from all pertinent meetings, summary of problems and successes for the week, and individual status reports. 8.2.2 Meetings Meetings will be held at 5:30 on Mondays in CET room #317 every week. These meetings will include the CSE members. A weekly conference call will be held every Thursday morning at 7:30 a.m. 8.2.3 Attendance Individuals who do not perform will receive negative peer evaluations. If non-performance continues, advice from the course instructor will be sought. No-shows and tardiness will be handled in the same fashion. 8.2.4 Personal Conflict Personal conflicts are not expected, but if encountered, will be handled by the team leader. The team leader will resolve these issues through meditation and communication. If the team leader cannot resolve a conflict, he will take the issue to Dr. Scott. The team leader will inform Dr. Scott of the issue and they will discuss the situation with all affected parties. If they cannot resolve the conflict, Dr. Scott and the team leader will come to a final decision. 8.2.5 Decision Making Decisions will be made by a unanimous agreement of the team, if this cannot be reached, the team leader will seek the advice of the course instructor and the faculty advisor.
14 9 Design Process 9.1 Design Philosophy
Design, development and testing within each sub-project will be emphasized to maintain stability. System stability would be the major goal in this project. Second to this would be ease of product use.
9.2 Design Approach
To ensure the success of our design philosophy we will iteratively design and test the main project. Each sub-component will also be constantly and iteratively tested and integrated into the main project. This process will verify that each portion of the project will operate in harmony with the rest of the main project. The main project will initially be broken down into two main portions. These will be the software development and the physical hardware design. These portions have many smaller components that will be managed independently, these are:
Software 1. USB Device Driver 2. Demonstration Device Application Software 3. Firmware Development Hardware 1. USB Transceiver I/O Logic 2. FPGA to USB I/O Logic 3. Demonstration Device Hardware Development
These will be accomplished by assigning feasibility research for each component to individuals in the group. Once some of the research is completed tasks will be assigned to each person to start some more in-depth research on specific questions. Component integration and design will take place next semester, but some preliminary design of each component is necessary to specify system level interfaces and create a parts list.
9.3 Deliverables
These documents and products will be delivered at the end of the project according to the schedule that has been attached.
Team Web Site: A common place for team members, client, professor and other users to access the latest information concerning the project. MS Project Schedule: A progressing schedule of tasks concerning the project.
15 Design Requirements Documentation: The standard by which project deliverables will be produced. Design Proposal Document: Final Design proposal agreed upon by client and team. 1 FPGA-USB interface board: Primary hardware deliverable. USB Operators Manual: Technical users manual. This will explain the functionality and layout of the board to any user. Hardware drivers for the USB interface board. These will be written and analyzed in both Visual C++ and Borland C++ if possible. A copy of the demonstration software that will have been developed in both Visual C++ and Borland C++. Analysis document: This will analyze in detail the differences between Visual C++ and Borland C++. Final Project Report: Final analysis of the entire project. Protocol Specification documenting all protocol that were used and developed to complete the project, excluding the USB1.1 that will only be referenced.
16 10 Resources and Schedule 10.1 Budget
Travel Anticipated $0 Phone Paid for by NAU Software MS Office Provided by NAU MS Schedule Provided by NAU MS Visual C++ Provided by Client Borland Builder 5.0 Provided by Client OrCAD Provided by Client Services Synergy Systems loan of a GPS unit Bill of Materials USB Development Kit Donated from Cypress GPS unit Donated/Loaned LCD $30 Misc. Hardware components $17.15 Serial cable (6ft) $2.96 USB cable (2m) $9.95 3 Ribbon cables $2.25 ($.75x3) Voltage Regulator $1.99 Serial EEPROM $0.50 EZ-USB chipset $15 USB type B connector $1.23 Transient Suppressor (sn75240/p) $0.53 Serial EEPROM (24lc00) $0.56 Voltage Regulator (MAX882EPA) $3.24 Crystal oscilator (12MHZ) $1.40 Capacitors (total 3.44*3) $10.32 3 packs of 10 1% accuracy Resistors (total 1.09*3) $3.27 3 packs of 10 1% accuracy Power Connector $1.50 Misc. Ribbon Cables $3.00 Two USB-Ready Computers Provided by Client Table 2
Budget
17 10.2 Schedule See Appendix A.
11 Design Section 11.1 Overall 11.1.1 Overview
Our design will include two major hardware components and two major software components. The hardware components will be the USB board, and the demonstration device. The software components will be the application software to control the demonstration device, and the USB device driver to control the USB board.
11.1.2 Diagrams
Computer External USB board
GPS Demonstration Device FPGA_eb1
LCD Demonstration Device
Figure 1
System Level Diagram
18 11.2 Hardware Design 11.2.1 Overview
The USB board will be comprised of an EZ-USB controller chip and a voltage regulator circuitry. This EZ-USB controller chip will be responsible for the data communication to and from the computer; it will also have minimal support for regulating data to and from the fpga_eb1 board. The EZ-USB chip will handle this data communication and abstract some if not all of the USB protocol allowing for seamless integration to the fpga_eb1. The inbound data from the computer will then be processed and the protocol stripped off before being roughed to the SPI line and then to the fpga_eb1. The voltage regulator will supply the needed 5 Volts to the fpga_eb1 from the USB and will be responsible for maintaining power stability while the device is plugged into the computer.
The fpga_eb1 will receive the raw data sent from the USB board via the SPI line and convert it from the serial format to 8bit parallel format. Both formats will be available to the FPGA programmer. The USB board will also include a power cord that will connect to the standard power input on the fpga_eb1.
The demonstration device will attach to the fpga_eb1 board via the 16 I/O lines located at the rear of the fpga_eb1 board. These lines will control the GPS as well as the LCD screen. The GPS and LCD will be powered by an outside source and will not rely on the fpga_eb1 for any of its power.
All devices will share a mutual ground that will also be included in the data cables between devices. In this manner logic levels will be respective to this mutual ground, and therein protecting against data corruption.
11.2.2 Diagrams
USB EZ-USB Chipset Voltage +5v Common Ground Regulation
SPI [0]
Figure 2
External USB Board Diagram
19 LED [3:0] GPS Receiver Module
Figure 3
GPS Demonstration Device Block Diagram
LED [15:4] LCD Module
Figure 4
LCD Demonstration Device Block Diagram
11.2.3 Schematics See Appendix C.
11.3 Software 11.3.1 Overview
The software design at this point is at a high level stage only. There will be three major portions of the software.
The first component will consist of the USB compliant device driver. The computer will load this program whenever the device is plugged into the computer. The communication between the device and driver will utilize a protocol that is transparent to the application using the device.
The second component is the embedded software that will exist on the device itself. This software will be responsible for sending and receiving any data to or from the computer that the device is connected to.
The third component will be the demonstration application. This application will use the device driver to send and receive data to and from the fpga_eb1. The purpose of this application will be to demonstrate that the device driver and the USB interface hardware are functioning properly. Its complexity and
20 exact function are unknown at this time. This application’s primary purpose will be to communicate in some way with the demonstration device(s) attached to the fpga_eb1. This communication will require an additional protocol to maintain data integrity.
11.3.2 Diagrams Device Application Port USB Host Driver Demonstration Controller Devices
GPS
USB fpga_eb1 Port LCD CHIP EZ-USB
Figure 5
Software Communication Flow
21 Figure 6
Preliminary GUI
22 Appendix A
11.4 Schedules 11.4.1 Narrative Highlights Client contact was initiated 9/28/00 Client contact has been maintained weekly (Every Thursday 7:30am) First class presentation was done 10/16/00 Client status report was completed and sent 10/26/00 Reasearch on microprocessors was completed by 11/20/00 Second class presentation was done 11/20/00 Web page was up and running 11/20/00 Reasearch on USB related issues (especially protocall and selection of chip was done by 11/27/00 Preliminary Budget completed 11/27/00 Draft proposal was completed and sent for review on 11/27/00 Reasearch on Altera 7000MAX chip and VHDL code was done 12/1/00 Final preposal document was completed and sent for approval on 12/7/00 Preposal approval anticipated by 12/11/00
Final testing is yet undetermined. Final demonstration will be on 4/20/01 Design conference will be held 4/20/01
11.4.2 Gantt Chart
23 11.4.3 Pert Chart
24 12 Appendix B 12.1 Schematics 12.1.1 FPGA_EB1 schematics For reference to high level hardware design
25 12.1.2 LCD Specification Sheet
26 13 Appendix C 13.1 Preliminarly Schematic of the USB add-on board
27