3liteDragon
Member
I’m not sure I understand this because I read a brief explanation on ResetEra of the patent that Cerny’s SSD and I/O implementation are based off of and it sounded like the SRAM pool on the main custom chip only serves one purpose that’s related to file I/O. I may be wrong on this but here’s the link to the thread:L4 cache is the embedded SRAM on the SoC. Most people probably overlooked this bit, or simply do not know what it means, but it is a static RAM that is closer to SoC than the main system 16GB GDDR6 RAM (and thus has even less latency, perfect for streaming related stuff). Don't know its size however I can speculate it is around 32-64MB. You guys probably still remember Xbox One's 32MB eSRAM that was right on the chip which was made to close the gap for their use of DDR3 RAM as main system memory instead of GDDR5. This time however, PS5 has plentiful main system RAM with good BW and really (REALLY) high bandwidth NAND chips for storage, so it is hard for me to say PS5's usage of eSRAM as it doesn't need it to increase BW but a special purpose. It takes up precious die space so the reason of its existence must be really important but don't know why people simply overlooked it. I thought it was a well known feature of PS5, certainly since it was really badly implemented in Xbox One as a stop gap for their glaring BW deficit.
Well I can speculate a few use cases:
First, Tempest Audio is configured as RAMless DMA engine so if it requires memory pointers, SRAM is closest and probably one with least latency being on the same chip.
Second, is still related to Tempest however not for audio solution for PS5 games but for BC. I think TE which is described as SPU like chip can behave like CELL for PS3, RSX is GPU portion with its own GDDR6 RAM, however you guys must remember PS3 had split memory configuration where it's GPU - RSX had its own memory and its CPU - CELL also had its own, well you guessed it; this SRAM can be the on chip CPU RAM that it needs for a PS3 BC if there was any plan of doing it. Unified memory probably would not work in hardware BC where the original console had split config. so partially it makes sense, ofc this is speculation.
Third, and this is the most possible among these, related to SFS it holds the most current virtual asset IDs for better utilization of the RAM pool and keeps from unnecessarily streaming from SSD, it is most likely that these work in tandem with new caches placed in the GPU and the scrubbers that work to partially evict these caches once they are invalidated from the list resident and live updating in the SRAM.

PS5 - a patent dive into what might be the tech behind Sony's SSD customisations (technical!)
This will be one for people interested in some potentially more technical speculation. I posted in the next-gen speculation thread, but was encouraged to spin it off into its own thread. I did some patent diving to see if I could dig up any likely candidates for what Sony's SSD solution might...
SRAM instead of DRAM inside the SSD for lower latency and higher throughput access between the flash memory controller and the address lookup data. The patent proposes using a coarser granularity of data access for data that is written once, and not re-written - e.g. game install data. This larger block size can allow for address lookup tables as small as 32KB, instead of 1GB. Data read by the memory controller can also be buffered in SRAM for ECC checks instead of DRAM (because of changes made further up the stack, described later). The patent also notes that by ditching DRAM, reduced complexity and cost may be possible, and cost will scale better with larger SSDs that would otherwise need e.g. 2GB of DRAM for 2TB of storage, and so on.
When a read request is made by the main CPU, it sends it to the secondary CPU, which splits the request into a larger number of small data accesses. It does this for two reasons - to maximise parallel use of the NAND devices and channels (the 'expanded read unit'), and to make blocks small enough to be buffered and checked inside the SSD SRAM. The metadata the secondary CPU needs to traverse is much simpler (and thus faster to process) than under a typical virtual file system.
The NAND memory controller can be flexible about what granularity of data it uses - for data requests send through the File Archive API, it uses granularities that allow the address lookup table to be stored entirely in SRAM for minimal bottlenecking. Other granularities can be used for data that needs to be rewritten more often - user save data for example. In these cases, the SRAM partially caches the lookup tables.
When the SSD has checked its retrieved data, it's sent from SSD SRAM to kernel memory in the system RAM. The hardware accelerator then uses a DMAC to read that data, do its processing, and then write it back to user memory in system RAM. The coordination of this happens with signals between the components, and not involving the main CPU. The main CPU is then finally signalled when data is ready, but is uninvolved until that point.
Last edited: