So here's my question: What existing open source projects are there
for creating the data files for FPGA's without using the vendor's
software?

I've got a spartan-3e starter board. Suppose I wanted to program the
3e without using Xilinx's software, is it even possible?

You can synthesize your design without Xilinx software using Synplify or
something else, evaluating your design with GHDL, but there is no
open-source software for synthesis.

All we have today is the limited performance of FPGA EDA tools
because
of its closed source nature.
Regards,
Vadim Kataev

Does Xilinx document their data file for their chips? Suppose I wanted
to write a place & route program to generate the datafile, it'd be
possible if I knew the format and how the bits all get ordered on the
device.

Thanks--
Dave

_______________________________________________ http://www.opencores.org/mailman/listinfo/cores

As far as I know, the details of the datafile formats are kept secret by
the FPGA vendors (maybe with the exception of some very old device
families).

--- On *Mon, 7/28/08, Gunnar Dahlgren /gunnar.dahlgren at axis.com>/* wrote:

Hello!

Do you know a few such old devices, with their file formats published,
or at least reverse engineered in a clean room fashion? Even if they are
old, they could still be interesting...

Andrew

--- On *Mon, 7/28/08, Gunnar Dahlgren /gunnar.dahlgren at axis.com>/* wrote:

Hello!

Do you know a few such old devices, with their file formats published,
or at least reverse engineered in a clean room fashion? Even if they are
old, they could still be interesting...

Andrew

Andrei Purdea wrote:
I was thinking of the XC6200 family from Xilinx. It has probably been discontinued since long, there is no mention of it on Xilinx website. I didn't manage to find the datasheet on the web either. Anyone got a paper copy of Xilinx 1996 "the programmable logic databook"? :-) It is said to be there... Further, when thinking more of it, I'm not sure if the data format was actually documented, or if the FPGA just had the special feature of being "random-config-file-safe". I.e. it was not possible to burn the FPGA by presenting an incorrect config file to it. This feature made the FPGA useful to some guys experimenting with "evolutionary algorithms" for automatic, genetic hardware design. Quite cool. :-) See e.g. http://www-verimag.imag.fr/PEOPLE/Nicolas.Halbwachs/SYNCHRON03/Slides/girault2.pdf

I think it would be much more useful to work on software for the
other portions of the design process, synthesis, simulation and
debugging tools.

On Wednesday 30 July 2008 21:43:08 Rick Collins wrote:


Synthesis seems like a good idea. It seems to be lacking at the moment. Most
FPGA vendors have free synthesis tools that only work on their own target
technology. Their support for various language inferences is also different
from vendor to vendor. The ASIC vendors rely on existing EDA tools.

A generic open source synthesis tool that works for different FPGA and ASIC
technologies would be very useful. It is also do-able. There is enough
information available to do it. I'd be interested in doing it.

> A generic open source synthesis tool that works for different FPGA and
> ASIC technologies would be very useful. It is also do-able. There is
> enough information available to do it. I'd be interested in doing it.

On Wednesday 30 July 2008 21:43:08 Rick Collins wrote:
Synthesis seems like a good idea. It seems to be lacking at the moment. Most FPGA vendors have free synthesis tools that only work on their own target technology. Their support for various language inferences is also different from vendor to vendor. The ASIC vendors rely on existing EDA tools. A generic open source synthesis tool that works for different FPGA and ASIC technologies would be very useful. It is also do-able. There is enough information available to do it. I'd be interested in doing it. -- with metta, Shawn Tan Aeste Works (M) Sdn Bhd - Engineering Elegance http://www.aeste.net _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Shawn Tan Ser Ngiap wrote:
To do that a cell library is needed and it is needed for each individual device. A library must be present for the the last stage of compilation or synthesis. Compilers need the opcodes for the target processor (for linking) and the synthesizer need the physical cell library (which is a lot). For example -- the difference between the web version of the ISE and the Foundation ISE are the available device libraries. This is probably the problem with the verilog tool mentioned here. However, if that verilog tool source is available that's a good beginning. No FPGA copany and no ASIC fabricator will relese their cell libraries - not even if you are Cadens or Mentor - you can pay 200K for one of their tools and you still have to use the device vendor tool to "link" it (using a software term). There is a whole economy built on it. It may seems unfair but when you get millions of gates which you can plug into your computer with an automated design tool (which must be maintained) it is not even clear if this model can survive very long. But there is a way to deal with it in the open community and even take it places the industry does not go. We can create our own cell libraries. Someone mentioned here the 6100 or 6200. It had a very "flat" structure called "Sea of Gates" on which some companies built dynamically configurable computing and that frighten the FPGA industry and the product was taken of the market. It is all about the cells. Cells are everything because they defined what the device can do. Like opcodes in a CPU. There is a way to create, experiment and package individual cells. You do that by building it, synthsizing it, tsting it, documenting it and if you want to take the extra step, seperating it from the data bit file. If the source for the verilog product is available you can then build a device library and accumulate whatever you need. Notice that it is probably legal to do that only with cells you created yourself. In fact even that need to be checked because of the last step. But it worth looking at it if you have some good libraries in mind and there are directions the industry is very reluctant to go. FPGA can be much more efficient. Any one into cells? -- View this message in context: http://www.nabble.com/Open-Source-creation-of-FPGA-data-files--tp18310516p20745236.html Sent from the OpenCores - IP Cores mailing list archive at Nabble.com. _______________________________________________ http://www.opencores.org/mailman/listinfo/cores