Twenty Two NX (II)

En la entrada anterior os empece a comentar los motivos por los cuales Nintendo podría utilizar el proceso de 22nm de IBM , propiedad ahora de Global Foundries. En la siguiente entrada voy a continuar hablando decomo componer el puzzle de este hipotético sistema derivado de Wii U. Para ello partire de la información de Wii U para construir el nuevo sistema y en especial el nuevo SoC, del cual empece a hablar en la entrada anterior.

Este es el diagrama principal de Wii U, cortesia de la gente de failoverflow:

blockdia_wiiu_full

En primer lugar nos interesa el Latte y no el el Espresso y en segundo lugar la compatilidad hacia atrás es con Wii U, no con Wii por lo que el elemento llamado GX que es lo que permite la compatibilidad hacia atrás lo descartamos ya que no nos hace falta, otro elemento que tampoco nos hace falta del diagrama es el DMCU HC11. Si miramos la descripción en Failoverflow nos dicen lo siguiente sobre este:

Habréis notado que el viejo buen VI (El controlador de pantalla /Video Interface de las viejas Wii y GameCube) ya no esta. ¿Eh, como funciona esto? Parece ser que lo están emulando en software y trasladando su configuración a los registros CRTC de del R7xx. ¿Pero donde se ejecuta esta software de emulación? Sigilosamente han añadido un microcontrolador especial al Latte solo para este propósito. El DMCU es una CPU de 8 bits compacte con la arquitectura 68HC11 cuyo propósito es realizar la emulación del VU. Tiene un calzador que en la “parte frontal” parece el VI para el software de Wii y por detrás traduce esos registros a lo de la Radeon incluyendo la configuración de rescatado… El DMCU no parece estar activo en el modo Wii U.

Es decir, si tenemos en cuenta la parte de que las consolas de Nintendo solo son retrocompatibles hacia atrás con las de la anterior generación por lo que esta pieza la podemos eliminar de la ecuación por completo cuando montemos las piezas para montar la NX.

Por otro lado tenemos que tener en cuenta que en cualquier procesador las piezas no están simplemente unidas las una con las otra sino que existe un control de señal y un enrutamiento. Mirando el diagrama sabemos que no informan de que hay varios elementos interconectados pero no sabemos como lo están. En todo hardware informático siempre hay un director de orquesta encargado de manejar las comunicaciones entre los procesadores que lo componen y los controladores de memoria conectados al mismo, dicha pieza suele recibir normalmente el nombre de “Northbridge/Puente Norte” pero habitualmente es conocida como Crossbar Switch.

¿Que ocurre cuando dos procesadores quieren acceder a un mismo destino? ¿Como lo hacemos para saber cual tiene preferencia y cual no? Pues de estas tareas se encarga el Crossbar Switch, el cual tiene un microcontrolador no programable por el desarrollador de aplicaciones encargado de monitorizar y vigilar todas las comunicaciones. Pensad en dicho microcontrolador pieza como un centro de control de tráfico ferroviario:

IMG_0085p

Donde el cableado por donde pasan los datos son las vías y por tanto el Crossbar Switch por lo que los datos son los trenes que se mueven alrededor de ellas. Obviamente en un sistema tan complejo tenemos varias entradas y varias salidas por lo que la configuración del cableado será la siguiente:

4_8

Todo sistema informático tiene uno o varios crossbar switch para las comunicaciones entre diferentes procesadores, en el caso de los SoC la parte de no-procesamiento pero si de control del tráfico de los datos y que se encuentra fuera del control de los programadores cuando realizan un programa se le llama hoy en día cololoquiamente como “uncore” que se podría traducir como “no-núcleo” para diferenciarla de partes como la CPU, GPU, DSP… A las que los desarrolladores si que tienen acceso. Dicho esto… ¿como sabemos cual es la configuración del Latte? Pues lo sabemos gracias a las patentes ya que la arquitectura general de Wii U es la misma que la de sus predecesoras:

Y si miramos el siguiente diagrama de GameCube veremos que el Nortbridge de las consolas de Nintendo desde GameCube se encuentra en el caso de Wii U en el Latte.

motherboard datapath

Me gustaría que le echarías un vistazo a la siguiente foto anotada del Latte, que hace la misma función que el Flipper en el diagrama de arriba.

latte_annotated-e1412283402547

Tenemos dos puertos 60Xe que conectan con el Espresso, el 60Xe es una versión extendida de 128 bits del bus 60X utilizado en los PowerPC de IBM, aquí podemos ver unas dos interfaces, la primera de ellas situada a la izquierda da un acceso a la eDRAM/MEM1 desde la CPU, la segunda situada en la parte derecha da un acceso directo a la GPU y al DSP de sonido, los cuales se encuentran en el área superior derecha del “Latte”… ¿Como se eso? Pues por la interfaz externa en la parte superior derecha que es la siguiente:

