Arquitectura de la PlayStation

Esta sección disecciona el Sony CXD8530BQ, uno de los dos grandes chips que alberga esta consola. Es lo que hoy llamaríamos un 'System-on-Chip'.

Los orígenes

El procesador principal responde a uno de esos esquemas del tipo 'X diseñado por Y, basado en Z y fabricado de segunda fuente por W', demasiado denso para resumirse en pocas frases. ¿Por qué no comenzamos con algo de contexto histórico?

Un poco de historia

Un Macintosh Quadra 700 junto a una tarjeta de actualización PowerPC. Como ocurrió con muchos usuarios de la Motorola 68k, los 90 marcaron el inevitable giro hacia las CPU basadas en RISC (en el caso de Apple, el PowerPC).

Los primeros años noventa estuvieron marcados por un punto de inflexión en la fortuna de muchas CPU populares. Los otrora dominantes procesadores de 8 bits, como el Z80 y el 6502, habían quedado ya en un segundo plano, y la famosa 68000 de Motorola, junto con otros diseños de 16 bits que habían cosechado éxito a finales de los 80, eran ahora candidatos a la sustitución. Incluso en el campo de los PC, Andrew S. Tanenbaum, en su célebre debate con Linus Torvalds, predijo que la arquitectura x86 de Intel solo le quedaban cinco años antes de desaparecer del mercado doméstico.

A primera vista, podría parecer que el desarrollo tecnológico había llegado a un punto muerto. Sin embargo, una nueva oleada de CPU relativamente desconocidas comenzaba a abrirse paso en los dispositivos de consumo. Muchos de estos diseños tenían su origen en el ámbito académico, con la intención de demostrar principios de diseño concretos. Entre los ejemplos más destacados de aquella época encontramos:

• MIPS: adoptada por Silicon Graphics Incorporated (orientada a estaciones de trabajo gráficas).
• PowerPC: adoptada por Apple (orientada a la autoedición).
• SPARC: desarrollada por Sun Microsystems (orientada a servidores y estaciones de trabajo empresariales).
• ARM: desarrollada por Acorn, inicialmente orientada al mercado doméstico, antes de expandirse a las PDA, los teléfonos móviles y otros dispositivos integrados.
• ... y muchos más chips de 'microcontrolador' que aún no habían sido finalizados ni adoptados por ningún sector importante —como el SH de Hitachi y el V810 de NEC—. Para sorpresa de todos, estos fueron posteriormente elegidos para la Sega Saturn y la Nintendo Virtual Boy, respectivamente.

Todos estos procesadores tenían algo en común: se adherían a la disciplina del Ordenador de Set de Instrucciones Reducido (RISC, del inglés Reduced Instruction Set Computer), que transformó radicalmente la manera en que se diseñaban y programaban estos chips. Una de las reglas de la arquitectura RISC dictaba que una sola instrucción no podía combinar el acceso a memoria con operaciones sobre registros. Esto permitió a los diseñadores de hardware simplificar la circuitería responsable de ejecutar instrucciones... y luego potenciarla con técnicas de paralelismo.

MIPS y Sony

El SGI Iris 4D/80, una potente estación de trabajo gráfica con diseño de torre doble. La serie 4D inauguró las CPU MIPS en los ordenadores SGI; este modelo en concreto incluye el procesador R2000 . Esta foto la tomé en el Computer History Museum (Mountain View, California) durante mi segunda visita, en marzo de 2025.

MIPS Computer Systems nació del afán de sus fundadores (profesores de Stanford) por convertir su investigación en procesadores reales. Esto encajaba bien con el apetito de los inversores de capital riesgo de Silicon Valley en los años 80, ansiosos por financiar este tipo de innovaciones . Su primera CPU, la 'MIPS R2000', está considerada el primer procesador comercial en incorporar un diseño RISC, y encontró hueco en numerosas estaciones de trabajo UNIX.

Sin embargo, no fue hasta 1987 cuando los chips de MIPS comenzaron a ser el centro de atención, gracias a su adopción (y posterior adquisición) por parte de Silicon Graphics Incorporated (SGI) para impulsar sus equipos. SGI fue una fuerza influyente en el mercado de los gráficos por ordenador, especialmente con el desarrollo de pipelines de vértices acelerados por hardware, una función que originalmente recaía en el software (dentro de la CPU). Tras la fusión, SGI consolidó una posición de liderazgo tanto en el sector de las CPU como en el de los gráficos.

