BadBreathOfTheWild
Member
OK fair enough I wasn't around the forum during that discussion. The SRAM on SoC can be used as it is described here, if indeed the distinction between 'a' and 'the' actually means what you postulated it means, it can be a homogenous pool across PCIe lanes that acts as security check and hazard check if they are set up as concurrent clones of each other.
The part emphasized might be correct in some way like making sure the memory pointers truly points to the same assets all around the homogenous memory pool but you are underestimating 4 lanes of PCIe BW if the destination is system RAM pool, which means the loading of assets for to be used by the GPU for streaming purposes; however, what I was mainly talking about was calculations done right on the SoC for example sound occlusion and necessary ray march for it and also BVH traversal and it's path tracing, which are all BW hungry and SRAM that is embedded on SoC itself is the perfect fit for it. These all depend on the size of each SRAM which we don't know anything about right now, and if they are concurrently updated for checking in reasons, and if they can be used for multiple and separate purposes so we are also not sure if one of it is general purpose or not, it is all speculation at this point. The patent can be read as you said but 'a' and 'the' distinction didn't convince me enough if it is correct or if it is the only use case.
We're both just blue-balled and speculating on cool hardware in exactly the right place to do it.
I think it's clear from the patent what the pool of IO complex SRAM is used for, but that's not to say that's only what it's used for.
I only mentioned PCIe bandwidth in my extreme example of the decompressor using the flash controller's SRAM for its read buffer, because then according to the rest of the patent the data path would go something like this Flash->Controller SRAM->Kernel RAM->Controller SRAM->Decompressor->User RAM. It seems like a nonsensical use of controller SRAM and the PCIe interface separating the decompressor and controller SRAM.
The patent says data from the SSD streams into kernel space system memory before being subject to various checks and decompressing into user space system memory at higher effective bandwidth due to decompression.
It mentions a use of SRAM to do those decompression and check-in tasks and does so while not referring to it as "the SRAM (#)" as the controller SRAM is always referred to as.
It also just makes sense in the context of Cerny's slide where the SRAM is diagrammatically ring-fenced in with the sub-CPU an accelerator mentioned i the patent. It also makes sense that if SRAM is being used as an input buffer for the decompressor, and for the sub-CPU to perform decryption and check-in, it would be close and available to them on the same chip.
That's what I make of it all, anyway.
The entire point of that complex is that it's completely hands off for the actual CPU. The CPU and sub-CPU share address space for system memory as required, but there's no mention or provision for the main CPU being able to address the SRAM as far as I could tell.
I personally think from what's written in the patent and from how it was shown in Cerny's slide, the IO Complex SRAM is dedicated to IO and isn't sharing work with the main CPU/GPU. If it was addressable by the CPU/GPU then any time that happened the IO pipeline would stall, and the wording of the patent regarding the SRAM in the IO Complex seems to be entirely about removing any delay or latency in this middle part of the IO pipeline.