Electronics > FPGA

Xilinx FPGA bitstream

<< < (8/9) > >>

Bassman59:

--- Quote from: Unixon on September 14, 2014, 10:34:24 am ---
--- Quote from: miguelvp on September 14, 2014, 10:25:04 am ---The thing is that as a company you have to understand that they want their customers to feel safe with their investments without worries.
--- End quote ---
That doesn't explain all of it. Why do they need to keep specs closed? They're just selling chips anyway. Why can't they just sell chips with open specs as other companies do?

--- End quote ---
Because they don't want to deal with the support issues, nor the liability issues involved with a customer loading a bad bitstream.
And anyways, none of the FPGA vendors have published their bitstream specs.

Bassman59:

--- Quote from: Unixon on September 14, 2014, 10:16:32 am ---If an open source FPGA architecture would be available off-the-shelf
--- End quote ---

That's never going to happen. Unless there's some compelling architectural improvement, attracting the investment capital necessary to bring the parts into production won't happen. The incumbents are just too entrenched. And an open bitstream is not even on the list of things that matter to most customers.

Bassman59:

--- Quote from: andersm on September 15, 2014, 08:16:05 am ---ISTR reading that a long time ago, Xilinx did publish the bitstream format for one of their devices for use in universities. However in the end this produced very little results, and they stopped the practice because it just wasn't worth the effort.
--- End quote ---

XC6200, long since discontinued.

mikeselectricstuff:

--- Quote from: Unixon on September 15, 2014, 04:16:32 pm ---
--- Quote from: mikeselectricstuff on September 15, 2014, 03:58:23 pm ---What's the difference?

--- End quote ---
If an underlying FPGA fabric is bad, you are to blame the manufacturer of that FPGA chip.
If a toolchain is bad, you are to blame the developer of that toolchain.

--- End quote ---
The problem is that "bad" is not a binary condition. I have no doubt that FPGA toolchains include all sorts of tweaks and fudges to work around or improve issues that are actually silicon related.
If the silicon vendor supplies the tools, there is one point of blame if there's a problem, as soon as you seperate them,  it could get very difficult to figure out who's to blame.

abyrvalg:
Does existense of GCC affect reliability of CPUs in general? What are you guys talking about? If you need reliability - you buy something like Intel C Compiler, ARM Developer Suite (or even something "hardened" from Wind River). If you don't care and just want to go cheap - use GCC (that's another question - how does GCC's quality compares to those commercial's). That's "free market", no?

There are so many other possible points of FPGA failure - cheap unexperienced HDL engineers, cheap PCB designers, fake voltage regulators powering the board etc, why then don't force using all these from FPGA manufacturer too? - this will increase the Holy Reliability! Let's go extreme: don't publish the tools at all, don't publish the pinouts - voila! you'll have a single totally reliable (according to your logic) source of FPGA-based products.

Unixon, check this also: https://code.google.com/p/debit/

Navigation

[0] Message Index

[#] Next page

[*] Previous page