On Thursday 12 January 2006 08:06, Timothy Miller wrote: > Actually, I do recall seeing this. And the reason I didn't reply to > it is, if I understand you correctly, you're suggesting that we do > precisely what we're already planning to do. I guess you could say > that you have an excellent idea. :)
In our case we're using a 3rd-party device that I can go out, buy, and insert into my computer. The device has a PCI-bridge chip on it (PLX9054) which I've already written code for that allows me to inject a *.BIT file into the FPGA. Additionally I've already started a preliminary Linux device driver for it. As I understand it, you are going to be developing your own device from the start and from scratch, therefore nobody can go out right now and buy something that can help towards the development of your device. Additionally your device won't have a PCI bridge on it but instead will require additional, external hardware in the form of an FPGA programmer. Or am I completely wrong on these two points? That is, is there something I can go out and buy right now, install in my computer, start writing the injection code for, and then sit back and wait for you and your team to supply us with new versions of *.BIT files (or whichever format you're using) which we can test by conjuring up some sort of cable from the device's IO pins to some old, secondary monitor? > > On 1/12/06, Trevor <[EMAIL PROTECTED]> wrote: > > On Tuesday 10 January 2006 19:35, Timothy Miller wrote: > > > Developing and testing OGA won't be an easy process. > > > > Hi Tim, > > > > Around Christmas time I wrote the following email to this mailing > > list and was quite disappointed when nobody replied to it at all. > > :-( But then later someone mentioned that the mailing list had > > problems over Christmas, so maybe nobody received it. I'm sending > > it only to you in case others did receive it, maybe it's not worth > > commenting on. I think this is a reasonable solution to help make > > the development and testing of OGA easier before selling and > > shipping hardware with bugs and/or incomplete drivers: > > > > ------------------------------------------ > > 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 for use under > > Linux (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)
