NX Opción B (I)

Inicialmente esta entrada trataba sobre la opción Nvidia, pero al final he decidido convertirla en ARM+GPU de rendering directo, no os preocupéis, una GPU de rendering directo no es más que una GPU que no es un Tile Renderer y por tanto hablamos de una GPU convencional cuando lleguemos a esa parte, pero desde el momento en que hay varios candidatos aparte de Nvidia para el puesto tened en cuenta que hablare en términos más generales.

#1 Nintendo y el conjunto de instrucciones ARM.

Nintendo no es ajena al uso de procesadores ARM en sus consolas:

  • GBA, DS y 3DS en sus diferentes iteraciones utilizan CPUs con conjunto de instrucciones ARM.
  • Wii, Wii U y 3DS utilizan procesadores ARM para la seguridad del sistema.

¿Pero que es un conjunto de instrucciones? La Wikipedia nos lo explica muy bien:

Un conjunto de instrucciones, repertorio de instrucciones, juego de instrucciones o ISA (del inglés instruction set architecture, «arquitectura del conjunto de instrucciones») es una especificación que detalla las instrucciones que una unidad central de procesamiento puede entender y ejecutar, o el conjunto de todos los comandos implementados por un diseño particular de una CPU. El término describe los aspectos del procesador generalmente visibles para un programador, incluyendo los tipos de datos nativos, las instrucciones, los registros, la arquitectura de memoria y las interrupciones, entre otros aspectos.

Existen principalmente tres tipos: CISC (Complex Instruction Set Computer), RISC (Reduced Instruction Set Computer) y SISC (Simple Instruction Set Computing).

La arquitectura del conjunto de instrucciones (ISA) se emplea a veces para distinguir este conjunto de características de la microarquitectura, que son los elementos y técnicas que se emplean para implementar el conjunto de instrucciones. Entre estos elementos se encuentran las microinstrucciones y los sistemas de caché.

Procesadores con diferentes diseños internos pueden compartir un conjunto de instrucciones; por ejemplo, el IntelPentium y AMDAthlon implementan versiones casi idénticas del conjunto de instrucciones x86, aunque tienen diseños diferentes.

La gente suele pensar que el hecho de colocar un chip con arquitectura ARM como CPU significa poca potencia, eso es un mito estúpido desde el momento en que eso solo marca el conjunto de instrucciones y punto, pueden haber chips ARM que sean mejores que los x86, pueden haber chips x86 que sean peores… dependiendo siempre de la arquitectura del procesador.

Ahora bien… ¿Cuáles pueden ser los motivos por los cuales Nintendo puede escoger una CPU ARM para su NX? Hay varios motivos para ello.

  1. Familiaridad. Nintendo lleva trabajando en ellos desde hace ya más de diez años, tiene gente experta programando para dicho conjunto de instrucciones desde el lanzamiento de GBA, mientras que la familiaridad con la arquitectura x86 es nula.
  2. Transición desde el conjunto de instrucciones PowerPC. Ciertas cosas se tendrán que realizar a bajo nivel, esto significa ir a ensamblador y os sorprenderá mucho pero aún hay cosas hoy en día que se hacen en ensamblador. Obviamente no hablo del desarrollo de medios de consumo (juegos) sino del desarrollo de medios de producción y esta tarea es trabajo de Nintendo, la cual hasta ahora ha trabajado con el conjunto de instrucciones PowerPC en sobremesa. Pues bien, tanto PowerPC como ARM son arquitecturas RISC en lo que a su conjunto de instrucciones se refiere, es decir, de carga/almacenamiento y su código ensamblador es muy similar el uno del otro.
  3. Opciones. x86 solo te da dos opciones Intel o AMD, los cuales venden diseños completos, en el caso de Intel esta no hace SoCs a medida del cliente, es posible que Nintendo quiera un SoC a medida y por tanto Intel queda fuera por eso. Sobre AMD ya hable en la opción A, pero queda fuera por no tener un procesador ARM.
  4. Regalías. Las regalías por colocar una CPU ARM son mucho más bajas que por colocar una CPU x86, es decir, el pago por el uso del conjunto de instrucciones es más bajo.

Una vez explicados los posibles motivos por los cuales Nintendo puede escoger una CPU con un conjunto de instrucciones ARM tenemos que ir a la utilidad en los sistemas de la compañía.

#2 El IOS/IOSU y NX OS

No, Nintendo no utiliza el SO de Apple, IOS viene de In/Out System y es el SO que corre dentro del chip ARM de Wii y Wii U. ¿Su trabajo? Controlar que el acceso a y desde los dispositivo de E/S se haga con software “seguro” y “confiable”, es decir, que este firmado por Nintendo. El IOS/IOUSU tampoco es el SO en el que corren los juegos, en el caso de Wii el Café OS que es el SO del sistema cuando necesita realizar una petición al Disco Duro Externo, la NAND Flash de la consola, o el lector BluRay de esta lo hace enviando peticiones al ARM9 colocado como CPU de seguridad, el cual funciona como un portero de discoteca.

