Ejecución fuera de orden, explicada con un RISC-V real

⏱️ Lectura: 10 min

Un desarrollador, sin equipo y sin financiamiento, publico un procesador RISC-V que ejecuta instrucciones fuera de orden y arranca Linux de verdad. No es una simulacion de juguete. Es un core superescalar de 64 bits, escrito en SystemVerilog, que corre el kernel 6.6.50 con BusyBox encima bajo memoria virtual Sv39, y que ademas cierra timing a 500 MHz en una libreria estandar de 45 nm (FURSOY/fursoy-cpu). Es un caso real, con codigo abierto y metricas publicadas, para entender que es la ejecucion fuera de orden y que la distingue de un procesador que ejecuta todo en el orden en que llego el programa.

📑 En este artículo

1. Que es Fursoy Slice-1
2. Ejecucion fuera de orden y superescalar: que significan en la practica
3. Por que el fuera de orden necesita memoria que no se bloquee
4. Lo que probamos: el laboratorio no encontro que compilar
5. Fursoy frente a lo que ya existe para aprender el kernel de Linux
6. Que significa esto para tu trabajo
7. Limitaciones y cuando no conviene mirarlo
8. Preguntas frecuentes
   1. ¿Puedo correr Fursoy en una FPGA de verdad?
   2. ¿Por que el lenguaje principal del repositorio es C++ si el procesador esta en SystemVerilog?
9. Referencias
   1. 📚 Artículos relacionados

Que es Fursoy Slice-1

Fursoy Slice-1 (fursoy_s1_core / fursoy_s1_soc) implementa el set de instrucciones RV64IMAFDV mas las extensiones Zba, Zbb, Zicsr y Zifencei: enteros, multiplicacion, atomicos, punto flotante simple y doble, y vectores (FURSOY/fursoy-cpu). Separa los tres niveles de privilegio de RISC-V (maquina, supervisor y usuario), implementa paginado por demanda bajo Sv39 y agrega telemetria de rendimiento ciclo a ciclo. Todo eso figura en un repositorio con un solo autor: unas 7 estrellas y 0 forks al 14 de noviembre de 2026 (FURSOY/fursoy-cpu).

Varios proyectos academicos ya logran arrancar Linux en hardware propio. Lo que distingue a Fursoy Slice-1 es que lo hace con una microarquitectura fuera de orden y superescalar, las dos tecnicas que separan un procesador simple de uno de alto rendimiento. Para entender por que eso es dificil hay que mirar como las implementa.

Ejecucion fuera de orden y superescalar: que significan en la practica

Un procesador en orden ejecuta cada instruccion cuando llega su turno, aunque tenga que esperar a que termine la anterior. Uno superescalar busca y decodifica varias instrucciones por ciclo en vez de una; Fursoy lo hace de a dos (fetch, decode y rename de 2 instrucciones por ciclo), segun su propia documentacion (FURSOY/fursoy-cpu).

Decodificar dos instrucciones no sirve de nada si la segunda tiene que esperar un dato que la primera todavia no calculo. Ahi entra la ejecucion fuera de orden, que deja avanzar instrucciones posteriores mientras una anterior sigue esperando, siempre que no dependan entre si, y que necesita tres piezas con tamanos concretos en este diseno: un reorder buffer (ROB) de 128 entradas (ROB_DEPTH = 128) que guarda el orden original y retira las instrucciones en ese orden aunque se hayan ejecutado en otro; un banco de 160 registros fisicos (PRF_SIZE = 160, con 128 entradas especulativas libres) que separa los nombres de registro que ve el programa de los registros reales; y 8 puntos de control (NUM_CHECKPOINTS = 8) que permiten deshacer en un ciclo el trabajo especulativo si una prediccion de salto falla (FURSOY/fursoy-cpu).

flowchart LR
  A["Fetch: 2 instrucciones"] --> B["Decode y rename"]
  B --> C["Issue queues: INT, MEM, FP, VEC"]
  C --> D["Ejecucion fuera de orden"]
  D --> E["ROB de 128 entradas: retiro en orden"]

Cada tipo de instruccion espera su turno en una cola de emision separada: 32 entradas para enteros, 32 para memoria, una cola propia para punto flotante (con 64 registros fisicos de FP) y una de 8 entradas para vectores de 256 bits. Esa separacion es lo que permite que una multiplicacion lenta no bloquee una suma simple que ya tiene sus operandos listos.

