La siguiente sobremesa de Nintendo “será”/podría ser como sus antecesoras tecnicamente hablando

Esto es una continuación de la entrada del otro día sobre la futura consola de sobremesa de Nintendo..

Resulta que mirando por ahí he encontrado un documento de la propia AMD que habla de un concepto llamado PIM (Processor in-Memory), es interesante porque tiene cierta información con lo comentado en anteriores entradas de esta serie. Tengo que decir que he añadido algunos diagramas e imagenes para ilustrar mejor las explicaciones del documento.

Los escenarios anticipados del Wide I/O y el HBM, así que como los estudios académico de memoria 3D apilada, predominantemente asumen dos organizaciones: (1) apilado directo (3D) de la memoria sobre el procesador o apilado  “2.5D” donde el procesador/procesadores son montados uno al lado del otro por un interposer de silició.

amd_bryan_black_2-5-3d_400x150

La primera organización provee el beneficio de una unión estrecha entre el procesador y la memoria pero aumenta los desafíos termales.Como resultado la envoltura termal del procesador debe ser constreñida para evitar la excesiva degradación del tiempo de retención de la memoria apilada, reduciendo el pico de rendimiento. La tasa de refresco de la RAM también necesita ser incrementada dado el calor disipado por el procesador, reduciendo aún más el rendimiento. Estas limitaciones pueden limitar una buena fracción del rendimiento potencial de las memorias apiladas, especialmente en sistemas de alto rendimiento. Además, la capacidad de memoria que puede ser apilada esta limitada a la forma y tamaño del procesador.

Captura de pantalla 2014-12-02 a la(s) 12.32.11

Captura de pantalla 2014-12-02 a la(s) 12.14.46

 

En este caso tenemos el SoC (Procesador) en la parte inferior de la base y lo que pone Logic Die es la interfaz con la memoria (eso lleva a confusión ya que en mucha documentación lo que es el SoC es llamado “Logic Die”), las bolas grises son las interfaces TSV por la cual se comunican lo datos (el cableado vamos), como veis tenemos unas cuatro memorias apiladas y cada una de ellas conectada a un canal de memoria en el caso del Wide I/O 2 y unas 8 memorias en el caso del HBM. Aunque ambas interfaces se basan en los mismos parámetros, en realidad la interfaz HBM es una WideIO de segunda generación de 1024 bits:

40339_03_amd_to_release_its_radeon_r9_390x_early_next_year_20nm_with_hbm_tech

En este mapa de ruta se ven mucho mejor las diferencias entre el HBM y el Wide I/O estándar de segunda generación:

HBM-Memory-Roadmap

Así pues, tenemos un bus de 512 bits y 800Mbps en el caso del Wide I/O 2 y un bus de 1024 bits y 1000Mbps en el caso del HBM, los conceptos en ambos buses son los mismos pero la diferencia esta en que el HBM al tener un ancho de banda mayor se le pueden conectar hasta 8 chips de memoria. No obstante puedes tener configuraciones de 1024 bits con n chips de memoria por ejemplo ya que al contrario de la GDDR5 el número de chips en el apilado es independiente a la interfaz, que es siempre la misma y no varía, un ejemplo son los chips HBM de primera generación que como se ve en el mapa de ruta de arriba tienen un bus de 1024 bits y esta compuesto por cuatro chips de memoria tal y como se ve en el siguiente extracto del catálogo de SK Hynix (que es el proveedor de AMD para este tipo de memorias):

HBM

Eso si, no se pueden sobrepasar ciertas condiciones termales y de consumo, es por ello que el apilado 3D esta pensado para ser utilizado en procesadores de bajo consumo ya que superadas ciertas condiciones optimas en cuanto a consumo y calor es recomendable tirar de la otras opciones, ¿pero cuales son esas condiciones? Sobre este tema ya se entrará más adelante, por lo que lo mejor es entrar en otras opciones.

La segunda organización (2.5D) reduce las preocupaciones termales pero añade el coste adicional de un interposer e introduce sobrecargas de consumo y latencia debido que los accesos a la DRAM se hacen a través del interposer.

Interposer