Esta noche os he comentado una patente reciente de una consola con Disco Duro interno, en ella se habla de un hardware con dos software básicos, uno encargado de encender el sistema y el otro de mover la interfaz gráfica de usuario. Es una referencia al IOSU y al Café OS respectivamente en Wii U, la diferencia es que en dicha patente se mencionan los dos procesos en una consola de sobremesa como si se ejecutasen en el mismo procesador en vez de hacerse en procesadores distintos, esto nos lleva a tres escenarios:

  • Efectivamente se ejecutan en el mismo procesador, lo que sería una pista para el uso de la misma arquitectura.
  • Hablamos de un SoC, por lo que se pueden ejecutar en procesadores distintos.
  • Una mezcla de los dos, es decir núcleos distintos de una misma CPU.

El caso de 3DS es particular, tenemos un núcleo ARM ejecutando el SO, pero dicho SO hace el mismo trabajo que el IOS /IOUSU y no hay un SO complejo como ocurre en Wii U sino que las cosas funcionan más bien como en Wii donde el juego y las diferentes aplicaciones funcionan de forma nativa sobre el procesador pero con la diferencia de que el juego se queda con el primer procesador y en el segundo procesador corren el resto de aplicaciones junto al IOSU, corren haciendo uso de la potencia que le sobra al segundo procesador. En el caso concreto de New 3DS se han añadido dos núcleos adicionales a la CPU para darle más potencia para esas aplicaciones adicionales.

En el caso de Wii U aparte de tener funcionando el IOSU tenemos el Café OS que es el SO donde se ejecutan los juegos, el tema es que es más complejo y esta claro que NX utilizará una evolución de este, tanto en su versión portátil como en su versión de sobremesa.

WiiUOS

Si la CPU es un SoC de AMD x86 entonces es posible que el encargado de ejecutar el IOS sea el llamado PSP, el cual es un Cortex-A5 dentro de los SoC AMD. Si en cambio no lo es entonces uno de los núcleos de la CPU puede encargarse del IOS y otras funciones, mientras que el resto de núcleos del NX OS y de la ejecución de los juegos. Por cierto y como último añadido, por lo visto en Wii U no hay un núcleo dedicado al Cafe OS sino que este coge potencia de todos los núcleos, por lo que la carga del SO sobre la CPU disminuirá a medida que se aumente el número de núcleos.

#3  La CPU

¿Cuál es el núcleo que Nintendo podría utilizar? Hay que tener tres puntos esenciales:

  • La tecnología ha de estar disponible.
  • No puede ser un núcleo propietario.
  • Ha de estar disponible en el proceso de fabricación elegido.

Teniendo en cuenta estos puntos creo que la CPU éstara compuesta por uno o dos módulos del Cortex A57, tenéis un excelente artículo sobre su arquitectura aquí.

ARM-Cortex-A57

No me voy a entretener en este aspecto más tiempo porque acabaríamos teniendo un post kilométrico. ¿El motivo de escoger este procesador? Porque necesito un uncore de referencia para poder trabajar.

#4 El Uncore

El Uncore de los SoC con ARM por descontado no es igual que el que veríamos en los SoC de AMD, pero su funcionamiento vendría a ser más o menos el mismo en todos y de forma simplificada en un SoC moderno el siguiente:

SoCSimple

Es diferente al diagrama de los SoC de AMD que es el siguiente:

SoCAMD

Los diagramas estan muy pero que muy simplificados y son en plano general, pero os lo voy a explicar, se llama bus coherente cuando la información sobre el estado de la memoria RAM necesita ser compartida por varios procesadores. Es decir, si dos procesadores comparten el mismo espacio de la memoria entonces necesitan que el bus sea coherente entre ambos porque si uno cambia un dato que necesita el otro puede dar a error, el bus no-coherente en cambio se refiere al acceso a la memoria a una parte que esta asignada únicamente a dicho procesador, que en este caso es la GPU y el único momento en el que la GPU accede al bus coherente en el esquema de AMD es para acceder al espacio de la CPU, es decir, para tareas de apoyo a la CPU y por tanto como co-procesador GPGPU.

Pero en el esquema de los SoC con ARM para simplificar las cosas y para evitar males de cabeza han decidido que todos los accesos a memoria desde los diferentes componentes sean completamente coherentes y por un único camino, es decir, no existe un bus no-coherente en el modelo ARM a no ser que Nintendo en NX se rompa los cuernos para crear un uncore a medida para dar soporte a ello.

En fin, antes he hablado de que la CPU podría ser un Cortex A57, pues a este le corresponde el CoreLink CCN-504 como Crossbar Switch…