Antes del desarrollo de la PlayStation, MIPS adoptó un modelo de negocio basado en la concesión de licencias de propiedad intelectual, en el que los diseños de CPU se vendían en forma de licencias, y los licenciatarios podían entonces personalizarlos y fabricarlos libremente. Entre sus productos figuraba la CPU R3000A, presente en su catálogo de gama baja. Como tal, la R3000A no pertenecía a la línea estrella (a diferencia de la R4000, que otros elegirían más adelante), pero resultaba una inversión atractiva en cuanto al coste.

Volviendo al tema que nos ocupa, Sony diseñó sus chips de audio y gráficos internamente, pero aún necesitaba el chip principal que los pusiera en marcha. La CPU elegida tenía que ser lo suficientemente potente para demostrar las impresionantes capacidades de los chips de Sony, sin dejar de ser asequible para mantener la consola a un precio competitivo.

LSI y el encargo

Al mismo tiempo, LSI Logic (un fabricante de semiconductores) era licenciatario de MIPS y ofrecía a empresas un programa de CPU 'a medida'. Este servicio, conocido como CoreWare, permitía a los clientes ensamblar paquetes de CPU personalizados eligiendo entre una serie de bloques modulares . Entre los componentes de la biblioteca CoreWare se encontraba el bloque 'CW33300', un núcleo de CPU derivado del LSI LR33300 —un chip de CPU de catálogo que LSI también comercializaba—.

¿Adónde quiero llegar con todo esto? Resulta que tanto el LR33300 como el CW33300 son compatibles en binario con la familia MIPS R3000A. Sus arquitecturas difieren ligeramente en algunos aspectos, pero la interfaz de programación (ISA MIPS I) es la misma.

Al final, Sony encargó a LSI la construcción de su paquete de CPU. Eligieron el CW33000, realizaron algunos ajustes e integraron todo con otros bloques para dar forma al chip que encontramos en la placa base de la PlayStation.

La oferta

El chip SoC en la placa base de la PlayStation, donde reside el núcleo basado en el MIPS R3000A.

El núcleo de CPU resultante funciona a 33,87 MHz y ofrece:

• La ISA MIPS I: la primera versión de la Arquitectura de Set de Instrucciones de MIPS. Entre otras cosas, utiliza palabras de 32 bits e incluye instrucciones de multiplicación y división.
• 32 registros de uso general y 2 registros de multiplicación/división: también de 32 bits. Uno de los registros de uso general (R0) está cableado a cero, un rasgo habitual en los diseños RISC.
• Bus de datos de 32 bits: en la PS1, este bus se bifurca en dos:
  • Bus principal (32 bits): conecta el MDEC y la GPU.
  • Bus secundario (16/8 bits): conecta el resto de componentes y la E/S. La conexión entre ambos la gestiona la Bus Interface Unit, que también permite acceder a puertos especiales de la GPU y la SPU.
• Bus de direcciones de 32 bits: permite acceder a hasta 4 GB de memoria física; es decir, RAM, E/S mapeada en memoria, etc.
• Pipeline de 5 etapas: permite procesar hasta cinco instrucciones simultáneamente (véase un artículo anterior para una explicación detallada).
• 4 KB de caché de instrucciones: también puede 'aislarse', lo que permite al programa manipular la caché de instrucciones directamente.
• Sorprendentemente, no hay caché de datos. El 1 KB de memoria que normalmente se reservaría para ella se mapea en una dirección fija . Esta área recibe el nombre de Scratchpad y se utiliza como 'SRAM rápida'.

Cuatro chips de 512 KB de RAM EDO.

Dicho esto, Sony dotó al sistema de 2 MB de RAM de uso general. Curiosamente, optaron por instalar chips Extended Data Out (EDO) en la placa base. Estos son algo más eficientes que la DRAM convencional y presentan menor latencia.

Tomando el control de la CPU

En determinados momentos, cualquier subsistema —los gráficos, el audio o la unidad de CD— necesitará grandes bloques de datos a alta velocidad. Sin embargo, la CPU no siempre es capaz de satisfacer esa demanda.

Por ello, el controlador de CD-ROM, el MDEC, la GPU, la SPU y el puerto paralelo tienen acceso a un controlador DMA dedicado cuando lo precisan. El Acceso Directo a Memoria (DMA, del inglés Direct Memory Access) toma el control del bus principal para realizar transferencias de datos de forma independiente. Esto se traduce en un ancho de banda considerablemente mayor que si la transferencia pasara por la CPU, aunque esta sigue siendo necesaria para configurar la operación DMA.

