Robust configuration memory

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello,

I need a moderate amount of non-volatile memory (for FPGA
configuration purposes and the like), but can't tolerate
configuration errors due to charge leaks, cosmic radiation
or just the malfunction of the chip. I thought that something
like RAID5 imposed on memory chips/SD cards would be fine.
It would be extremely simple in an FPGA, but it creates
a chicken and egg problem: how can you read the controller's
configuration from flash if the flash itself might be corrupt.

It could also be done easily in hardware, but would require
parallel-output chips, which are not particularly trendy nowadays
and the SPI decoding circuitry would be insanely complex with
simple gates.

I presume I am not the first person to have such a need, so
what would you recommend me? It has to be autonomous only
for (early) reads, the write mode part can materialize later
within the FPGA. Any ideas?

    Best regards, Piotr


Re: Robust configuration memory
On Sunday, February 18, 2018 at 2:20:55 AM UTC-8, Piotr Wyderski wrote:

Quoted text here. Click to load it

Flash is cheap; either redundancy (three copies and a vote)
or checksums (two copies with two checksums) will warn of an error,
and you can mark a block 'bad' and use another.
Reading isn't stressful on flash, it's only the erase/rewrite cycles
that you gotta worry about, eventually.  So, minimize those.

Some implementations are available with internal ECC-checking, too.
<http://www.onsemi.com/pub/Collateral/CAT24C256-D.PDF

Re: Robust configuration memory
whit3rd wrote:

Quoted text here. Click to load it

You're right, a single voting engine attached to three copies
of the DOUT SPI line will do the job without the need to analyze
the protocol. Problem solved, dead simple, thanks!

Quoted text here. Click to load it

There will not be many write cycles, but the storage is leaky,
so it will turn into all ones eventually. With the voting mechanism
I can detect it early and re-program the chips with the correct(ed)
content.

The interesting discovery now is the apparent lack of majority gates
and the circuit is sufficiently complex not to fit within a simple
logic circuit in a single package. It seems the best thing to do is
to use an 8:1 MUX (say, 74AC241) and etch the LUT on the PCB. 6ns
delay doesn't sound bad. Am I missing an even simpler implementation?

    Best regards, Piotr

Re: Robust configuration memory
On 18/02/2018 23:24, Piotr Wyderski wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it


Simpler but not better: Tie them all together and let them fight it out.  
If you are somewhat merciful you could give each output a series resistor.


Re: Robust configuration memory
On Sun, 18 Feb 2018 23:57:15 +1100, Chris Jones

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

The pulldown will usually win.

Quoted text here. Click to load it

Assuming the FPGA logic threshold is Vcc/2, and the FPGA and the flash
chips use the same Vcc.

Sounds risky.


--  

John Larkin   Highland Technology, Inc   trk

jlarkin att highlandtechnology dott com
We've slightly trimmed the long signature. Click to see the full one.
Re: Robust configuration memory
On Sun, 18 Feb 2018 18:36:45 -0800, John Larkin

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Sum with resistors.
Quoted text here. Click to load it

Comparator.  LVDS comparators should be quick enough.

Quoted text here. Click to load it

What, you don't like analog solutions to digital problems?  ;-)

Re: Robust configuration memory
On Sun, 18 Feb 2018 21:55:39 -0500, snipped-for-privacy@notreal.com wrote:

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

It could be done with three resistors and a comparator. LVDS receivers
typically have a +-100 mV offset spec, which would be good enough for
a 3.3 volt majority decision. The resistors need to be big enough to
swamp the flash chip output impedance variation, so a little speed
might be lost.

Good place for a digital solution.


--  

John Larkin   Highland Technology, Inc   trk

jlarkin att highlandtechnology dott com
We've slightly trimmed the long signature. Click to see the full one.
Re: Robust configuration memory
On 02/18/2018 09:36 PM, John Larkin wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Murphy's law dictates that you'll never get an isolated failure that can  
be majority-ruled two to one, you'll either get full agreement or a  
Mexican standoff.

The Space Shuttle used four active GPCs with a fifth one kept on warm  
standby designed only to run the de-orbit/descent program; if one was in  
consistent disagreement with the other three it was taken off-line and  
the mission continued, if another then went off the reservation then the  
mission would be aborted and the fifth computer brought up to run the  
descent program ASAP.

Re: Robust configuration memory
bitrex wrote:

Quoted text here. Click to load it

Majority voting in a system composed of even number of participants, jazzy!

    Best regards, Piotr


Re: Robust configuration memory
On 02/19/2018 04:25 AM, Piotr Wyderski wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

It was considered a feature, not a bug - the guidance/avionics software  
for the main computers was extremely complex with millions of lines of  
code, absolutely no way to guarantee there wasn't a showstopper bug  
lurking there somewhere. All four main computers ran the same code  
developed by IBM; the fifth backup computer's code was written entirely  
independently IIRC by the Rockwell team.

