Xilinx FPGA bitstream

[Unixon]

Are you saying that:
1) There is no way that a badly constructed bitstream can cause harm to an FPGA
2) That a place and route process can't turn a valid logical design into a design with reliablity issues - for example failed timing for paths, metastability issues, chip-level hot spots, dodgy startup states, clock skew over reset networks, flakeyness due to carry chain length issues, voltage and temp corner cases and so on...

I'm saying that both of these issues has nothing to do with reliability of an FPGA itself. A hardware designer that puts an incorrect bitstream into FPGA can have reliability problems with his design, but this is unrelated to the FPGA chip. If somebody wants to fry his FPGA with flawed configuration he has all rights to do so.

And speaking about the reliability of an FPGA... I wouldn't consider reliable an architecture of FPGA that allows a badly constructed bitstream to cause a malfunction or lead to irreversible changes in the die.

and likewise you should allow FPGA manufactures to keep their bitstreams closed if they want to.... they don't have to share the results of their R&D with you.

I don't mind them having protection mechanisms, including encryption, that make it impossible to readout a customer's configuration - that's totally OK, I appreciate that, but closing the architecture specs for this purpose is an overkill.

[andersm]

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.

Have you reviewed the existing research on the subject (eg. http://www.isi.edu/~nsteiner/publications/soni-2013-bitstream-fccm13.pdf)?

[Unixon]

Have you reviewed the existing research on the subject (eg. http://www.isi.edu/~nsteiner/publications/soni-2013-bitstream-fccm13.pdf)?

Oh, thanks. Haven't seen this paper.

Quickly browsed through pages... the theory look OK, but I didn't get it clearly from a first glance to what degree this is applicable to real FPGAs I intend to experiment with. Have to read this slowly and carefully

[mikeselectricstuff]

I don't beleive that FPGA manufactures want to the reliability and performance of their hardware product to be determined by the quality of homebrewed synthsis software.

The reliability of an FPGA is only determined by the reliability of bare silicon, it has nothing to do with bitstream, firmware or whatever other software a product user may want to run on this underlying hardware.

Rubbish.
It also depends heavily on the accuracy of the timing model. A toolchain that doesn't get this right could easily produce designs that are marginal and  risk failing over temperature or part-to-part variation

[mikeselectricstuff]

I would never trust a tool I can't verify myself and all commercial tools are not verifiable as they're closed, hence all commercial tools are much more untrusted no matter what resources a manufacturer had put in verifying the product, it is virtually zero as I can't verify that myself.

The FPGA toolchain  is too complex for pretty much anyone to understand, let alone verify.
If you don't trust anything you can't verify yourself then you'll just have to live in the stone age and not use any modern technology.

[Unixon]

It also depends heavily on the accuracy of the timing model. A toolchain that doesn't get this right could easily produce designs that are marginal and  risk failing over temperature or part-to-part variation

This is true in respect of a particular design, not the FPGA. A poor design may fail for any reason, but the FPGA doesn't care if it does, it will just process signals under provided configuration.

If you don't trust anything you can't verify yourself then you'll just have to live in the stone age and not use any modern technology.

Nope. This only means you don't have to trust in something to use it.

[Balaur]

It also depends heavily on the accuracy of the timing model. A toolchain that doesn't get this right could easily produce designs that are marginal and  risk failing over temperature or part-to-part variation

This is true in respect of a particular design, not the FPGA. A poor design may fail for any reason, but the FPGA doesn't care if it does, it will just process signals under provided configuration.

This is not what Mike said.

The toolchain (especially on the synthesis and timing analysis part) will have to meet timing constraints that you may have set. This happens through logic, placement and routing choices and optimization that are obviously dependent on 1) the FPGA architecture and 2) the physical characterization data that the tools use for the timing/power analysis.

For the overall process to be successful, several requirements must be met:

- the synthesis is successful, i.e. your synthesis tool managed to translate some kind of High-Level Synthesis (HLS) design representation - it may be RTL or block-level schematic or whatever to the exact LUT/CLB/VersaTile your FPGA may have. This is not trivial

- the placement of the cells and the routing of the signals is successful

- if you have a time-constrained design (i.e. it needs to work at a given frequency), you will have to trust that the tools from the design flow managed to fulfill your constraints. Failing that, you need to look at the report from timing analysis tools to work around the actual performance you get. This is the part that Mike discussed. If the tools are not good or if the primary silicon data they use is not accurate, their analysis may be wrong. Your design may work, almost work at 156.25 MHz required for your 10Gb Ethernet or fail miserably when some particular condition is met, causing a lot of headaches.

[Unixon]

We argued mostly about the terminology. I understand what you mean, but this is related to the reliability of a design, not the reliability of an FPGA. I agree, that a toolchain that doesn't do project verification well enough may produce poor configuration even from a perfectly designed project sources. My point is that while these issues may affect the reliability of a design and a product where that design goes to, under no circumstances we can say that it affects the reliability of the FPGA we used since the FPGA chip itself doesn't care what we put into it.

Even if a trusted toolchain is used, we can't tell that it OK, unless the product is tested under all possible conditions.

My other point was that since it is the product testing procedures that decide if it works as intended or not, we may use toolchains of any level of trust, those that fail will just drop out of competition.

[mikeselectricstuff]

My point is that while these issues may affect the reliability of a design and a product where that design goes to, under no circumstances we can say that it affects the reliability of the FPGA we used since the FPGA chip itself doesn't care what we put into it.

What's the difference?
It is impossible to use an FPGA without design software. If that design software does not accurately know about the timing behaviour of every part of the device, it can produce a bitstream that doesn't work reliably, and you won't necessarily know until you start seeing field failures, or designs that fail on some chips but not others . This is to all intents and purposes indistinguishable from bad hardware.
This is a completely different scenario to a processor, which if clocked within spec is guaranteed to execute any code under all circumstances.

[Unixon]

What's the difference?

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.
If a design is bad, you are to blame the designer that made it.

While these may become indistinguishable in a hardware, it is not a good practice to blame ones for other's faults.

[Bassman59]

The thing is that as a company you have to understand that they want their customers to feel safe with their investments without worries.

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?

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]

If an open source FPGA architecture would be available off-the-shelf

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]

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.

XC6200, long since discontinued.

[mikeselectricstuff]

What's the difference?

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.

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/

[marshallh]

Friend of mine has reversed the Coolrunner II architecture. It's a simple CPLD.  Let me know if you want  more info.

But really, there is no point in whinging about no open source alternative, when the OSS guys themselves tell us closed source fools "if you want it so bad just make it yourself".