A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
fuse.wikichip.org
A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
1–10 of 16 posts
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#2Interesting. There have been a few of these super-manycore processors before; their main characteristic is being quite hard to program effectively due to the need to partition the work and think very hard about memory bottlenecks.
> The Vanilla-5 cores are a 5-stage in-order pipeline RV32IM cores so they support the integer and multiply extensions
So, roughly comparable to a high-speed Cortex M.
> instead of using caches, the entire memory address space is mapped across all the nodes in the network using a 32-bit address scheme. This approach, which also means no virtualization or translation, simplifies the design a great deal.
The diagram shows each core has icache and dcache; what they've ditched is cache coherency. That certainly makes it simpler to implement but now the cores have to be responsible for their own coherency. Also, none of your protected mode operating system nonsense - this is designed to run a single program and get everything out of the way. Every core can potentially overwrite any other core's memory, and if it does so you won't know until you have a cache miss. Good luck figuring that one out in the debugger.
This is very clearly intended for the sort of AI or image processing workload where you can clearly partition it two-dimensionally across the array to identical nodes, and then have those nodes collaborate locally by passing messages across the edges.
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#3Another project that goes for a manycore designed, is by Princton and ETH Zürich. Their design targets a few less cores I think.
See: https://github.com/PrincetonUniversity/openpiton#support-for...
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#4Interesting. There have been a few of these super-manycore processors before; their main characteristic is being quite hard to program effectively due to the need to partition the work and think very hard about memory bottlenecks. > The Vanilla-5 cores are a 5-stage in-order pipeline RV32IM cores so they support the integer and multiply extensions So, roughly comparable to a high-speed Cortex M. > instead of using ca…
> what they've ditched is cache coherency. That certainly makes it simpler to implement but now the cores have to be responsible for their own coherency.
Like the quote says: “There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.”
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#5Ok, if two processors read/write the same address what happens? Could I assume the reads are coherent but writes are not?
If this is the case then I assume I'd just need to design-wise restrict one processor from writing to another's area, yes?
I've worked on worse. Quite promising set of ideas from my limited reading.
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#6Interesting. There have been a few of these super-manycore processors before; their main characteristic is being quite hard to program effectively due to the need to partition the work and think very hard about memory bottlenecks. > The Vanilla-5 cores are a 5-stage in-order pipeline RV32IM cores so they support the integer and multiply extensions So, roughly comparable to a high-speed Cortex M. > instead of using ca…
> The diagram shows each core has icache and dcache; what they've ditched is cache coherency.
This is not quite true: the local data memories are not caches, i.e., they do not implicitly move memory in from a more distant tier in the memory hierarchy. They are just plain explicitly managed local memories (sometimes called "scratchpads" to distinguish them from caches).
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#7I like that only permitting writes to other cores' memory simplifies the design. If you want to read, you have to write a request to that core by storing the request in a place it will look, and tell it where to put the answer. And, all the cores heve to check for such requests.
It is kind of surprising that that is acceptable. I suppose the usual case is that each core already knows what its neigbors will want to see, and sends those values before each neighbor needs them.
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#8I think it's interesting to compare this to a dual 64 core AMD system (so 128 cores) or similar in terms of the programming model or performance.
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#9I think it's interesting to compare this to a dual 64 core AMD system (so 128 cores) or similar in terms of the programming model or performance.
This completely different from EPYC (and the Xeon Phi). The x86's present a single coherent memory image and lots of identical CPU cores whereas this one doesn't. In some aspects it resembles a Cell processor, with the difference that the "SPUs" (the tiny in-order cores) have some direct access to the main memory and are mostly binary compatible with the "PPUs" (the five large RISC-V cores).
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#10I like that only permitting writes to other cores' memory simplifies the design. If you want to read, you have to write a request to that core by storing the request in a place it will look, and tell it where to put the answer. And, all the cores heve to check for such requests. It is kind of surprising that that is acceptable. I suppose the usual case is that each core already knows what its neigbors will want to se…
Ask what's memory protection before it overwrites state used by another core. Then ask again how you synchronize these words from one with reads from another.
Yeah, it's not even eventual consistency. They get away with it by using a heavy mailbox message passing setup for synchronization and separate address spaces.