The company I work for is in a position where we need our hardware group to develop an FPGA-based device to interface with existing hardware. Due to the fact this project is under severe time constraints we didn't want to find ourselves (the software team) in a situation whereby we would only receive our first pieces of hardware very late in the project with almost no time to write the driver and get to know the device.
To alleviate this concern we decided to obtain a number of Mesa 4i68 boards: http://www.mesanet.com/parallelcardinfo.html (you have to scroll down until you find the 4i68) This board comes with a lot of digital IO, a Spartan-3 FPGA from Xilinx, and a PCI bridge chip (the PLX 9054). It's a PC104+ based design but PC104 to PCI adaptor boards are easy enough to come by. The link to the support software includes source code for injecting the FPGA with the contents of a *.BIT file; this code was written for MS environments, but is quite easy to convert (the DOS version is the easiest to work with). Why am I mentioning this? Maybe it would be nice if this project had something similar? That way the software and the hardware could be developed in parallel and any gotchas and provisos can be caught early in the design. Traditionally, hardware and software are developed such that all the hardware work is done, then the software work starts. If something in the hardware makes the software hard to write or is poorly designed from a software point of view (which is an important consideration) it's usually too late by that time and software simply has to "deal with it". There are several instances on this list where Timothy will ask the software people their opinion on some matter, and there tends not to be very much response. Sometimes it's hard for software to become deeply involved in the "development" of a project which exists exclusively in the mind. For our project, both hardware and software started off at the same time, at the same point. Both teams work a little bit on the interface document, then the hardware teams creates a *.BIT file for us to work with, we inject it into the device, and update our driver and software with the new functionality. Our first iteration consisted of a *.BIT file and the corresponding device driver for turning the 4 on-board LEDs on and off (the "Hello, world!" of the hardware world! :-). At the same time, they are developing our actual hardware. Once our real hardware becomes available we should simply be able to switch everything to the new board and everything should continue to work; anything that doesn't would point to a flaw in the new device. Having the separate PCI bridge chip ensures that we'll never end up in a situation where we've lost our hardware. Even if the FPGA code is completely messed up or the driver does something completely wrong, we can always simply re-inject a new *.BIT image and try again. It's a wonderful, synergistic design/development cycle that is highly beneficial for both sides and, in my opinion, it would be nice if this model could be adapted to work with this project as well. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
