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.

Hi,

Dioptre schrieb:
> 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?

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

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.

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....

Dioptre wrote:
> 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.

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.

Hi,

radarman schrieb:

> 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
[..]
> 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.

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.

> 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)

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

bye Thomas

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.

http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html

Dioptre schrieb:
> 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?
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

radarman wrote:

>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.
>
>http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
>
>  
>
Wow, that was a fascinating read!  Thanks,

Jon

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