News for hackers. Stuff that matters.
Re:A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC by ncmncm on Monday January 13, 2020 @10:37AM (#22035328)
I 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 by JerryTy on Monday January 13, 2020 @03:41PM (#22038332)
This technique is known as remote store programming (RSP) which allows for a very convenient producer-consumer communication. It lends itself well to AI workloads since reading for a foreign core is rather rare compared to writing to one (eg next stage).
Re:A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC by AstralStorm on Monday January 13, 2020 @11:50AM (#22036074)
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.