Captura de pantalla 2015-11-27 a las 12.34.21

Gracias a esta inferfaz sabemos que donde se encuentran tanto la GPU como el DSP y dada la proximidad de uno de los buses 60Xe entonces esta claro que mientras el primer 60Xe se utiliza para acceder a la MEM1, el segundo se utiliza para acceder al Northbridge haciendo que la arquitectura general de Wii U quede de la siguiente manera, eso si… hay una serie de elementos como la E/S que por motivos de no sobrecomplicar las cosas por el momento no lo he colocado en el diagrama.

WiiiU

El trabajo a hacer es pasar de esto…

Wii-CPUGPU

A que todo este en un solo chip por lo que el sustrato/interposer desaparecería y todo estaría en un mismo chip de manera unificada, es decir… A simple vista realizar lo siguiente:

WiiUSoc

¿Pero es el camino ideal? No olvidemos que en la entrada anterior hemos comentado el uso de una GPU con arquitectura Evergreen, una evolución de la arquitectura R700 de Wii U que entre otras cosas permite computación de propósito general desde la GPU, algo en lo que Nintendo esta muy interesada en implementar y que no permite la GPU de Wii U.

Iwata: Obtenéis la información más confidencial de Nintendo a tiempo.

Alex: Exactamente. Los desarrolladores de la sede central de Nintendo tienen que invertir su tiempo desarrollando la propia plataforma, por lo que nos gustaría explorar aquellas áreas para las que no tienen tiempo. Por ejemplo las posibilidades que se abren debido a la combinación de tecnologías de nube29 y nuevos paradigmas como la programación de GPU para un uso general30.Creo que ahora mismo nos encontramos en el lugar idóneo para crear las mejores nuevas ideas, pero tenemos que ser muy audaces y ambiciosos para ello. Por eso me alegro tanto de estar en NERD y no en ningún otro lugar.

Habitualmente las GPUs y las CPUs aunque fisicamente compartan memoria suelen tener las direcciones de memoria partida entre ellos y no llegan a acceder a los mismos datos… ¿Pero que ocurre cuando dos procesadores independientemente de su tipo tienen que acceder al mismo tipo de memoria? Entonces hace falta un Northbridge que permita un acceso coherente a la memoria y esto no es algo que cumpla el uncore de Wii U por lo que… ¿Vale la pena reciclar el Northbridge de Wii U en el nuevo sistema o tenemos otra opción mejor para ello? La respuesta es que tenemos una mejor opción para ello y es el uncore que AMD utiliza en sus APUs/SoC, el cual por lo general tiene la siguiente arquitectura:

DiagramaNX1

A partir de ahí podemos construir el sistema… ¿Que colocamos en los dos módulos de CPU? Pues que mejor que dos módulos “Espresso”, siendo cada módulo la CPU de Wii U pero integrada en el chip y con una mayor velocidad de reloj gracias a la reducción de tamaño de la misma.

espresso_layout

Con esto la CPU queda completamente dentro del SoC y eliminamos la necesidad del sustrato/interposer por un lado y de los puertos 60X en el SoC, por lo que podemos utilizar las interfaces externas para otras cosas. A nivel interno del SoC pasaríamos de tener una configuración de unos 3 núcleos a una configuración de unos 6 núcleos ya que tendríamos dos Espresso por lo que hemos solucionado el primer problema que es la integración de la CPU dentro del SoC. Pero no es el único problema con el que nos enfrentamos, si miramos el diagrama general de las consolas de sobremesa de Nintendo veremos que estas tienen tres pozos de memoria:

  • Memoria Interna (MEM1).
  • Memoria Externa (MEM2)
  • VRAM.

En el caso de Wii U la VRAM esta integrada en la MEM1 por eso no la he hecho aparecer, la VRAM es la utilizada para el búfer de imagen y es lo que le da el ancho de banda necesario a la GPU para operar. El acceso a las memorias interna y externa ha de ser coherente con la CPU, pero no el acceso a la VRAM, es por ello que lo mejor es que la memoria interna y la externa acaben unificadas como la RAM principal que estaría de forma externa al chip, mientras que el trabajo de la eDRAM seria el mismo que en Wii y GCN, hacer de VRAM para almacenar los búfers de imagen. Por lo que la cosa quedaría de la siguiente manera:

DiagramaNX2

En la siguiente entrada respondere algunos comentarios de la primera entrada y tocare el último punto de esta especulación, el de la RAM.

Anuncios