Los orígenes del procesador principal de la Nintendo 64 comienzan con el MIPS R4000, la nueva CPU de vanguardia de MIPS. Lanzada en 1991, la novedad más ostensible del R4000 fue la inclusión de capacidades de 64 bits, fruto de ensanchar los buses, registros y unidades de cálculo para manipular valores de 64 bits con eficiencia. Los desarrolladores, por su parte, accedieron a estas capacidades a través del nuevo set de instrucciones MIPS III. En líneas generales, el R4000 permitió que nuevas aplicaciones pudieran manejar bloques de datos más grandes sin consumir ciclos adicionales.
Para su consola de nueva generación, Nintendo investigó la posibilidad de llevar hardware industrial al hogar. A diferencia de Sony, que disponía de una gran cantidad de componentes propios y solo necesitaba un proveedor secundario de CPUs MIPS, Nintendo se asoció directamente con los propietarios de MIPS (y de numerosas estaciones de trabajo gráficas) para co-diseñar todo su ecosistema. Esa compañía era Silicon Graphics Incorporated (SGI).
En las oficinas de SGI, el R4000 era un producto costoso (alrededor de $400 ), lo que lo hacía prohibitivo para una consola de videojuegos. Aun así, Nintendo no quería renunciar a sus ambiciones tecnológicas de vanguardia, así que optaron por una variante de gama baja llamada R4300i, de la que NEC pudo actuar como segundo proveedor.
La CPU MIPS R4300i (1994).
Al final, Nintendo y SGI se decantaron por la NEC VR4300 funcionando a 93,75 MHz . Se trata de una versión con compatibilidad binaria del MIPS R4300i que incluye :
- Dos modos de operación:
- Modo de 32 bits: Modo tradicional en el que la CPU se comporta como un procesador compatible con MIPS II. No hay nada especial en este modo, salvo que todas las nuevas funcionalidades quedan bloqueadas.
- Modo de 64 bits: Modo 'nativo' donde todas las extensiones de 64 bits están disponibles. También es compatible a nivel binario con aplicaciones de 32 bits.
- 32 registros de uso general: De 32 bits de ancho en modo de 32 bits, y de 64 bits en modo de 64 bits.
- Set de instrucciones MIPS III: Un set de tipo RISC sucesor del MIPS II. Introduce nuevos opcodes para calcular palabras de 64 bits denominadas 'doublewords'. Las instrucciones son siempre de 32 bits de longitud, independientemente del modo.
- Cabe mencionar que, a partir de MIPS II, los load delay slots pasaron a ser opcionales. En su lugar, el hardware puede trabar o detener automáticamente el pipeline para evitar riesgos de datos. Resulta curioso que esto contradiga la filosofía original de las siglas MIPS.
- Curiosamente, los branch delay slots siguen presentes, aunque se añadieron nuevas instrucciones de salto que permiten descartarlos. Eso sí, dichas instrucciones fueron eliminadas en revisiones posteriores del set .
- Un bus interno de 64 bits conectado a un bus de datos externo de 32 bits: Aunque las operaciones con doublewords no penalizan el rendimiento cuando se ejecutan internamente, mover datos de 64 bits por el resto del sistema implica ciclos adicionales.
- Éste es uno de los recortes de la variante R4300i (el R4000 dispone de un bus de datos completo de 64 bits).
- Bus de direcciones de 32 bits: Capaz de direccionar hasta 4 GB de memoria física.
- Pipeline de cinco etapas: Hasta cinco instrucciones pueden asignarse para ejecución simultánea (encontrarás una explicación detallada en un artículo anterior).
- 24 KB de caché L1: Repartidos en 16 KB para instrucciones y 8 KB para datos.
El paquete también incluye una Unidad de Punto Flotante (FPU, del inglés 'Floating Point Unit') integrada. La VR4300 la denomina coprocesador (CP1); sin embargo, la unidad está ubicada junto a la ALU y solo se accede a ella a través del pipeline de ésta, por lo que en la práctica no hay coprocesamiento como tal. Dicho esto, la FPU dispone de su propio banco de registros dedicado y acelera las operaciones con números de punto flotante de 64 y 32 bits. Para terminar, esta unidad cumple con el estándar IEEE 754.
Simplificando el acceso a la memoria
La forma en que se ensambla la RAM sigue la Arquitectura de Memoria Unificada (UMA, del inglés 'Unified Memory Architecture'), donde toda la RAM disponible se centraliza en un único lugar y cualquier componente que necesite acceder a la RAM lo hace desde esa ubicación compartida. El árbitro de ese acceso es, en este caso, la GPU.
Este diseño se escogió principalmente por el considerable ahorro que supone en costes de fabricación; aunque si no se gestiona bien, también incrementa la contención de accesos.
¿Sin controlador de DMA?
Como consecuencia de la arquitectura de memoria unificada, la CPU ya no tiene acceso directo a la RAM. Por ello, la GPU también proporciona la funcionalidad de Acceso Directo a Memoria (DMA).
Diseño de la memoria
Al margen de la UMA, la estructura de la RAM es algo más enrevesada, así que intentaré explicarlo de la forma más sencilla posible. Allá vamos...
El sistema dispone físicamente de 4,5 MB de RAM; sin embargo, está conectado mediante un bus de datos de 9 bits, donde el 9º bit está reservado para la GPU (lo explico con más detalle en la sección 'Gráficos'). Como consecuencia, todos los componentes salvo la GPU solo podrán acceder a un máximo de 4 MB.
Organización de la memoria del sistema. Asumo que la velocidad del bus CPU-RCP coincide con la velocidad de reloj del RCP o de la CPU.
El tipo de RAM instalada en la placa se llama Rambus DRAM (RDRAM) . Este fue otro diseño que compitió con la SDRAM para convertirse en el siguiente estándar. La RDRAM emplea una arquitectura serie rápida (donde los módulos de memoria se encadenan en secuencia), mientras que la SDRAM utiliza una conexión paralela más lenta (conectando todos los módulos directamente al controlador de memoria). Cada una tenía sus ventajas e inconvenientes, tanto técnicos como comerciales. Con todo, conviene señalar que, aunque la SDRAM acabó imponiéndose, la RDRAM siguió apareciendo en generaciones posteriores de consolas, con nuevas revisiones del protocolo en cada una.
Por último, la Nintendo 64 implementó la variante Base RDRAM , la primera revisión del protocolo.
Latencia y velocidad
Aunque las instalaciones RDRAM requerían menos cableado y disfrutaban de frecuencias de reloj más altas que la SDRAM, la latencia de acceso aumentaba proporcionalmente con el número de bancos instalados . En el caso de la Nintendo 64, el tiempo que mediaba entre iniciar una operación de memoria y encontrar el valor en caché era considerable: alrededor de 640 ns . Los ingenieros intentaron aliviarlo dotando a los bancos de memoria de una frecuencia de reloj elevada, de 250 MHz (aproximadamente 2,6 veces más rápida que la CPU). De este modo, Nintendo afirmó que la RDRAM podía alcanzar transferencias de hasta 500 MB/s al leer o escribir datos consecutivos .
Como curiosidad, Nintendo eligió los bancos de memoria uPD488170L de NEC para la placa base de la N64 . Estos chips implementan una tecnología conocida como 'Rambus Signaling Logic', un hiperónimo que engloba numerosas mejoras, entre las que destaca una que duplica la tasa de transferencia . Esto puede explicar por qué algunas fuentes citan la velocidad 'efectiva' de la memoria como 500 MHz.
Dejando margen para mejoras
Curiosamente, la cantidad de RAM disponible en esta consola puede ampliarse instalando el accesorio Expansion Pak: una peculiar cajita que añade otros 4,5 MB. Mientras que este accesorio fue opcional para algunos juegos (y la mayoría ni lo aprovecharon), ciertos títulos como Donkey Kong 64 y The Legend of Zelda: Majora's Mask se diseñaron con la expansión como requisito, y mostraban una pantalla de error si no estaba enchufado.
El Expansion Pak , un accesorio opcional vendido por separado (a veces incluido junto al juego que lo requería).
El Jumper Pak . En ausencia del Expansion Pak, este debe estar presente para terminar el bus RDRAM.
Debido a su diseño de extremo a extremo, la RDRAM debe estar correctamente terminada; de lo contrario, las señales rebotan de un lado a otro por el bus (un fenómeno bien conocido como reflexión). Rambus lo mitigó exigiendo a los usuarios de PC que instalaran los módulos de memoria en pares y rellenaran las ranuras vacías con módulos 'Continuity RIMM' (CRIMM), que actuaban como terminadores. En el caso de esta consola, Nintendo incluyó un terminador llamado Jumper Pak, instalado de serie en el hueco del Expansion Pak. El Jumper Pak solo alberga los condensadores y resistencias justos para igualar la impedancia del bus , reduciendo así la reflexión. También sirve para cerrar el bucle de la cadena serie .
Llegados a este punto, cabe preguntarse: ¿qué pasaría si encendiéramos la consola sin ningún Pak instalado? Pues bien, los chips de memoria de la placa no funcionarían, la secuencia de arranque fallaría y no saldría ninguna señal de vídeo.
Gestión de memoria
El VR4300 incluye otro coprocesador conocido como System Control Coprocessor (CP0), compuesto por una Unidad de Gestión de Memoria (MMU, del inglés 'Memory Management Unit') y un Translation Lookaside Buffer (TLB). La MMU controla cómo se organiza la memoria y cómo se gestiona su caché.
Aunque la CPU es capaz de direccionar hasta 4 GB de memoria, la Nintendo 64 dispone de mucha menos, incluso teniendo en cuenta la E/S mapeada en memoria. Por eso, la MMU aprovecha el limitado espacio de direccionamiento ofreciendo un mapa de memoria virtual en el que la memoria física se espeja varias veces. En consecuencia, las ubicaciones de memoria se tratan como direcciones virtuales (en contraposición a las 'direcciones físicas'). Además, el TLB permite a los desarrolladores definir mapas de memoria personalizados en algunos espejos sin penalizaciones de rendimiento (significativas).
A primera vista puede parecer redundante, pero cada espejo (denominado segmento) está conectado a circuitería distinta (por ejemplo, caché L1, RAM física o regiones mapeadas con TLB), lo que permite a los desarrolladores optimizar el uso eligiendo el segmento más adecuado según las necesidades .
Algunos segmentos se diseñaron para distinguir entre ubicaciones de 'kernel' y de 'usuario' por motivos de seguridad. Sin embargo, la N64 siempre opera en modo 'kernel', lo que convierte al segmento 'kernel cacheado sin TLB' (llamado 'KSEG0') en el más habitual para los juegos.
Por último, la MMU también puede funcionar en modo de 64 bits, donde las direcciones de memoria son de 40 bits. Esto ensancha el espacio de direcciones virtuales hasta aproximadamente 1 TB... ¡aunque dudo mucho que la Nintendo 64 llegue a aprovecharlo!