[libre-riscv-dev] chinese sponsor, looking to design an ECP5-based dev board

[Luke Kenneth Casson Leighton]

On Mon, May 6, 2019 at 10:58 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> In my opinion, we should either support correction or not bother at
> all, since the extra memory hardware to support detection is only
> slightly less expensive than supporting correction. I had selected
> non-ECC simply because that's the easiest to obtain sodimm type and
> because that means we don't have to dedicate as many pins to the
> memory bus in the final SoC, since pin count is a large factor in
> package cost. If we can, it would be nice to support both ECC and
> non-ECC memory, rather than requiring one or the other type.

 if we were designing a server-class processor, the discussion would
definitely be emphatically and strongly in favour of ECC: in fact, if
we did *not* factor in ECC, the entire design would be placed in
jeapordy by not meeting a key critical requirement of server-class
data-centre designs.

 "consumer" class (really don't like that word, it smacks of
irresponsibility - "consumption" of physical items implies that
discarding them is a mandatory expectation, that the item will be
"useless" after "consumption")...

 "consumer" class designs, it's assumed that the application is not
mission-critical.  if a single users' phone glitches due to ECC memory
corruption, only one person is affected: they power-cycle the phone
and dial their friend back.

 no harm done.

 one glitch on a server and several thousand to hundreds of thousands
of people can be affected.


> Note that on read-only caches (like the instruction cache), error
> detection is sufficient since the error can be corrected by just
> reloading that cache line from RAM. RW caches will need some kind of
> error correction.

 intriguing. worth making a note of, given that at some point in the
future our design may end up in AI and robotics applications
(OpenPiton as the NoC / interconnect).

 at that point, the sheer volume of data traffic through on-chip
routing may genuinely need ECC in the caches, to be checked during
transfers between routers.

 also, some form of compression may be beneficial: this is something
that i understand many AI ASIC designers are looking at.  they have
upwards of 4,000 processors on a *single* chip.  MASSIVE interconnect,
and staggeringly-high on-chip data transfer rates.  without data
compression it would be unmanageable.

l.