KCPSM6 PicoBlaze: ¡Soft cores al poder!
Publicado: 08 May 2018, 11:55
El core de M6809 que usa jt_gng ocupa ya más que toda la FPGA del ZX-UNO. Pensaba yo que por ser una CPU de 8 bits iba a caber fácilmente… Pues no. No cabe. La Spartan 6 que usa el ZX-UNO tiene 1430 slices (¿para cuando un upgrade?). Y el core de la CPU usa más o menos esa cantidad.
Esta CPU es un procesador potente de 8 bits: buenos modos de direccionamiento, un poquito de aritmética interna de 16 bits… En general se la ve usada a 4MHz en las placas de la época.
Xilinx tiene una CPU de 8 bits estilo RISC -KCPSM6, conocida como PicoBlaze-, que ocupa sólo 26 slices (sí, sólo 26 según la documentación) más un bloque de RAM que sirve para el código. Esta CPU según ellos llega a correr a 125MHz en la Spartan 6. Todas las instrucciones tardan lo mismo: 2 ciclos de reloj. O sea 62.5 MIPS máximo.
¿Ya sabéis por dónde voy? Pues eso. La idea es olvidarse de hacer las CPUs directamente en lógica y usar un PicoBlaze como núcleo de la CPU. El código de la PicoBlaze sería el equivalente al microcódigo de una CPU normal. Es decir, hacemos un emulador software de la CPU original que corre en la PicoBlaze y nos quitamos mucha, pero mucha, complicación de encima. Además de liberar mucho, pero mucho, sitio de la FPGA. Así le damos vida para algunos años más al ZX-UNO.
¿Qué cómo lo hacemos? Bueno, la PicoBlaze tiene 16 registros de 8 bits y puede acceder al mundo exterior a través de un puerto de 8 bits más 8 bits de dirección. Hace falta hacerle un poquito de lógica exterior de bridge para adaptar los puertos a los de la CPU original y a correr.
Por ejemplo. La instrucción LDA del 6809 carga 8 bits en el acumulador A. Esta instrucción tarda 2 ciclos de reloj en ejecutarse. A ver cuánto tardaría en correr emulada:
1. Decodificar el direccionamiento (~3 pasos)
2. Cargar el dato (~1 paso)
3. Actualizar los flags (~3 pasos)
Serían unos 7 pasos más quizá 2 o 3 más de descodificar la instrucción original. O sea unas 10 instrucciones (pasos) en la PicoBlaze, o 20 ciclos de reloj. Para que acabemos al menos en el mismo tiempo que la CPU original habría que correr la PicoBlaze a 20/2=10 veces más o sea 40MHz. Si se supone que la PicoBlaze va hasta 125MHz, estamos aun lejos del límite. Incluso si tardáramos 20 veces más (80MHz) aun estaríamos lejos. Como la PicoBlaze son muy poquitas slices se puede sintetizar bien todo juntito y no dará problemas de velocidad.
Para CPUs viejas de los 80, esta parece una alternativa muy eficiente en área y de mejor mantenimiento que la implementación hardware directa. Además para gente con experiencia software es una forma más sencilla para meterse en el mundo de las FPGA porque el grueso del trabajo es software: escribir un emulador de una CPU en ensamblador de otra.
El juego de instrucciones de la PicoBlaze es increíblemente escueto. No cuesta nada dominarla. No hay que calentarse la cabeza con sistemas operativos, multi hilo, ni nada. Se puede hacer correr la CPU original exactamente a la velocidad que toca sin interrupciones y precisa al ciclo de reloj. Sólo que por dentro hemos metido una CPU que va 10~20 veces más rápida y está dedicada solo a esto.
A ver quien se anima a empezar…
Esta CPU es un procesador potente de 8 bits: buenos modos de direccionamiento, un poquito de aritmética interna de 16 bits… En general se la ve usada a 4MHz en las placas de la época.
Xilinx tiene una CPU de 8 bits estilo RISC -KCPSM6, conocida como PicoBlaze-, que ocupa sólo 26 slices (sí, sólo 26 según la documentación) más un bloque de RAM que sirve para el código. Esta CPU según ellos llega a correr a 125MHz en la Spartan 6. Todas las instrucciones tardan lo mismo: 2 ciclos de reloj. O sea 62.5 MIPS máximo.
¿Ya sabéis por dónde voy? Pues eso. La idea es olvidarse de hacer las CPUs directamente en lógica y usar un PicoBlaze como núcleo de la CPU. El código de la PicoBlaze sería el equivalente al microcódigo de una CPU normal. Es decir, hacemos un emulador software de la CPU original que corre en la PicoBlaze y nos quitamos mucha, pero mucha, complicación de encima. Además de liberar mucho, pero mucho, sitio de la FPGA. Así le damos vida para algunos años más al ZX-UNO.
¿Qué cómo lo hacemos? Bueno, la PicoBlaze tiene 16 registros de 8 bits y puede acceder al mundo exterior a través de un puerto de 8 bits más 8 bits de dirección. Hace falta hacerle un poquito de lógica exterior de bridge para adaptar los puertos a los de la CPU original y a correr.
Por ejemplo. La instrucción LDA del 6809 carga 8 bits en el acumulador A. Esta instrucción tarda 2 ciclos de reloj en ejecutarse. A ver cuánto tardaría en correr emulada:
1. Decodificar el direccionamiento (~3 pasos)
2. Cargar el dato (~1 paso)
3. Actualizar los flags (~3 pasos)
Serían unos 7 pasos más quizá 2 o 3 más de descodificar la instrucción original. O sea unas 10 instrucciones (pasos) en la PicoBlaze, o 20 ciclos de reloj. Para que acabemos al menos en el mismo tiempo que la CPU original habría que correr la PicoBlaze a 20/2=10 veces más o sea 40MHz. Si se supone que la PicoBlaze va hasta 125MHz, estamos aun lejos del límite. Incluso si tardáramos 20 veces más (80MHz) aun estaríamos lejos. Como la PicoBlaze son muy poquitas slices se puede sintetizar bien todo juntito y no dará problemas de velocidad.
Para CPUs viejas de los 80, esta parece una alternativa muy eficiente en área y de mejor mantenimiento que la implementación hardware directa. Además para gente con experiencia software es una forma más sencilla para meterse en el mundo de las FPGA porque el grueso del trabajo es software: escribir un emulador de una CPU en ensamblador de otra.
El juego de instrucciones de la PicoBlaze es increíblemente escueto. No cuesta nada dominarla. No hay que calentarse la cabeza con sistemas operativos, multi hilo, ni nada. Se puede hacer correr la CPU original exactamente a la velocidad que toca sin interrupciones y precisa al ciclo de reloj. Sólo que por dentro hemos metido una CPU que va 10~20 veces más rápida y está dedicada solo a esto.
A ver quien se anima a empezar…