CoreLink_CCN-504_Diagram_large

o el CoreLink CCN-508.

CoreLink_CCN-508_Diagram_large

Antes de entrar en el tema de la RAM lo importante aquí es la cache de tercer nivel, la cual se encuentra en el mismo Xbar Switch/CCN-50n y por tanto puede ser accedido por todos los componentes que estén conectados al mismo y ademas de forma coherente por lo que un escenario típicamente Nintendo podría hacer el mismo papel que hace la MEM1/eDRAM en Wii U perfectamente.

“Los llamamos a ellos L3″… “pero actualmente esto es un mal nombre. La realidad es que son una pieza muy poderosa de microarquitectura.” Si, la cache L3 funciona como cache L3 para los núcleos de computación, los cuales tienen sus propias caches L1 y L2, por supuesto, pero también funcionan como un cache de E/S, de alto rendimiento y flexible para todo el sistema permitiendo el movimiento de datos no solo entre las CPUs, los dispositivos de E/S o los aceleradores enganchados al bus, pero también entre los mismos dispositivos.

Hablando de velocidades, ARM afirma que cuando funciona a 2Ghz, el CoreLink CCN-508 es capaz de entregar hasta 1.6 TB/seg de ancho de banda utilizable.

Como en muchos elementos en la arquitectura CoreLink CCN-5xx, las cache L3 son distribuidas, descentralizadas y escalables. En el CoreLink CCN-508 por ejemplo hay ocho particiones escalables desde los 128KB a los 4MB por partición.

Es decir que tenemos en la configuración máxima una cache L3 de 32MB divida en 8 particiones de 4MB cada una y un ancho de banda total de 1.6 TB/seg, lo cual es una burrada, pero como bien sabéis podemos reducir la velocidad de reloj de la cache L3 para obtener una más adecuada para las necesidades de la consola y que consuma mucho menos.

La contrapartida por el uso de los 32MB para la cache L3 es que obliga al uso de 4 controladores DDR4, por lo que ambas cosas combinadas hacen que el tamaño del SoC no sea precisamente pequeño, en todo caso unos 32MB son una cifra que ha dado ciertos problemas a Xbox One en el tema de la resolución, pero ya sabemos que Nintendo no apunta tan alto.

No obstante hay que aclarar la diferencia entre el modelo Nintendo para la MEM1 y el modelo de Xbox One con la ESRAM, el modelo de Xbox One es el siguiente:

SocXBoxOne

En cambio en el caso de Nintendo en sobremesa la configuración vendría a ser la siguiente:

SoCNintendo

Como veis no es la misma configuración aunque ambos sistemas hagan uso de la memoria embebida.

#5 RAM

Aquí llegamos al quid de la cuestión, en varias entradas os he dicho que unas de las obsesiones de Nintendo es la de ir reduciendo el número de chips en placa, una configuración con cuatro controladores DDR4 significan unos 16 chips de memoria en la placa base, lo cual es una barbaridad, no obstante os comente sobre la 3DS-DDR4 en la entrada anterior  y creo que es la mejor candidata en este caso.

¿Cual es el problema de combinar unos 32MB de SRAM junto a un bus de 256 bits DDR4? Pues que el chip resultante precisamente pasa a no ser pequeño precisamente, en todo caso estaríamos hablando de que colocando un bus de 256 bits DDR4 tendríamos unos 16GB de memoria, hasta ahora he estado especulando con 8GB pero en el escenario en el que nos encontramos esos 8GB serían de un ancho de banda del 50%. Eso si, el escenario Nintendo difiere del escenario Xbox en un detalle, el hecho de que siempre texturiza desde la MEM1/eDRAM, la GPU en el escenario Nintendo nunca accede a la RAM principal excepto para volcar el búfer frontal de imagen, pero lo que son las texturas de la escena siempre las ha procesado desde la MEM1/eDRAM mientras que en Xbox One las texturas se acceden desde la RAM principal y de ahí que se necesite ese enorme ancho de banda para la lectura.

Ahora bien… ¿Es posible el escenario con la memoria HBM2? No hay que olvidar que la memoria HBM2 es un estándar de la JEDEC, pero esto significarían una serie de cambios respecto al modelo propuesto hasta ahora:

  • Supresión de la cache L3 (chip más pequeño), al ser redundante su utilización por la HBM2 o en su defecto reducción de la densidad de esta
  • Añadido del sustrato/interposer para la comunicación con la memoria HBM2.
  • Supresion de la memoria DDR4 cuya función sería sustituida por la de la HBM2.

En este caso la sustitución tendría que hacerse sobre los controladores de memoria, por lo demás el resto del SoC se podría dejar igual. En fin, esto se ha hecho ya muy largo, dejemos la GPU para la segunda parte de esta entrada, la cual será más corta que esta.

 

 

Anuncios