Cabe señalar que, una vez que el DMA entra en funcionamiento, la CPU no puede acceder al bus principal. Esto significa que la CPU quedará inactiva a menos que tenga algo en la Scratchpad con lo que mantenerse ocupada.

Complementando el núcleo

Al igual que otras CPU basadas en el MIPS R3000, el CW33000 admite configuraciones de hasta cuatro coprocesadores. Sony lo personalizó con tres:

System Control Coprocessor

Identificado como 'CP0', el System Control Coprocessor es un bloque habitual en las CPU MIPS. En los sistemas basados en el R3000, como este, el CP0 gobierna cómo se implementa la caché, lo que permite el acceso directo tanto a la caché de datos (en forma de 'Scratchpad') como a la caché de instrucciones (mediante el 'aislamiento de caché'). El coprocesador de control también gestiona interrupciones, excepciones y puntos de interrupción (breakpoints), estos últimos de gran utilidad durante la depuración.

Espera, ¿no deberían los coprocesadores limitarse a ampliar las funciones de la CPU? ¿Por qué el CP0 está tan estrechamente ligado a esta?

Efectivamente, los núcleos R3000 dependen del coprocesador de control del sistema para usar muchos componentes. Si esto debería ser 'legal' o no depende de cómo se interprete la palabra 'coprocesador'. Según MIPS, un coprocesador no es estrictamente una parte opcional de la CPU: también puede dirigir el entorno de esta (como la caché o las interrupciones). Por tanto, un coprocesador puede ser parte integral del sistema. Conviene tenerlo en cuenta al hablar de sistemas basados en MIPS.

Los posteriores sistemas basados en el R4000 incorporaron una Unidad de Gestión de Memoria (MMU, del inglés Memory Management Unit) y una Translation Lookaside Buffer (TLB) en este bloque, ampliando así sus capacidades y asumiendo nuevas funciones.

Geometry Transformation Engine

El 'CP2', o Geometry Transformation Engine (GTE), es un procesador matemático especializado que acelera los cálculos de vectores y matrices.

Aunque solo opera con tipos de punto fijo, ofrece operaciones de gran utilidad para los gráficos 3D, como:

• Multiplicación y suma de matrices o vectores, y cuadrado de vectores.
• Transformación de perspectiva (para proyecciones 3D).
• Producto vectorial de dos o tres vectores (el segundo caso se utiliza para el clipping).
• Numerosas funciones de interpolación con distintos parámetros.
• Depth cueing y valores de color derivados de una fuente de luz (para operaciones de iluminación y color).
• Promediado de profundidad (Z/depth averaging). Sospecho que se utiliza para la 'tabla de ordenación' (doy más detalles en la sección 'Gráficos').

No hace falta memorizarlo todo para seguir el resto del artículo. Basta con tener presente que el GTE se encarga de las etapas iniciales del pipeline gráfico, incluyendo la proyección 3D, la iluminación y el clipping. Con esto se generan los datos necesarios para enviarlos a la GPU y que esta los renderice.

Motion Decoder

El Motion Decoder, también llamado 'MDEC' o 'Macroblock Decoder', es otro procesador que convive con la CPU. En este caso, descomprime 'macroblocks' a un formato que la GPU puede interpretar. Un macroblock es una estructura de datos que contiene una imagen codificada de forma similar a JPEG.

El MDEC descomprime mapas de bits de 8×8 píxeles a 24 bpp (bits por píxel). En conjunto, el MDEC puede procesar 9.000 macroblocks por segundo , lo que permite reproducir un vídeo de movimiento completo (FMV, del inglés Full-Motion Video) de 320×240 px a 30 frames por segundo.

El DMA se utiliza para transferir datos comprimidos entre el CD-ROM, la RAM y el MDEC. El mismo recorrido se usa en sentido inverso, aunque en este caso el destino es la VRAM.

Aunque este componente reside dentro del SoC y comparte el mismo bus de datos, no es un coprocesador MIPS; la CPU y el DMA acceden a él a través del mapa de memoria, en lugar de interceptar instrucciones.

Para más información sobre el MDEC, recomiendo consultar los recursos de Sabin y Czekański .

¿Faltan unidades?

Hasta ahora hemos visto un 'CP0' y un 'CP2', pero ¿dónde está el 'CP1'? Pues bien, este está reservado para una Unidad de Punto Flotante (FPU, del inglés Floating-Point Unit) —y por desgracia Sony no incluyó ninguna—. Esto no significa que la CPU sea incapaz de realizar operaciones aritméticas con números decimales; simplemente no será suficientemente rápida (si se recurre a rutinas por software) ni especialmente precisa (si se trabaja con aritmética de punto fijo).

