Multiple Independent Circuits on a Single FPGA

Question: Is it possible / feasible / easy to implement a design on an FPGA such that two or more circuits are guaranteed not to share any part of the FPGA hardware?

The application is this: I have redundant inputs and redundant outputs

- I wish to use a single FPGA, but maintain the redundancy. I am concerned only with safety, not with reliability, so complete failure of the FPGA is not an issue.

My concern is that the two circuits, whilst specified independently, would end up optimised and sharing gates, thus compromising the independence.

Reply to
Dioptre
Loading thread data ...

Hi,

Dioptre schrieb:

No problem. You need two independend clock and reset lines. This comes typical to two independend parts of your design. As long as both designs are complete independend and share no IO I would consider it hard to find any possibility to enable some resource sharing.

Of course you need to inspect the used fpga technology if there is any global fpga function like global reset at power up and check wheter this has any influence for your demands. But in general there is no problem bye Thomas

Reply to
Thomas Stanka

Hi, There are certain synthesis constraints that will by default tend to share the resources if the logic involved across 2 set of output lines are identical. The mathematical logic resources are bound by Resource Sharing Option. If you are using the ISE for Synthesis, you can disable this option through the synthesis properties. Another property is Equivalent Register Sharing and this is about sharing flip-flops that are described in the RTL and in the Xilinx Specifif Options of the Synthesis properties, you can disable this property as well to ensure independent use of resources. Similar properties and settings are available for other party synthesis tools as well.

Hope this explanation helps.

regards, Venkat.

Reply to
Venkat

Right. In other words, your timespecs will (likely) come off the clock lines so you will want separate clocks. The issue is the IO. Board vendors are starting to get the hang of banking memory IO properly. Most are still clueless about it on other buses. Invariably your IO for the project will overlap banks, leading to conflicts....

Reply to
Brannon

The technical answer is yes. The practical answer is no. Seriously, think about it for a moment. In the meantime, let me relay a problem that afflicts new PLC (programmable logic controller) designers.

In many safety critical systems, there is a master stop switch. This switch *should* stop everything where it is, and leave the system in a safe place. Many people often make this master stop switch an input to their PLC - which works great, until the PLC fails - which happens. The bottom line? The system is only as safe as the PLC - and there are situations where the system will not react as expected.

Likewise, placing redundant designs in a single FPGA will likely suffice for most situations, but should either the support components or the FPGA itself crap out - both designs will fail. If this is a space application, where you may have to deal with SEU events (single event upsets) or worse - consider that a single bit change to the FPGA configuration memory may render the entire device unusable, especially if that bit controls a common element.

Long story short, if it is critical - use two parts. If it's life-safety (or space qualified) critical - use three parts and implement a voting scheme. If it's not - just do the design once, in a single FPGA. As long as you have done the correct job in design, odds are fairly good that both will fail in the same manner, at approximately the same time, anyway. (this is what happened to a particularly unlucky Arianne rocket - look it up)

If you really want to get retentive, you can do what NASA does (or used to do). Implement the function independently three different times to the same spec - then load the three implementations on to three separate parts. This way, the odds of all three failing at the same time are exceedingly low, and you can tolerate a lot more.

Reply to
radarman

Hi,

radarman schrieb:

[..]

In space applicatione it is common practice to use radiation tolerant technologies (TMR) for registers only. Of course you avoid single source of failures on system level (eg. two redundant bus structures). I never heard of anybody using 3 devices in parallel to achieve robustness against radiation in space. You had a hard argue to get a customer accepting reconfigurable FPGAs in environment with high SEU probabillity like satellites especially if you need a high reliability. But a fuse based fpga is (nearly) immune against permanent changes due to radiation and therefore state of the art.

Just for curiosity: What fault in an Arianne are you talking about?

bye Thomas

Reply to
Thomas Stanka

Even with rad-hard chips, you still have potential SEU issues. I worked on an unnamed satellite where we had to deal with this. We chose to use a single part, in this case, a rad-hard Actel fuse-link part, and use TMR (triple module redundancy) on the I/O, and internally for the logic

- but we did it for power reasons. In this case, though, a failure could generally be tolerated (and corrected) remotely with no real safety consideration. At worst, we would lose utility for a brief time.

That, for me, is the primary factor. If a complete failure can be tolerated, it's generally acceptable to use a single part and replicate the design - but with safety critical, it's another story. I worked for a while at a nuclear power plant, and every critical system has at least one backup, and in some cases, two backups. Clearly, not a situation where you can tolerate a complete failure gracefully.

The Arianne problem I was referring to was the Arianne 5, the first of which went off course and was destroyed due to a fault in it's inertial navigation system software.

formatting link

Reply to
radarman

Dioptre schrieb:

While it is conceivable, that for some extreme circuits an implementation that shares ressources, none of the currenct optimization techniques can find such an implementation. No local transformation can achieve it and there are no implications between the two parts. You can be pretty sure that there will be no shared logic.

On the practical side you can use the modular design flow to create a netlist for one of the parts and instantiate it twice. Additionally you can apply non overlapping area constraints to the circuits.

Kolja Sulimma

Reply to
Kolja Sulimma

Wow, that was a fascinating read! Thanks,

Jon

Reply to
Jon Elson

Hi, "(this is what happened to a particularly unlucky Arianne rocket - look it up) "

Can you show the information resource in web?

Thank you.

Weng

Reply to
Weng Tianxiang

--------------------------------------------- Maybe you just didn't get that far in the posts:

---------------------------------------------

Reply to
John_H

Hi,

radarman schrieb:

I consider TMR on registers as good enough and never used TMR on internal modules before. For extreme requirements our company changes to very hard technologies. A Fpga is good enough to have only a few failure in time (due to radiation) on normal GEO orbit. If that's not enough (e.g. for military satellites), you need to switch to very hard Asic technologies. But a simple technology used for commercial A problem left for TMR on modul level or even system level is the voter that decides wheter your result is good or wrong.

Depending on your system design you may still accept a temporary device malfunction :). I agree you need to be sure no SEU could lead to a problem in a nuclear power plant and three devices could be one sollution to ensure this.

*g* I just missunderstood the point you had with your example. After rereading your first post it was clear you mean this good example why heritage is never a replacement for a system test.

bye Thomas

Reply to
Thomas Stanka

If I implement a function in an FPGA twice and do all these measures to make sure that there are no functional interactions between theese two implementations: What makes this implementation worse comparing to an implementation based on two separate devices? The single power supply? If this single piece of silizium is "faulty"? anything else?

Regards Falk S.

Reply to
Falk Salewski

Yes, both circuits share the same configuration circuitry. A fault in the configuration logic will render the whole device unprogrammable.

Reply to
Ray Andraka

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.