Por que el fuera de orden necesita memoria que no se bloquee

Dejar que las instrucciones se adelanten no sirve de mucho si cualquier acceso a memoria detiene todo el nucleo. La cache de instrucciones (fursoy_s1_l1i) tiene 16 KiB en 64 conjuntos de 4 vias con un prefetcher conservador y 2 Miss Status Holding Registers (MSHR), y la de datos (fursoy_s1_l1d) tiene el mismo tamano pero organizada en 8 bancos, con 16 entradas de cola de carga, 16 de cola de escritura y 4 MSHR, de forma que varios fallos de cache puedan quedar pendientes a la vez en lugar de atenderse uno por uno (FURSOY/fursoy-cpu).

La traduccion de direcciones sigue la misma logica: un TLB de datos de doble puerto con 64 entradas en 4 vias mas una CAM de 8 entradas para paginas de 2 MiB o 1 GiB, un TLB de instrucciones equivalente, y un walker de tablas de pagina en hardware que puede leer directamente una entrada sucia que todavia vive en la cache L1D sin forzar su expulsion. Alrededor del nucleo, el SoC conecta todo con un cruce de prioridad de 5 a 1, 256 MiB de DRAM, un CLINT, un PLIC con 31 fuentes externas, una UART 16550 y un firmware SBI minimo propio. Es, en los hechos, una computadora completa capaz de sostener un kernel Linux real, no un banco de pruebas aislado.

Lo que probamos: el laboratorio no encontro que compilar

Clonamos el repositorio en un sandbox aislado para ver si podiamos reproducir algo del proyecto. El resultado fue un fallo, y el fallo en si es el dato mas util de esta seccion: nuestro laboratorio no reconocio una pila de build soportada para correr el proyecto.

En nuestra prueba sobre Linux 6.18.15 con git 2.39.5 corrimos el clon tal cual lo ejecuto el laboratorio:

git -c protocol.allow=never -c protocol.https.allow=always -c core.hooksPath=/dev/null clone --depth 1 --single-branch --no-tags -- https://github.com/FURSOY/fursoy-cpu /tmp/lab-runs/lab-9cg4gzej/w/repo
Cloning into '/tmp/lab-runs/lab-9cg4gzej/w/repo'...

Segun las mediciones de nuestro laboratorio, el clon tardo 0,906 segundos, peso 8,9 MB y uso un pico de 34,8 MB de memoria. Hasta ahi, nada fuera de lo comun. El siguiente paso automatico de nuestro laboratorio, el que intenta detectar como instalar o compilar un proyecto a partir de sus archivos, respondio «no supported stack detected». Tiene sentido: Fursoy no es un paquete de Python ni un binario de Node, es RTL en SystemVerilog pensado para simuladores de hardware (el propio proyecto usa Yosys y OpenSTA para su sintesis), y nuestras heuristicas de build estan pensadas para software convencional, no para flujos de EDA.

Fursoy frente a lo que ya existe para aprender el kernel de Linux

Buscar como aprender el funcionamiento de Linux en GitHub lleva casi siempre a tres proyectos consolidados: 0xAX/linux-insides, un libro en progreso sobre las entranas del kernel con unas 33.755 estrellas al 14 de noviembre de 2026; s-matyukevich/raspberry-pi-os, una guia para aprender desarrollo de sistemas operativos usando una Raspberry Pi, con unas 13.964 estrellas a la misma fecha; y sysprog21/lkmpg, la guia de programacion de modulos del kernel actualizada para 5.0+, con unas 8.646 estrellas (FURSOY/fursoy-cpu).

La diferencia no es de popularidad, es de nivel de abstraccion. Los tres proyectos explican el kernel asumiendo que el hardware debajo ya existe y funciona: muestran como Linux usa interrupciones, memoria virtual o modulos sobre una CPU real que nadie en el tutorial construyo. Fursoy hace lo opuesto: construye el hardware primero y deja que Linux lo descubra. La memoria virtual Sv39 que linux-insides explica desde el lado del kernel, en Fursoy existe del lado del silicio, con un TLB y un walker de tablas de pagina concretos, con su tamano y su latencia.

