On 6/25/06, Petter Urkedal <[EMAIL PROTECTED]> wrote:
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.
Typically, they use simulated annealing:
http://en.wikipedia.org/wiki/Simulated_annealing
This derives from simpler "hill-climbing" techniques and is also
similar to genetic algorithms in some ways.
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.
Their willingness to give us information may be influenced by what
we're able to offer them. For instance, if we developed GPL code that
synthesized for their products but told them that they (alone) could
freely derive proprietary products from it, they might bite. They'd
save whatever royalties they'd been paying to whoever developed the
internals of ISE (which is probably not them).
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
