Hace poco «ha aparecido una patente» que podría darnos pistas de como funcionaría el sitema de almacenamiento masivo de PlayStation 5, la patente la podéis encontrar aqui, y en esta entrada intentaré darle una explicación clara y concisa sobre lo que significa sin que acabéis en modo…

La patente es de Sony Interactive Entertainment y por tanto esta claro que se refiere a uno de sus productos, ergo a una consola. Solo hay que ver el diagrama principal de la patente para ver que se refiere a una consola completamente inédita.

la parte que pone Host Unit se refiere al SoC, esta simplificado enormemente y obviamente faltan componentes, pero dicha simplificación en el diagrama es para simplificar el entendimiento. La Memoria del Sistema 14 se sobre-entiende que se trata de un grupo de chips aparte y luego tenemos un chip aparte que esta conectado al IO Controller del SoC principal, tened en cuenta que el IO Controller es el IO Hub en los SoC actuales de AMD y que la comunicación del IO Controller/IO Hub con el exterior es con una serie de lineas PCI Express.

En PS4 el único elemento externo al chip aparte de la memoria y el almacenamiento es el Southbridge que es donde están conectados todas las interfaces de E/S del sistema…

Pero si miramos en la lista de dispositivos Ariel veremos que el Southbridge ha sido trasladado dentro del propio SoC en todas sus funciones.

Incluso el nucléo ARM que ahora ha pasado a ser el Cryptographic Coprocessor.

Por lo que el dispositivo externo tiene que tratarse de otro elemento que no es un Southbridge. En la patente nos explican su función:

La únidad huepesd 12 genera una petición para acceder a la memoria flash 20 de acuerdo al progreso de una tarea de proceso de la información, almacenando la petición en la memoria del sistema 14.

Esto significa que tenemos que tener una pieza en el SoC principal que pueda acceder tanto al controlador de memoria y comunicarse con él como acceder al IO Hub dentro del mismo.

La petición de acceso incluye una dirección lógica (Logical Block Addres) de una dirección de destino. El controlador hueped 22 del controlador flash 18 lee la petición de acceso desde la memoria del sistema 14 y convierte el LBA en una dirección física de la memoria flash 20. En este tiempo, parte de la dirección necesaria para la tabla de conversión de direcciones que estaba localizada en la memoria flash 20 esta localizada en la SRAM 24.

¡Entonces si el Host Controller es el que tiene acceso a la RAM del sistema tenemos que el diagrama esta mal y es horrendo, en serio. ¿Como es que el texto de la patente contradice al diagrama? El llamado Host Controller debería estar dentro del propio SoC porque la única manera de tener acceso directo a la memoria del sistema y al IO Controller/Hub es estar conectado a ambos y por tanto dentro del SoC. Por otro lado nos indica una situación de dependencia entre la memoria SRAM y el Controlador Huesped 22… Y tenemos claro en ambos casos que este se encuentra antes del controlador de memoria tanto de la RAM principal como de la NAND Flash.

¿A que nos suena esto? Dado que Sony esta utilizando tecnología de AMD…

El Controlador Huesped creo que no es otra cosa que el High Bandwidth Cache Controller en en la GPUs de AMD hemos visto a partir de Vega y le permite a la GPU tener acceso directo a las diferentes memorias aparte de su memoria local.

En consolas la memoria local es la memoria de la gráfica también por la configuración UMA de estas por lo que su acceso se limitaría a la RAM del sistema. El handicap con el que nos encontramos es que en el caso de la HBCC a la hora de acceder a la memoria del sistema o la NV RAM/Nand Flash esta usa la memoria HBM2 como cache intermedia y en la consola no la vamos a tener porque sería un sobrecoste adicional.