Proyecto	Que ensena	Nivel	Estrellas (14 nov 2026)
Fursoy Slice-1	Como se construye una CPU fuera de orden que soporta Linux	Hardware (RTL, SystemVerilog)	~7
linux-insides	Como funciona el kernel por dentro, capa por capa	Software (lectura de codigo C)	~33.755
raspberry-pi-os	Como escribir un OS minimo sobre hardware ARM existente	Software (bare metal sobre SoC ya hecho)	~13.964
lkmpg	Como escribir modulos de kernel	Software (API del kernel)	~8.646

Que significa esto para tu trabajo

Si programas backend o escribis codigo de alto rendimiento (bases de datos, motores de juego, pipelines numericos), lo que te sirve no es correr Fursoy, es su catalogo de parametros. Un ROB de 128 entradas significa que la CPU puede tener en vuelo hasta 128 instrucciones sin confirmar, pero si tu codigo tiene una cadena larga de dependencias (cada resultado depende del anterior) ese margen no te sirve de nada, porque la ejecucion fuera de orden necesita instrucciones independientes para adelantar, no solo espacio en el buffer. Es el mismo motivo por el que desenrollar un bucle o reordenar calculos independientes sigue dando mejoras medibles en codigo critico, incluso en CPUs mucho mas grandes que esta.

Si trabajas en verificacion de hardware, FPGA o estudias arquitectura de computadoras, Fursoy es un diseno completo y legible de punta a punta: podes revisar como resuelve el renaming de registros o la recuperacion ante una prediccion de salto fallida sin pagar la licencia de un simulador comercial ni pelear con millones de lineas de un proyecto industrial. Podes clonarlo, pero no esperes que un laboratorio automatico de instalacion, ni el nuestro, sepa que hacer con el. Vas a necesitar Verilator o un simulador de SystemVerilog instalado a mano.

Limitaciones y cuando no conviene mirarlo

Fursoy es un proyecto de sintesis evaluada por bloques, no un chip fabricado: el reporte de timing cierra 500 MHz en 8 bloques funcionales por separado (fursoy_s1_branch_unit, fursoy_s1_csr, fursoy_s1_dtlb, fursoy_s1_itlb, fursoy_s1_agu, fursoy_s1_ptw, fursoy_s1_decode y fursoy_s1_alu), no como nucleo integrado completo. El margen de timing de un bloque aislado suele encogerse cuando se integra con el resto, asi que 500 MHz como nucleo completo todavia no esta confirmado por ese mismo reporte.

Tampoco es un proyecto para quien busca correr Linux rapido en silicio real: la propia fuente reporta un IPC de 0,84838 y un desglose completo de los 89.861.075 ciclos simulados por categoria (ejecucion util, recuperacion de saltos, stalls de memoria, entre otras) (FURSOY/fursoy-cpu), pero esa cifra sale de una simulacion funcional en Verilator, no de una medicion sobre el reloj de 500 MHz que cierra el reporte de sintesis por bloques. Con 0 forks y un solo autor, no tiene todavia la revision de pares que si tienen nucleos RISC-V abiertos mas grandes. Si necesitas una CPU RISC-V para un producto real, esto no es eso. Si queres entender por que una CPU real tarda meses en disenarse, es un mapa a escala legible.

Preguntas frecuentes

¿Puedo correr Fursoy en una FPGA de verdad?

El repositorio documenta sintesis contra una libreria de celdas estandar de 45 nm (Nangate), no un flujo de FPGA. Portarlo requeriria adaptar las restricciones de sintesis a la familia de FPGA elegida, y no hay un paso documentado para eso en el proyecto.

¿Por que el lenguaje principal del repositorio es C++ si el procesador esta en SystemVerilog?

Es algo habitual en proyectos de hardware, donde el testbench suele ser mas grande que el diseno que prueba.

Referencias

• FURSOY/fursoy-cpu: repositorio y documentacion tecnica del procesador, estadisticas de GitHub y reporte de sintesis.
• 0xAX/linux-insides: libro de referencia sobre el funcionamiento interno del kernel de Linux.
• s-matyukevich/raspberry-pi-os: guia de desarrollo de sistemas operativos sobre Raspberry Pi.
• sysprog21/lkmpg: guia de programacion de modulos del kernel de Linux.
• Hacker News: hilo de Show HN donde la comunidad discutio el lanzamiento del proyecto.

Seguimos el tema en @programacion.

Imagen destacada: Foto de Vishnu Mohanan en Unsplash

Así preparamos cada artículo (fuentes, pruebas y criterio editorial): Cómo trabajamos.