Path: ...!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: MM instruction and the pipeline
Date: Mon, 21 Oct 2024 12:56:59 +0300
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <20241021125659.00001e39@yahoo.com>
References: <venkii$23b6b$1@dont-email.me>
	<vep8rb$2d8ru$1@dont-email.me>
	<bf46a508f4e6bbe44846078a50af63b7@www.novabbs.org>
	<vf39a8$fr1q$1@dont-email.me>
	<2024Oct21.083252@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 21 Oct 2024 11:57:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d12df2ed3511ddfd502bf24f00a7dcce";
	logging-data="550734"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18CeMm49afWedUVKo4L6s3efWE1HEaoChQ="
Cancel-Lock: sha1:cpoSjdWWfvAmsZ+Srjs0j2ciDqQ=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 3566

On Mon, 21 Oct 2024 06:32:52 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> "Paul A. Clayton" <paaronclayton@gmail.com> writes:
> >I was thinking primarily about uncorrectable errors in the
> >source. It would be convenient to software for MM to fail early on
> >an uncorrectable source error. It would be a little less
> >convenient (and possibly more complex in hardware) to generate an
> >ECC exception at the end of the MM instruction (or when it
> >pauses from a context switch).  
> 
> Welcome to the DDR5 age (which started in 2021).  DDR5 not just has
> on-die ECC, it also has ECS (error check and scrub).  From
> <https://in.micron.com/content/dam/micron/global/public/products/white-paper/ddr5-new-features-white-paper.pdf>:
> 
> |An additional feature of the DDR5 SDRAM ECC is the error check and
> |scrub (ECS) function. The ECS function is a read of internal data and
> |the writing back of corrected data if an error occurred. ECS can be
> |used as a manual function initiated by a Multi-Purpose Command (MPC),
> |or the DDR5 SDRAM can run the ECS in automatic mode, where the DRAM
> |schedules and performs the ECS commands as needed to complete a full
> |scrub of the data bits in the array within the recommended 24-hour
> |period. At the completion of a full-array scrub, the DDR5 reports the
> |number of errors that were corrected during the scrub (once the error
> |count exceeds a minimum fail threshold) and reports the row with the
> |highest number of errors, which is also subject to a minimum
> |threshold.
> 
> I am wondering why scrubbing is not performed automatically on
> refresh.
>

Typical DDR5 row contains 4096 data bits. That's 32x bigger than
internal ECC block. In order to do scrub at refresh without major
increase in refresh timing one would need a lot more ECC correction
logic than currently present.
Even with a lot of extra logic there will be some slowdown, likely one
clock (== 16T == 2.5 to 3.3 ns).

> Even before DDR5, scrubbing is a feature of the memory controller that
> it performs in hardware (i.e., without software having to do something
> in an interrupt handler or some such).  Of course the My66000 memory
> controller may be less capable, and leave scrubbing to software; maybe
> also refresh?
> 

Hopefully the last part is tongue in cheek.

> - anton