Re: "RESET"

Liste des GroupesRevenir à se design 
Sujet : Re: "RESET"
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : sci.electronics.design
Date : 25. May 2025, 21:35:26
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <100vuug$1i7o7$3@dont-email.me>
References : 1 2 3
User-Agent : Mozilla Thunderbird
On 5/25/2025 12:20 PM, Carlos E. R. wrote:
On 2025-05-25 05:47, Ralph Mowery wrote:
While not really much of a chance but in the eairly days bits could be
randomally changed by stray radiation.
 And today. It is even a bigger chance, with lower logic voltages. Chips are not shielded.
Depending on the technology, just accessing a memory cell can degrade it's
content.  When you are storing a handful of electrons, any couple that
manage to "leak out" can alter the perceived state of that cell.
Accesses to "nearby" cells/wordlines, etc.
Expecting memory to "remember" is naive, nowadays.
For devices that load RAM from a (slower) FLASH store, there is no
guarantee that the contents of the RAM mirror the FLASH any time later.
Even assuming errant software doesn't "accidentally" corrupt it.
Do you *routinely* verify it's integrity?  How often?  What do
you do WHEN you discover a bit has been corrupted in the TEXT?
How confident does that make you about the DATA??
"Oh, the hardware is reliable"  Then, you should be able to PROVE
this assertion.  Monitor EVERY access (in a test fixture) and
verify they agree with a duplicate store maintained "outside"
the product.
Or, just look at the research others have done and realize your reliability
assumptions are likely wishful thinking.  ("Ah, but we can blame the
software for any anomalous behavior!"  And, NEVER manage to find "the bug"
or FIX it!)
In the days of toy products (a few kiloBITS of RAM made with very
large geometries and slow cycle times), you could reasonably hope
for a long time between failures.  (And, failures need not manifest
as changes from desired behavior!  "4 >> 1" yields the same result
as "5 >> 1".  "JMP if ODD" yields the same behavior as "JMP unconditionally"
if the test just *happens* to be ODD)
Nowadays, its so easy to have megabytes and gigabytes of RAM in
a device and few XIP like days of old.  So, the risks causes double.

Date Sujet#  Auteur
24 May 25 * "RESET"42Don Y
24 May 25 +- Re: "RESET"1Don Y
25 May 25 +- Re: "RESET"1john larkin
25 May 25 +* Re: "RESET"26Carlos E. R.
25 May 25 i+* Re: "RESET"3Don Y
25 May 25 ii`* Re: "RESET"2Carlos E. R.
25 May 25 ii `- Re: "RESET"1Don Y
27 May 25 i+* Re: "RESET"20Don Y
28 May 25 ii`* Re: "RESET"19Joe Gwinn
28 May 25 ii +- Re: "RESET"1Don Y
28 May 25 ii `* Re: "RESET"17David Brown
28 May 25 ii  `* Re: "RESET"16Joe Gwinn
30 May 25 ii   `* Re: "RESET"15David Brown
30 May 25 ii    `* Re: "RESET"14Joe Gwinn
4 Jun 25 ii     `* Re: "RESET"13David Brown
4 Jun 25 ii      +* Re: "RESET"8Joe Gwinn
4 Jun 25 ii      i`* Re: "RESET"7David Brown
4 Jun 25 ii      i `* Re: "RESET"6Joe Gwinn
5 Jun 25 ii      i  +* Re: "RESET"2David Brown
5 Jun 25 ii      i  i`- Re: "RESET"1Carlos E.R.
5 Jun 25 ii      i  `* Re: "RESET"3Martin Brown
5 Jun 25 ii      i   +- Re: "RESET"1Joe Gwinn
5 Jun 25 ii      i   `- Re: "RESET"1Don Y
6 Jun 25 ii      +* Re: "RESET"3David Brown
6 Jun 25 ii      i`* Re: "RESET"2Carlos E.R.
10 Jun 25 ii      i `- Re: "RESET"1David Brown
6 Jun 25 ii      `- Re: "RESET"1john larkin
28 May 25 i`* Re: "RESET"2Martin Brown
28 May 25 i `- Re: "RESET"1Don Y
25 May 25 +* Re: "RESET"6Ralph Mowery
25 May 25 i+* Re: "RESET"3Don Y
25 May 25 ii`* Re: "RESET"2Carlos E. R.
25 May 25 ii `- Re: "RESET"1Don Y
25 May 25 i`* Re: "RESET"2Carlos E. R.
25 May 25 i `- Re: "RESET"1Don Y
25 May 25 +* Re: "RESET"2Ian
25 May 25 i`- Re: "RESET"1Don Y
25 May 25 +* Re: "RESET"2Theo
25 May 25 i`- Re: "RESET"1Don Y
25 May 25 `* Re: "RESET"3Martin Brown
25 May 25  +- Re: "RESET"1Don Y
25 May 25  `- Re: "RESET"1Carlos E. R.

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal