[libre-riscv-dev] chinese sponsor, looking to design an ECP5-based dev board
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Tue May 7 00:16:40 BST 2019
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
"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.
More information about the libre-riscv-dev