Groups | Search | Server Info | Login | Register

Groups > sci.electronics.design > #725815

Re: DRAM accommodations

Show all headers | View raw

On 9/5/2024 3:54 PM, Don Y wrote:
> Given the high rate of memory errors in DRAM, what steps
> are folks taking to mitigate the effects of these?
> 
> Or, is ignorance truly bliss?  <frown>

 From discussions with colleagues, apparently, adding (external) ECC to
most MCUs is simply not possible; too much of the memory and DRAM
controllers are in-built (unlike older multi-chip microprocessors).
There's no easy way to generate a bus fault to rerun the bus cycle
or delay for the write-after-read correction.

And, among those devices that *do* support ECC, it's just a conventional
SECDEC implelmentation.  So, a fair number of UCEs will plague any
design with an appreciable amount of DRAM (can you even BUY *small*
amounts of DRAM??)

For devices with PMMUs, it's possible to address the UCEs -- sort of.
But, this places an additional burden on the software and raises
the problem of "If you are getting UCEs, how sure are you that
undetected CEs aren't slipping through??"  (again, you can only
detect the UCEs via an explicit effort so you pay the fee and take
your chances!)

For devices without PMMUs, you have to rely on POST or BIST.  And,
*hope* that everything works in the periods between (restart often!  :> )

Back of the napkin figures suggest many errors are (silently!) encountered
in an 8-hour shift.  For XIP implementations, it's mainly data that is at
risk (though that can also include control flow information from, e.g.,
the pushdown stack).  For implementations that load their application
into DRAM, then the code is suspect as well as the data!

[Which is likely to cause more detectable/undetectable problems?]

Back to sci.electronics.design | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

DRAM accommodations Don Y <blockedofcourse@foo.invalid> - 2024-09-05 15:54 -0700
  Re: DRAM accommodations john larkin <jl@650pot.com> - 2024-09-05 16:54 -0700
  Re: DRAM accommodations Bill Sloman <bill.sloman@ieee.org> - 2024-09-06 16:15 +1000
  Re: DRAM accommodations Don Y <blockedofcourse@foo.invalid> - 2024-09-06 12:31 -0700
    Re: DRAM accommodations Don Y <blockedofcourse@foo.invalid> - 2024-09-06 17:43 -0700
    Re: DRAM accommodations Bill Sloman <bill.sloman@ieee.org> - 2024-09-07 15:07 +1000
    Re: DRAM accommodations albert@spenarnc.xs4all.nl - 2024-09-07 11:56 +0200
      Re: DRAM accommodations Don Y <blockedofcourse@foo.invalid> - 2024-09-07 04:04 -0700
        Re: DRAM accommodations Don Y <blockedofcourse@foo.invalid> - 2024-09-07 04:06 -0700
          Re: DRAM accommodations Don Y <blockedofcourse@foo.invalid> - 2024-09-07 04:08 -0700
        Re: DRAM accommodations Don Y <blockedofcourse@foo.invalid> - 2024-09-07 05:01 -0700
        Re: DRAM accommodations john larkin <jlarkin_highland_tech> - 2024-09-07 07:35 -0700
    Re: DRAM accommodations Waldek Hebisch <antispam@fricas.org> - 2024-09-17 00:33 +0000
      Re: DRAM accommodations Don Y <blockedofcourse@foo.invalid> - 2024-09-16 19:05 -0700
        Re: DRAM accommodations Don Y <blockedofcourse@foo.invalid> - 2024-09-16 19:31 -0700
        Re: DRAM accommodations antispam@fricas.org - 2024-09-17 16:12 +0000
          Re: DRAM accommodations Don Y <blockedofcourse@foo.invalid> - 2024-09-17 11:57 -0700
  Re: DRAM accommodations Chris Jones <lugnut808@spam.yahoo.com> - 2024-09-17 23:47 +1000
    Re: DRAM accommodations Bill Sloman <bill.sloman@ieee.org> - 2024-09-18 00:04 +1000
    Re: DRAM accommodations Don Y <blockedofcourse@foo.invalid> - 2024-09-17 07:57 -0700

csiph-web