The most likely cause of a "majority-rule" fault was considered to be a  
hardware issue, but a 2-2 deadlock was more likely to be a software  
problem, and in that situation you simply can't trust the four main  
computer's software to do anything correctly anymore so you bring up the  
fifth computer to run the critical sections using an independent codebase.

The probability of both a showstopper bug in the main code and another  
one in the backup causing a loss of vehicle accident was considered to  
be so remote as to be an eventuality that wasn't addressable by any  
reasonable amount of engineering effort. AFAIK a 2-2 split never  
occurred in practice

Re: Robust configuration memory
On 02/19/2018 09:19 AM, bitrex wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Four main guidance computers plus a backup on standby was considered the  
minimum to achieve a fail-continue/fail-safe mission profile in the case  
of one and two computer failures, respectively.

Three would have only been enough to achieve fail-safe in the case of a  
single failure. Five active main computers plus a backup was too heavy.

Re: Robust configuration memory
Quoted text here. Click to load it

Also, redundant systems are only useful when the failure modes are
different.  Just connecting 3 memory devices and do a majority vote
does not cover the case where all 3 fail at the same time due to a
common cause (such as a supply voltage spike, a gamma radiation event, etc)

So you would need 3 memories of different technology to at least attempt
to cover such things.

Same goes for running redundant computers: they should at least have
different hardware, and preferably also run independently developed
software.  Else you will encounter the Ariane-501 mode of failure where
both computers fail at the same time due to software error.

Re: Robust configuration memory
On 02/19/2018 09:20 AM, Rob wrote:
Quoted text here. Click to load it

Yep. A triple-redundant system with common software and/or common  
failure modes that can only recover from a single-point failure is  
probably not that much more reliable than a single device.

There were a number of systems even on the Space Shuttle that didn't  
have any redundancy and were "must-work" systems that if they failed  
would intrinsically lead to a LOV incident. The SRBs were one, and the  
payload bay door latching system was another.

If the payload bay doors failed to latch prior to descent the only  
contingency plan was to get every guy available down to work on prepping  
the next shuttle's turn-around around-the-clock as fast as possible,  
launch as soon as possible, maybe see what assistance the Russians could  
provide via Soyuz, and pray.

Re: Robust configuration memory
Den mandag den 19. februar 2018 kl. 15.36.37 UTC+1 skrev bitrex:
Quoted text here. Click to load it

after Columbia they added a cable harness so the flight computer and controls
could be connected and the shuttle landed via remote control. The crew would
stay at the ISS until they could get down in some other way

Re: Robust configuration memory
On 02/19/2018 12:12 PM, Lasse Langwadt Christensen wrote:
Quoted text here. Click to load it

That's an option on mission profiles where the ISS was the destination;  
that was most missions in the final years of the program but not all of  
them, including the ill-fated Columbia mission.

The Shuttle doesn't have the ability to reach the ISS from any arbitrary  
orbit.

Re: Robust configuration memory
Quoted text here. Click to load it

<dim-mamory>
There are some "configurable 2-input" gates that can be used for that, I think, if you play around with their truth tables a bit. (They actually have 3 or 4 inputs.)
</dim-mamory>

Cheers

Phil Hobbs

Re: Robust configuration memory
Quoted text here. Click to load it


  
 Slightly simpler.

                         ............
                         . 4:1 mux  .
                         .          .
                         .       X0 . ------ 0
                    A ---.  A0   X1 . ------ C
                    B ---.  A1   X2 . -------C
                         .       X3 . ------ 1
                         .          .
                         .        Y . ----------
                         ............     
                  

--  
This email has not been checked by half-arsed antivirus software  

Re: Robust configuration memory
Jasen Betts wrote:

Quoted text here. Click to load it

I like it, thanks! Unfortunately, it seems that there
is no single 4:1 MUX in the TinyLogic series, so there
is no real estate win, but OTOH I can have two such voters
in the same package or use the second MUX for something else.

    Best regards, Piotr


Re: Robust configuration memory
On 18.02.2018 13:24, Piotr Wyderski wrote:
Quoted text here. Click to load it

Make sure however that you have a way to disable the voting and access
the memory chips individually for writing. For one thing, writing to all
of them at the same time might be risky (in case a glitch happens), but
also SPI EEPROMs tend to have a status register bit that is polled
during writes to check for completion. With a voter still active, the
write would be indicated as finished as soon as 2 out of 3 chips finish
writing, with the third one at risk of getting into an undefined state.

Dimitrij

Re: Robust configuration memory
Dimitrij Klingbeil wrote:

Quoted text here. Click to load it

Sure thing, Dimitrij. After the configuration I'd even gladly jump
to x4 mode, as the FPGA can easily handle multichannel majority voting
on its own. Just wanted to close the loop during the most sensitive
stage. I didn't expect it to be *that* simple.

The updates will be rare, so even a software-controlled bit-banging,
one chip at a time, will be fully sufficient.

    Best regards, Piotr


Site Timeline