El ancho de banda a través del interposer también puede ser más bajo que el del apilado 3D debido a que es difícil tener tanto cableado en el interposer como en los TSV que hay en el apilado 3D, necesitando una reducción en los canales de comunicación paralela y el ancho de banda.

En el segundo caso nos permite colocar un procesador más potente (desaparecen las limitacione termales) y una mayor densidad de memoria RAM pero lo hace sacrificando ancho de banda (el interposer hace de interfaz de memoria y enrutador común para todos los componentes del sistema). El hecho de que no haya un contacto directo entre la memoria y el procesador añade latencia respecto a la primera opción por la distancia del cableado (los electrones tardan más en viajar). La ventaja es que permite añadir una mayor cantidad de pilas de memoria pero el aumentar la densidad en este caso no aumenta el ancho de banda por el hecho que no existe una interfaz por cada pila y/o chip de memoria sino que la interfaz es común entre todos los chips de memoria.

Una tercera alternativa, adoptada en el HMC (Hybrid Memory Cube), es integrar solo los controladores de memoría y otra lógica de soporte de la memoria en la base de las pilas de memoria.

Captura de pantalla 2014-12-02 a la(s) 13.50.06

 

El procesador  no esta apilado con la memoria y se comunica con las pilas de memoria a través de conexiones a nivel de placa base o a través de enlaces en el empaquetado común. Este enfoque evita las limitaciones termales y de capacidad pero se queda corto en los beneficios de los apilados 3D o 2.5D apara aplicaciones que son intensivas del ancho de banda.

Una vez explicadas las diferencias vamos a entrar al concepto que explica la GPU de AMD en el documento, el llamado PIM o (Procesador en memoria).

AMD-PIM-Architecture

 En el documento de AMD se puede encontrar una descripción de este tipo de arquitectura:

El enfoque que hemos considerado y que se muestra en la Figure 1 (Nota de Urian: Es lo mismo que la diapositiva que hay encima), combina lo aspectos deseables de las tres organizaciones descritos arriba de arriba.

  1. Los procesadores en memoria incorporados en la base de las pilas de memoria proveen el ancho de banda completo y la evidencia del apilado 3D para ejecutar aplicaciones que son intensivas en cuanto memoria.
  2. Esto alivia las demandas de ancho de banda en los enlaces entre el huésped y la memoria, permitiendo interconexiones a nivel de placa base y de empaquetado para esos enlaces, al contrario que de las organizaciones 2.5D basados que requieren el uso de los interposers.
  3. El procesador huésped no tiene memoria apilada, por lo tanto evita las limitaciones termales, y puede soportar código altamente intensivo.

Sigamos

Tanto el procesador huesped como los procesadores en memoria (PIM) de nuestra organización de sistema son unidades aceleradas de procesamiento (APU). Cada APU consiste en núcleos CPU y GPU en una misma pastilla de silicio.

Por lo que tenemos una configuración curiosa con una APU maestra y varias APUs esclavas, las APUs esclavas se encuentran una en cada pila de memoria utilizando la primera configuracion de las anteriormente descritas.

Captura de pantalla 2014-12-02 a la(s) 10.22.36

Obviamente las APUs que se encuentran debajo de las pilas de memoria tienen que tener unas limitaciones térmicas y de consumo concretas tal y como hemos dicho antes.

Las configuraciones de los procesadores en-memoria estaban también limitadas para no sobrepasar los 10W de potencia de diseño térmico.

Esta información del documento nos permite saber que el limite de consumo en el que un procesador puede ser colocado apilada 3D utilizando tecnología TSV y sin interposer por el medio es de unos 10W. Esto es importante por el hecho que nos permite saber en que condiciones se enfrentaran aquellos que quieran diseñar sistemas utilizar configuraciones 3D TSV y ahorrarse el interposer por el camino como medida para recortar costes en el sistema. Ahora bien, no le hagáis mucho caso a las especificaciones de la tabla ya que tiene en cuenta un tipo de procesador que ha de caber en el mismo área que en la memoria HBM tal y como se describe en el siguiente párrafo:

Historicamente, el tamaño de los chips de DRAM se han movido entre los 40-80mm2. Asumimos que el área de la base lógica (nota de Urian: Se refiere al tamaño del procesador) esta en el limite superior de ese rango (nota de Urian: cerca de los 80mm2 de área para el SoC/APU) y la cuenta de CUs no excede el 50% de dicha área (incluyendo las estructuras de hardware de apoyo, caches compartidas, etc).

Resulta ser que las pilas de memoria HBM son ciertamente pequeñas tal y como se ve en esta fotografía:

Hynix_DDR4_and_HBM

 

Y esta diapositiva:

Captura de pantalla 2014-12-03 a la(s) 10.14.22

En el caso de la siguiente sobremesa de Nintendo no habria procesador huesped sino que el PIM sería el procesador huesped pero no creo que Nintendo utilice la configuración descrita en el documento de AMD dado que el tamaño sería ridículo para una consola de Nintendo. Pero viendo la forma en la que diseñan sus sistemas a mi no me extrañaría (tal y como describí en la entrada anterior) que un SoC/APU hecho a medida con la memoria HBM apilada encima del procesador haciendo lo mismo que la MEM1 de Wii U, con la ventaja de pasar de los 32MB de densidad de 1GB y encima con un ancho de banda mucho mayor que en Wii U. Obviamente aún nos quedaría la MEM2 para otorgar el almacenamiento adicional en lo que a la RAM se refiere.

¿Tiene que ser acaso un chipset de AMD? No tiene porque, ya que las configuraciones de memoria descritas arriba son estandares de la JEDEC y no dependen de una marca concreta y desconocemos sí Nintendo va a seguir con AMD o en su defecto va a tirar por un camino distinto para su siguiente consola pero dado que Nintendo nunca ha roto ningún contrato con sus proveedores excepto por causas mayores esta claro que la relación con AMD de cara al diseño del nuevo sistema tiene muchos números que la mantengan, eso si, se habrían perdido por el camino la relación con Renesas e IBM (ambas fuera del mercado).

Eso si, en el caso de que Nintendo siga con AMD tengo muy claro que van a elegir una GPU con arquitectura GCN, ¿Los motivos? En uno de los Iwata Pregunta (que comente en la primera parte de esta serie) apareció mencionado el interés de Nintendo por la computacion de proposito general desde una GPU (GPGPU) y la arquitectura RV7xx de la GPU de Wii U aparte de anticuada y menos eficiente que la GCN no esta pensada para procesos GPGPU. El segundo motivo es que es una arquitectura que será altamente conocida entre los desarrolladores gracias a PS4 y Xbox One, pero dado que Nintendo no parece “arrepentida” del fiasco técnico de Wii y Wii U, les veo repitiendo la jugada en la siguiente consola de sobremesa de Nintendo. Luego sumad la ideología de desarrollo de Miyamoto, en la que es mejor equipos pequeños que grandes equipos y el hecho que llegado a un punto para demostrar la potencia de un hardware se necesitan grandes equipos y entonces todo el panorama cuadra.

A todo esto tengo que decir que no quiero ser pesimista, pero teniendo en cuenta el historial de Nintendo con los diseños de  Wii y Wii U yo no miraría lo que puede sacar Nintendo para igualar a Sony y Microsoft.  Ya que no han tenido ningún reparo en sacar una Wii U menos potente que Xbox 360 y PS3 para darle prioridad a un sistema de bajo consumo y a un diseño industrial concreto. Sinceramente no parece que Nintendo vaya a cambiar sus directrices en cuanto al diseño de sus consolas en un futuro próximo a no ser que decidan volcar la mesa del te y cambiar su forma de hacer sus sistemas, cosa que dudo estando Genyo Takeda al mando del departamento de hardware de Nintendo y conociendo cuales son sus prioridades pienso que lo mejor es estar preparado y no llevarse chascos en ese aspecto por hacerse falsas ilusiones.

Tengo que decir que es muy posible que me equivoque y espero equivocarme pero los ingredientes para el puchero están ahí y son esos.

Gracias por leerme y recordad que esta entrada es pura especulación.

Anuncios