Timothy Miller wrote: > On 6/25/06, Benjamin <[EMAIL PROTECTED]> wrote: > >> I guess I will just run the ISE in it's native environment... the whole >> wine thing is a rather pointless waste >> of time and developer ressources in my opinion, but don't get me started >> on that, and don't answer on this, >> the discussion leads nowhere important for this project ;-)
Another problem with the Wine installation is that it seems require some libraries form a Windows system, so it already requires that we own a Windows license. > > These vendors won't be convinced any time soon to release their tools > as open source. They've probably licensed so many pieces from so many > vendors that it would be impossible. I think it would be good enough with a cheap proprietary version which supports our potential new chip, say up to 300 USD. That's about what I would need to pay to get VMware and Windows, but I'm much more willing to give the money to Xilinx to get a native Linux version. To avoid competing with their full version, they could make a "Bare Essentials" version containing a command-line tools for synthesis and generation of configuration data, and GUI tools for placement and routing; no IDE. It could be compiled for any recent mainstream Linux distribution; we could make a compatibility package with the required versions of the shared object libraries for running on other distributions. > But there is some room for OSS > developers to work on their own. > > Just keep in mind that place and route is NP-hard. :) Yes, NP-hard means "interesting problem". It's typically not only hard for the computer, but also hard to write since there is no viable straight forward solution. I have made a 2nd order logic prover, but this problem might be of a quite different kind. A logic prover never terminate in reasonable time on may problems, and you can't get around that (because it is NP-hard), but a router should always terminate with at least a suboptimal solution (that is, we're not really solving the NP-hard problem). I would guess there is a lot of literature on the topic, maybe even published algorithms. The downside of this option is that we would be very optimistic to think we could make anything usable for the OGA1 development. Also, we would need to know the configuration data format. I can see that the Spartan chip itself is very well documented in "Spartan-3 FPGA Family: Complete Data Sheet", including the configurable ports and nets, except that I can not find any documentation for the configuration data format. Would Xilinx be willing to document this too? I can't see any reason it would expose any trade secrets, since the more important parts are already well documented. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