La lógica del juego (física, detección de colisiones y similares) puede apañárselas bien con la aritmética de punto fijo. La codificación en punto fijo representa los números decimales con un número inmutable de posiciones decimales. Esto conlleva una pérdida de precisión en ciertas operaciones, pero hay que recordar que estamos ante una videoconsola, no un simulador de vuelo profesional. En consecuencia, el equilibrio entre precisión y rendimiento puede considerarse razonable.

Por cierto, si quieres refrescar conceptos como 'punto fijo', 'punto flotante', 'decimal' o 'entero', te recomiendo echar un vistazo a la entrada de Gabriel Ivancescu .

Un sinfín de delays

Como ya hemos visto, el CW33300 es un procesador segmentado (con pipeline), lo que significa que encola varias instrucciones y las ejecuta en paralelo en distintas etapas. Esto mejora enormemente el rendimiento de instrucciones, pero sin un control adecuado puede dar lugar a riesgos de pipeline, con los consiguientes errores de cálculo.

La arquitectura MIPS I es especialmente susceptible a :

• Riesgos de control: instrucciones que se ejecutan cuando no deberían.
• Riesgos de datos: instrucciones que operan con datos desactualizados antes de que estos se hayan actualizado.

Instrucciones de 'Spyro The Dragon' visualizadas en el depurador NO$PSX. Obsérvese cómo LW (load word from memory), JAL (jump and link) y BNE (branch on not equal) van seguidas cada una de un delay slot para evitar riesgos. Las instrucciones marcadas en rojo (anteriores a la dirección 800597C4) son instrucciones de relleno (sin utilidad), mientras que las marcadas en azul realizan cálculos con propósito.

En consecuencia, las CPU MIPS I presentan el siguiente comportamiento:

• Cualquier instrucción que siga a un opcode de 'rama' (branch) o 'salto' (jump) se ejecuta incondicionalmente: por ello, los desarrolladores deben rellenar manualmente el pipeline con instrucciones modestas (como calcula 0 más 0) tras el salto para mitigar el riesgo. Estos rellenos se denominan branch delay slots.
  • Las CPU modernas convirtieron este fenómeno en una ventaja: la predicción de saltos. Al añadir circuitería para detectar el riesgo, la CPU puede descartar cálculos especulativos si la condición de rama o salto no se cumple; si se cumple, la CPU gana tiempo.
• Las instrucciones 'load' no detienen el pipeline hasta que el dato recuperado está disponible: la segunda etapa del pipeline (llamada RD o 'Read and Decode') recoge los operandos que se usarán en la tercera etapa (ALU) . La cuarta etapa (MEM, de 'access MEMory') busca datos en memoria (por ejemplo, en la RAM principal o en el lector de CD). El problema es que, para cuando una instrucción load obtiene el dato externo, la siguiente instrucción ya ha leído sus operandos. Por tanto, cuando una instrucción depende del dato de un load anterior, debe insertarse un relleno para garantizar que los operandos correctos se lean a tiempo.

Como ilustra el ejemplo , algunos delay slots se rellenan con instrucciones con propósito, que realizan cálculos no afectados por el riesgo. Por tanto, los delay slots no siempre equivalen a ciclos desperdiciados.

Una filosofía de base

Expuesto esto, quizás te preguntes por qué se comercializaría un procesador con tales defectos. Pues bien, uno de los principios de la filosofía RISC es que la carga de la programación de la CPU se traslada del desarrollador al compilador. MIPS, en particular, priorizó la producción de compiladores de alta calidad (incluyendo ensambladores) para acompañar a sus nuevas CPU . La empresa concebía que los desarrolladores usarían un lenguaje de alto nivel (como C) mientras que la cadena de herramientas se encargaba automáticamente de los riesgos, ya fuera reordenando instrucciones para rellenar los delay slots o insertando rellenos sin utilidad como último recurso.

De hecho, exponer el pipeline de la CPU a los desarrolladores era una estrategia de diseño fundamental en MIPS, como evidencia el propio acrónimo: 'Microprocessor without Interlocked Pipelined Stages'.

En definitiva, aunque no es agradable ver un programa rellenando la CPU de burbujas, creo que MIPS afrontó este reto de forma muy ingeniosa. Dicho esto, tampoco estuvo exento de inconvenientes. Como los años posteriores revelaron, exponer el pipeline complicó sobremanera la compatibilidad con versiones anteriores, especialmente a medida que las futuras CPU debutaban con microarquitecturas revolucionarias.