Groups | Search | Server Info | Login | Register


Groups > sci.electronics.design > #725829

Re: DRAM accommodations

From Bill Sloman <bill.sloman@ieee.org>
Newsgroups sci.electronics.design
Subject Re: DRAM accommodations
Date 2024-09-07 15:07 +1000
Organization A noiseless patient Spider
Message-ID <vbgn2u$171ul$1@dont-email.me> (permalink)
References <vbdcrs$gp01$1@dont-email.me> <vbflbe$tlhp$7@dont-email.me>

Show all headers | View raw


On 7/09/2024 5:31 am, Don Y wrote:
> 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?]

Typical software reaction. You design error detection and error 
correction into the hardware, and the extra hardware can both correct 
most errors (when they can be corrected) and report all of the them - 
both those corrected and those that couldn't be corrected.

Data transmission systems can re-transmit damaged packets of data. and 
tend to go for checksums that merely detected errors in much longer 
words/packets, and reject the affected packets.

-- 
Bill Sloman, Sydney

Back to sci.electronics.design | Previous | NextPrevious 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