Re: MM instruction and the pipeline

On Mon, 21 Oct 2024 9:56:59 +0000, Michael S wrote:

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.

The standard 64+8 code is SECDED and takes 8 gate delays (5-XOR gates,
2 NAND gates, 1 XOR gate).
One can do as many 64+8 error checks as one wants in those gates of
delay.
It is only when one wants better than SEC/DED that things get
interesting.

Even with a lot of extra logic there will be some slowdown, likely one
clock (== 16T == 2.5 to 3.3 ns).

DRAM clock should not be that much slower than CPU clock -- a factor
of 2-3 is expected (logic delay), putting DRAM clock in the 0.75ns
range.

>