Field Programmable Gate Arrays (FPGA) have long been used to design, prototype, and even replace Application Specific Integrated Circuits (ASIC) for low rate production of digital circuits. The digital circuit perform tasks much more efficient and in most cases faster than a microprocessor could. A particular algorithm such as Fast Fourier Transform could be computed in a few clock cycles in hardware where as doing this in software could take upwards of hundreds of cycles depending on the architecture. The FPGA would provide a flexibility much greater than that of the long extensive design and test cycle of creating a ASIC to perform a particular algorithm since the algorithm can be designed and then uploaded to the FPGA. Now this is a great improvement in flexibility over ASIC but is no where near the flexibility one has when using microprocessors where software can be changed on the fly by loading different application. Combining the advantage of efficiency and speed that FPGA has with the flexibility of a microprocessor allows the users to take advantage of parts of an application that need the flexibility and simplicity of the microprocessor and sending off other parts of the application to the FPGA that are better served by its efficient and timely processing. The FPGA simply acts as a co-processor to the microprocessor accessible in the application. Unlike the old days where a co-processor was limited in what it could, often times for performing floating point operations, or other math functions, the co-processor can be defined by the user enabled by the reprogrammable FPGA. The co-processor could act a image processor, physics engine, video and sound processor, or whatever the user can needs and can think of.
The Fox Brook Lite Development Kit recently created by Intel features an Intel Atom processor and Altera Arria 2 FPGA. The Atom processor and FPGA are interconnected via PCI-e bus. The main goal is to design a standard Application Programming Interface (API) between the FPGA and processor by defining a standard protocol that allows the passing of data and controls between FPGA and processor. This facilitates a very modular design that is independent of the application running on processor and the device defined on the FPGA. The idea will be to have a set of memory addresses that are written to that are read by the FPGA as controls and signals and another range Project Specification 2of addresses for transferring data back and forth. The user defines what the controls are in the FPGA device and likewise uses it in the application to make the FPGA perform work. These ranges will never change and each co-processor design is built around this protocol to ensure a consistent experience.
The end product is a driver for Linux and a Application Programming Interface (API) document which details how the FPGA device should be designed and how software will read and write to/from the FPGA.
The risks are low for obtaining the First Milestone whereas reaching the Second Milestone is much more risky and involves more effort, research, and learning to obtain.
There is documentation provided by Intel that detail about 50% of what is need to obtain the First Milestone. The other 50% is just refining it to this project. The Second Milestone entails a lot more. It involves gaining a better understanding the PCIe interface, the FGPA device and programming suite, and many facets of the Linux operating system such as device driver design and reading / writing to kernel space within user space.
The constraints are listed below:
Decisions will be made on a consensus between Project and System Engineer. The team will correspond with one another via email, telephone, and in person. Also a meeting once per week will be held with Project Mentor. The Project Schedule will be followed as closely as possible and whenever any scheduled items are more than half a week behind the project will be considered off schedule and a re-evaluation will be done of the schedule. Both Project and System engineer will be responsible for all milestones and deliverables as a team. The Project Engineer will be responsible for generation of weekly groups status and System Engineer will post it on the website.
Altera Quartus - Designing and Programming FPGA device
Eclipse / XCode / Vim- Developing software, drivers, and libraries
GCC - Compiling software, drivers, and libraries
Fedora 11 - Linux Operating System for Development Board
Two Solid State Disk (SSD) drives - These are needed as a backup of the Operating System in its current state as configured from Intel so that development can be done without changing baseline. Part of the development will entail upgrading various libraries and the Kernel and experimental changes that sometime will fail and require a quick recovery mechanism.
A meet in the middle test driven development methodology will be used during development. Once core functionality is established regression testing we be utilized on successive iterations of the design.
Engineering log books will be kept during the development phase documenting the process of design, decisioning making, and progress of work that has been done. An Application Programming Interface document will be generated once the project is at a alpha release of readiness.