Timothy Normand Miller wrote: > On 1/28/08, Terry Hancock <[EMAIL PROTECTED]> wrote: >> Dieter wrote: >>> Someone should write a FLOSS alternative. Unfortunately that is >>> more than an easy Saturday afternoon project. >> >> More than that, wouldn't it require considerable >> reverse-engineering? >> >> My understanding from earlier conversations about this is that the >> interface language used to program the FPGAs is proprietary and >> undocumented, and that's the real reason there's no free software >> tools for programming FPGAs. > > Undocumented and proprietary yes, but probably really not that hard > to figure out. Writing a good synthesizer and dealing with the > NP-complete problem that is P&R are what are difficult about this.
Okay, it's a hard problem, but isn't it a *solved* hard problem? Is the floorplanning algorithm for an FPGA really all that different from the ones used for PCB-layout? Doesn't gEDA or some other project have such code? Or failing that, at least developers with experience with the concepts and AI methods used to do it? > I was talking with someone who had worked for Lattice, I think, who > had some good ideas about how to go about this. Sadly, we're both > too busy to work on it, and finding some people to do the coding for > us isn't likely to happen. Well, if you (or someone) could factor out the problem into the proprietary interface and the abstract P&R problem, write a spec for what the P&R system should take as input and what it should produce as output, that would seem to be the challenging part from a programmer's perspective. If you present programmers with an abstract problem to solve, they're going to be a lot more likely to help than if you start with "first you have to buy an FPGA..." This is the flip-side of something Lourens Veen was talking about: > If you give a programmer a buggy editor as well as its source, she > will fix the editor. If you give a hardware developer a buggy > schematic capture tool, he will find something else to work on. You're in the same quandary if the programmer needs specialized hardware to test her software. If, on the other hand, you can minimize the hardware layer, so that the complex task happens entirely in a separately-testable piece of software, then you've got something more feasible. I suspect it would also have other uses. As a trivial example, self-documentation tools could produce *readable* UML diagrams from code. (HappyDoc could generate UML diagrams from code, but the result is a kind of rats nest -- you have to spend some time manually moving things around to make it readable afterwards). Anyway, this could be at about the level of a university semester project, IMHO. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