De ahí a utilizar la SRAM en el HBCC como un nivel adicional de cache para realizar dicha tarea, esto nos lleva que una importante cantidad de SRAM acabe en el SoC principal aumentando su tamaño y hemos de tener en cuenta que dicha SRAM ha de ser más grande en densidad que las caches de nivel más alto disponibles en CPU y GPU aunque no es una cache de ambas propiamente dicho si que lo es del Controlador Huesped 22, el cual tiene todos los números de ser una unidad HBCC pero añadir la SRAM en sustitución de la HBM2 acaba resultando obviamente en que esta acaba ocupando un espacio importante dentro del SoC principal.

La comunicación entre la SRAM 24 del Controlador Huesped 22 o vicecversa con la memoria del sistema nos viene en diagrama en la FIG. 8 donde se contradice con la FIG. 1 en cuanto a esa comunicación.

Se agradece que se mantengan los número de referencia para que de esta manera nos podamos situar mejor. Nos interesa la interfaz entre la SRAM y la memoria del sistema S44.

La FIG. 8 esquemáticamente ilustra un procedimiento de procesamiento que continua hasta que la lectura de un archivo que ha sido pedido se ha completado utilizando el «file archive». Primero el controlador flash 18 lee lo datos peticionados a la memoria flash 20 y los cara en la RAM integrada 24 como se describe en la FIG. 7 (S40). Etos datos estan en únidades resultantes de la división del archivo original en bloques y compresión de los mismos.

No voy a poner la FIG 7, no me hace falta para la explicación… ¿Que mecanismos conocido de AMD que hace este mismo trabajo divide los datos del arvhivo en bloques regulares? Lo habéis adivinado… el HBCC.

Continuemos…

Por lo tanto, los datos son de un tamaño que pueden ser adecuadamente almacenados en la RAM 24, entonces el controlador flash 18 realiza la comprobación ECC (bit de paridad) de esos datos en esas unidades (S42).

Cuando los datos pasan la comprobación ECC, los datos en cuestión se almacenan en la Kernel Area 70 de la memoria del sistema 14, reservada por adelantado por la sub CPU, por ejemplo, a través de un controlador DMA no ilustrado, y la sub-CPU 32 es notificada de este efecto (S44). Hay que tener en cuenta que un fallo durante la comprobación ECC va a hacer que e controlador flash 18haga de nuevo la petición hasta que todas las peticiones de lectura enviadas por la sub-CPU 32 estén completas.

Por lo que es la Sub-CPU 32 la que hace las peticiones a la SRAM y lo hace a través de un canal DMAC. LA Sub-CPU 32 se ha de encontrar en el mismo espacio de memoria de la CPU, de ahí a marcar el acceso coherente a la memoria en la FIG.1 pero al mismo tiempo tiene acceso al espacio de memoria de la SRAM a través de un controlador DMA.

La sub-CPU 32 envia una petición al acelerador 42 para comprobar el tampering, descodificación y decompresión de los datos leidos en el area del kernel 70 en respuesta a la notificación del controlador flash 18 (S46). El acelerador 42 realiza dichas taras por cada pieza de datos… en el user buffer 72 de la memoria del sistema 14 y avisa a la sub-CPU 32 (S48).

El acelerador 42 no tiene nada que ver con el HBCC y hay que tener en cuenta que tanto en PS4 como en Xbox One existen descompresores y compresores LZW por hardware en el uncore privado de la GPU, al desaparecer este uncore privado en la siguiente generación pasan a formar parte del uncore general. Hay que tener en cuenta que una vez los datos llegan a la RAM del sistema ya no estamos hablando del HBCC. ¿A que pieza se peude referir en concreto? En realidad son varias piezas, para empezar lo que es la descodificación y la descompresión . En cuanto a la pieza encargada del «Tampering» Yya hemos hablado de la misma con anterioridad en la actual entrada y lo destapare más adelante, no os preocupéis.

En cuanto a la sub-CPU 32… Aquí entramos en otro elemento confuso en cuanto a la patente porque es la sub-CPU 32 el dispositivo que tiene acceso a la SRAM a través de una unidad DMAC y el que tiene control sobre el mismo… De nuevo nos encontramos con texto y la FIG.1 contradiciendose por completo por lo que…

