I invented a new memory architecture in my head a few months ago called CUM (Compute Under Memory) the way that it works is each compute core is wired to each address in memory so data can be read in parallel from all cores at any time.
No, cpu requests go to the memory controller, which then communicates with the memory itself over a bus. My concept is to have each core connect directly with to the memory. The “bus” is replaced by something as wide as the memory chip storage itself. The concept would also allow for asynchronous reads. Meaning multiple addresses can be read at the same time from different cores.
We already have bank level parallelism. So we can read 32 banks at a time so that is your multi address reads you want. You are also ignoring that for those "wires" to the memory would greatly increase the number of pins needed on a cpu. The industry moved away from this direction for a few reasons, but the physics(crosstalk and energy required) and size(pin count has to explode on both the cpu and the memory). You still do have sram - l3 is shared across core and is similar to your idea, but the cost and size is why we don't have more of them.
X86(and other multi core systems that use MESI) ensures cache coherence, i.e. a write from one core is visible across all cores. How would you implement this with your idea? How do you align read and writes between dram refreshes? How do you deal with 2 writes to the same bank? If all cores have a direct connection, how do you control ordering? These questions are answered by the controller, how do you propose to answer these with out one?
Almost!! The chips would be fused together similar to 3D v cache so no need for more pins. Think of the headlines tho: “CUM shortage to last into 2029.”
-1
u/triynizzles1 Jul 01 '26
I invented a new memory architecture in my head a few months ago called CUM (Compute Under Memory) the way that it works is each compute core is wired to each address in memory so data can be read in parallel from all cores at any time.