La única manera de que cuadren las cosas es que la unidad DMAC de la Sub-CPU 32 por un lado y el Controlador Huesped 22 que conectan con la SRAM sean por lo tanto el mismo dispositivo y nos dos diferentes y ambos de manera combinada resulten el HBCC.

En la patente nos describen una lista de tareas de la sub-CPU 32 y coinciden por completo con las tareas del HBCC de AMD.

La CPU principal 30 se encarga del siguiente procesamiento en la actual encarnación como se describe debajo:

1. Calcular el valor hash desde el nombre del archivo.
2. Buscar una lista hash
3. Realizar una petición a la sub-CPU 32.

Esto deberia poder hacerlo tanto la CPU del sistema como la GPU, pero la GPU no aparece en la patente para simplificar.

La sub-CPU 32 se encarga del siguiente procesamiento en la encarnación actual.
1. Dividir una petición de la CPU principal 30 en bloques de datos de tamaño fijo.
2. Adquirir una direccón lógica de un area donde los datos comprimidos han sido almacenados ahciendo referencia a una tabla de compresión.
3. Enviar una petición al controlador flash 18 
4. Pedirle al acelerador 42 que realice el procesamiento como la comprobación del tampering en los datos leidos.
5. Notificar a la CPU principal 30 cuando los bloques que forman el archivo original han sido leidos.

El acelerador 42 como he dicho antes son varios aceleradores realmente. Pero el que nos interesa es el Cryptographic Coprocessor, el cual se encarga del Tampering… ¿Y que significa esto? Basicamente lo que hace es comprobar que el contenido que entra tenga un sello de autorizacion (DRM) y si dicho sello no se encuentra entonces lo que hace es evitar el acceso a esos datos en la RAM del sistema marcando con un tag al controlador de memoria que esos datos no se se deben leer ni tampoco escribir sobre ellos. Desde el momento en que se encuentran en el area correspondiente al kernel y por tanto al sistema los juegos no van a tener acceso a esos datos jamás y va a depender de que el coprocesador criptográfico diga si o no para que esos datos sean visibles en la otra area de la memoria. El Cryptographic Coprocessor ha de reemplazar el PS5 el ARM del Southbridge y tener el nivel de privilegios más alto (-3) con tal de que la CPU no anule su autoridad sobre los datos que son accesibles y cuales no.

La idea principal de la patente es utilizar la SRAM asociada al HBCC/sub-CPU 32 para que esta haga de cache y recortar enormemente el tiempo de acceso a los datos al estar estos en dicha SRAM funcionando como cache de datos. No solo eso sino que el uso de la SRAM como cache intermedia de datos nos permite alargar la vida útil de la Nand Flash que por densidad y precio será una TLC e incluso una QLC y por tanto vendra con una menor cantidad de ciclos de uso.

En cuanto a la memoria flash el diagrama nos habla de 4 canales de acceso en total desde el controlador de memoria de la misma, el cual creo que hace referencia a un controlador PCIe de 4 lineas. Teniendo en cuenta que la interfaz será PCIe 4.0 cuando aparezca PS5 en el mercado…

Estamos hablando de una velocidad de casi 8 GB/s que coincide en tiempo en lo visto en el video de Sony de hace unos dias.

Por lo que como mínimo el sistema tendria un SSD M.2 incluido de serie en la placa o vendra de serie con la consola conectado a su interfaz. Existe la posibilidad de que cada uno de los 4 canales de la patente no haga mención a una linea PCIe sino a una interfaz M.2 conectada cada una interfaz PCIe 4.0 x16. Es decir, que la consola tenga capacidad de expansión a futuro con 4 modulos M.2 aunque venga solo con uno.

Esto es todo, como siempre tenéis el Discord y los comentarios de la misma entrada para comentar el contenido de la misma.