[miSAV] Proyecto "Human Resource Machine" HRM-CPU

[Alexandre Dumont]

A la vez que descubri ese maravilloso mundo de las FPGA y del diseño de HW, los tutoriales del maestro Obijuan, tanto de IceStudio como Verilog, y la literatura correspondiente (+cursos de universidades, Google,...)... bueno, como decia, a la vez que descubri todo eso, mi hermano me presento un juego muy interesante llamado Human Resource Machine, o HRM.

En ese juego, el jugador programa un trabajador con un lenguage muy sencillo (en el primer nivel solo son 2 instrucciones). Poco a poco el juego de instrucciones disponibles se incrementa hasta 11. Tras jugar varios niveles, el iniciado reconocera rapidamente que el juego representa el funcionamiento interno de una CPU: 

Pongo aqui los elementos de la analogia (en mi opinion), pero os invito mejor a probar el juego (aunque sea de pago, pero vale la pena)!

HRM components	#	CPU components
Office Worker	1	Register
In/Out belts	2, 3	I/O
Floor Tiles	4	Memory (RAM)
Program	5	Program Memory
	6	Program Counter
	7	Instruction Register

Bueno pues claro, la mezcla fue explosiva (en mi cabeza) y me decidi a diseñar una CPU que funcione como ese juego (mejor dicho, que se comporte igual), con los mismo componentes, y el mismo lenguaje asemblador.

Por ahora,aun no lo tengo funcionando en FPGA, aun me queda, pero sí es la idea final.

Ahora lo estoy haciendo en 1º, Logisim, con el add-on de FSM, eso ya me esta funcionando para 7 instrucciones de las 11.

Mi diseño es una CPU 8bit multi-ciclo, con arquitectura Harvard (como en el juego), e instrucciones de longitud variable (1 o 2 palabras).

El modulo de FSM (un poco buggy) mola bastante, para ir probando y simulando:

De momento eso es lo que tengo creado:

Para cada modulo, lo diseño 1o en Logisim, lo simulo, luego lo diseño en Verilog y lo pruebo con su Testbench correspondiente, sus diagramas de RTL,...

Tambien he hecho un pequeño asemblado para convertir el codigo en lenguage maquina y poder cargarlo (de momento en Logisim, luego en BRAM,...)

Todo lo publico en Github, para que lo pueda consultar cualquiera (hay muchas mas informacion y diagramas de lo que pueda caber aqui). Tambien me abro Issues a mi mismo para registrar futuras ideas y evoluciones posibles:

https://github.com/adumont/hrm-cpu

Por ahora, esta es la ToC del README:

• Human Resource Machine CPU (Verilog)
• Introduction
  • Disclaimer
  • CPU Architecture components
• Instruction Set Architecture
  • Assembler
• Microarchitecture
  • Top module
  • Control Unit
  • Inbox
    • Logisim circuit
  • Outbox
    • Logisim circuit
  • Register
    • Logisim circuit
    • Circuit diagram
    • Testbench simulation
  • Memory
    • Logisim circuit
  • PC (Program Counter)
    • Logisim circuit
    • Circuit diagram
    • Testbench simulation
  • PROG (Program ROM)
    • Logisim circuit
    • Circuit diagram
    • Testbench simulation
  • IR (Instruction Register)
    • Logisim circuit
    • Circuit diagram
    • Testbench simulation
  • ALU
    • Logisim circuit
• Simulations in Logisim
  • Year 4
• Tools used in this project:

Ya tengo algunas mejoras en cabeza (https://github.com/adumont/hrm-cpu/issues ), para mas adelante (cambiar INBOX & OUTBOX por FIFOs y UART, o mejor incluso VGA,...).

Os invito a ver esta demo, del nivel 4  --> Simulations in Logisim , con explicacion, y videos del juego y de la simulacion en logisim de mi HRM-CPU.

Espero que le resulte interesante a alguien.

Se admiten comentarios.

Es con eso que paso el #SAV estos días ;)

Saludos,

Alex

[Jose Pico]

Increible Alexandre!

Va a quedar genial.

Me encantará seguir tu evolución.

Saludos y ánimo

[Juan Gonzalez Gomez]

Gracias Alexandre!  Es muy bueno!!

Me parece muy interesante que se muestre el funcionamiento de una cpu de forma sencilla, y que lo podamos replicar con FPGAs libres. Yo también trabajaré en esa dirección

¡Qué gran trabajo! ¡Muchas gracias! 😊

Saludos, Obijuan

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/f138de9d-919a-465e-b96b-b56e7df232c4%40googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[1138-4EB]

Muchas gracias por compartir el proyecto, Alexandre. Tiene un aspecto impresionante. ¡Felicidades!

En relación a las diferentes versiones de Logisim que parece has probado, ¿alguna permite sincronización bidireccional entre el código Verilog y los diagramas? ¿O tú editas todo en Logisim,, luego exportas a Verilog y si acaso lo modificas a mano, como en Icestudio?

El jueves, 19 de abril de 2018, 18:58:00 (UTC+2), Alexandre Dumont escribió:

[Alexandre Dumont]

Hola Unai,

No uso la generacion de codigo Verilog desde Logisim. Creo que existe esta posibilidad, mediante el modulo FPGA Commander en Logisim, pero creo que necesitas decir cual es la FPGA donde vas a sintetizar, y por ahora no soporta la Icezum o ninguna iCE40 (que yo haya visto). Eso es como todo, es Opensource, seria cuestion de ponerse y añadirla ;), pero al menos de momento no me puedo poner con eso. Imagino que se podria elegir otra FPGA, y coger el codigo que se genera, al menos podria  permitir tener una base de Verilog para retocar. En todo caso, no creo que sea bidireccional, sino que solo exportara a Verilog, no creo que permita crear un circuito en Logisim desde uno en Verilog.

El proceso que sigo yo es mas o menos el sigiuente:

O bien 1o en Logisim, luego lo simulo (en Logisim), y una vez vaya como quiero, me pongo a crearlo en Verilog (de cero, no exporto de logisim).

O, el segundo caso seria al reves, veo como hacerlo en Verilog, pero no se como hacerlo en Logisim (por ejemplo porque no se bien qué objeto usar en Logisim para hacer lo que quiero). En ese caso, lo que hago es 1o en Verilog, simulo para que me funcione como quiera, luego lo paso por netlistsvg para generar un diagrama RTL (con mi Makefile hago un make MODULE=modulename svg) y desde ahi intento reconstruirlo en Logisim. 

Es un proceso un poco artesanal, pero eso pasa porque las herramientas por ahora al menos, no permiten mas integracion, y/o exportacion/importacion. Y asi como hago las mismas cosas varias veces de maneras diferentes tengo la sensacion de que aprendo mucho mas :) jaja.

Me pasa un poco lo mismo con el FSM (finite state machine). Uso una version de Logisim con soporte basico para FSM (por cierto, se basa en una version de Logisim antigua, que ya no es compatible con la ultima version de logisim, una pena que no hayan hecho un fork/PullRequests para mantener su AddOn de FSM en el codigo official de Logisim...).

Ese addon de FSM para Logisim no permite siquiera exportar a Verilog (auque sí a VHDL, pero yo conozco VHDL). De todas maneras, lo mismo, cuando lo tenga bien probado en Logisim, lo recreare con otra herramienta que me parece mas potente (pero no integrada con Logisim), que permite generar Verilog en base a un diseño de FSM en una GUI (me refiero a Fizzim). Permite codificacion de estados one-hot por ejemplo. (Creo que es potente, el manual son un porron de paginas jajaja.)

(Sobre lo de usar Make, primero empeze con Verilog y make/Makefile, luego pase a apio, pero me parecia que perdia flexibilidad, porque cuando hay muchos modulos en una misma carpeta, con apio no puedes decirle cual coger, creoque coge *.v, y me petaba. con el Makefile controlo mejor cada caso, y puedo añadir cosas, como generacion del svg de diagrama RTL por ejemplo.)  

un saludo,

Alex

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/f8mjYT8JR5k/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.

Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/44550101-c738-4beb-8f90-32fec26bc351%40googlegroups.com.

[Alexandre Dumont]

Muchas gracias por el feedback. 

Por ahora el INBOX es un poco cutre, pero si , me gustaria cambiarlo por una FIFO y enchufarle antes un UART-RX (para poder enviar los datos, byte por byte, desde el puerto serie). Algo asi. Creo que en FSM de la CPU no tendre que cambiar nada (o poco), porque por ahora el INBOX ya reporta si esta vacia (señal empty a 1) y el FSM se basa en eso para esperar que llegen datos en el INBOX para seguir.

Mirare con mas calma lo que comentas sobre la FIFO, me parece muy interesante. De hecho, no dudes en pegar estas consideraciones en la Issue, asi ya lo tendre ahi reportado por tu usuario ;) (tambien puedo pegarlo yo mismo, pero al final el credito es tuyo).

Creo que el modulo de FSM en Logisim no codifica los estados en One-Hot sino en "binary" (00,01,10,11...). No obstante parece que es lo que hace en ese caso... raro. Sin embargo, en el FSM principal, tengo mogollon de estados (seguro que seria optimizable), pero no tengo tantos bits de estado. Tampoco me puse a mirar mucho y a la hora que era, igual me hice un lio ;) A lo mejor active una opcion de One-Hot sin quererlo en Logisim para el FSM de la INBOX y no el FSM de la CPU jaja). Lo mirare.

Cuando pase el FSM de la CPU a Fizzim, ya vere para generarlo en Verilog con OneHot Encoding :).

Muchas gracias,

Alex

On Fri, Apr 20, 2018 at 1:02 PM 1138-4EB <umarti...@ikasle.ehu.es> wrote:

Respondo de nuevo para comentar que los videojuegos referenciados en el articulo que se enlaza en el README merecen un vistazo: http://www.zachtronics.com/shenzhen-io/, http://www.zachtronics.com/tis-100/

Un par de comentarios sobre tu diseño:

- Por la descripción de INBOX (https://github.com/adumont/hrm-cpu#inbox) parece que lo que quieres es una FIFO. Si es así, gestionar "a mano" cuantos elementos hay en cada momento es ineficiente. Puedes usar el truco de generar dos punteros que tengan un bit más que los necesarios para representar la profundidad de la memoria. Por ejemplo, para una FIFO de cuatro posiciones, generas dos punteros de tres bits. Con ello, las señales de Empty y Full se calculan utilizando un comparador de igualdad y una puerta XOR. Ver ejemplo en VHDL: https://github.com/VUnit/vunit/blob/master/examples/vhdl/array_axis_vcs/src/fifo.vhd#L80-L82 He visto que las issues 1 y 5 están relacionadas. Pero, como indicas que escribes explícitamente el número de elementos de un bloque, supongo que utilizar FIFOs implica cambios en la lógica de control, y no solo en el datapath.
  - En este mismo sentido. Si lo que quieres con la FIFO es enviar diferentes secuencias de datos de longitud variable, pero necesitas saber cuándo ha terminado un bloque y cuándo empieza otro, te recomiento echar un vistazo a AXI Stream. El siguiente ejemplo muestra cómo convertir una FIFO en un maestro/esclavo AXI Stream.

- En el mismo apartado indicas que "The INBOX FSM is very simple. (for some reason, I was unable to create it in Logisim with 2-bit states encoding, that's probaby a bug. That's why it has 3 bit state encoding.)". Si te fijas, esto es debido a que se está utilizando codificación "one-hot" para la FSM. Como el nombre indica, esto requiere un bit por cada estado de la FSM (menos uno), de forma que en cualquier momento de la ejecución todos los bits están a cero excepto uno (salvo en standby, que no hay ninguno). Para "optimizarlo" y utilizar 2-bits tienes que mirar si es posible indicar a la herramienta que utilice codificación "binary" o "gray": https://en.wikipedia.org/wiki/One-hot

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/f8mjYT8JR5k/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/51d3da69-a579-49c1-a4d6-26e2d1ec849a%40googlegroups.com.

[Jordi Bardají]

Alexandre!!! Qué máquina!!! Gracias por el curro, es muy ilustrativo!!

Enhorabuena!!

Jordi

[Jesús Arroyo]

Qué pasada de proyecto y documentación!!

Muchas gracias por compartir!

El jueves, 19 de abril de 2018, 18:58:00 (UTC+2), Alexandre Dumont escribió:

[Alexandre Dumont]

Muchas gracias :D

He añadido un cuadro con el avance del proyecto. Estoy muy ilusionado con ello, a ver a donde me lleva :).

[Alexandre Dumont]

Algunas novedades de mi proyecto HRMCPU. En las ultimas semanas:

• he estado preparando el terreno para poder convertir Inbox & Outbox en FIFOs (que mas tarde quiero conectar a unas UART-RX/TX). El FSM se pausa (y espera para seguir) si INBOX esta vacia, idem si OUTBOX esta full.
  
• he cambiado el modulo de MEMORY, y añadido soporte para direccionamiento indirecto (que aparece mas adelante en el juego HRM)
• he añadido una funcionalidad de depuracion, que permite avanzar paso a paso (mas bien instruccion por instruccion), y se para despues de cada instruccion (hasta que se pulsa un boton), lo que permite inspeccionar cada registro, memoria, señal... justo despues de haber ejecutado una instruccion y antes de cargar la siguiente en el registro de instruccion. (es principalmente un cambio en el FSM).

El FSM queda así (diseñado por ahora en Logisim):

Tambien he añadido un test nuevo (incluye el correspondiente fichero de Logisim, con el diseño y las memorias pre-cargadas, menos la de salida):

This level is more complex. In level 32 there are 14 letters on the tiles, plus a 0. For each letters that comes into the Inbox, you have to compute how many tiles have the same letter, and send the total count to the Outbox.

This is how I did it in the real game:

Now let see how my HRM CPU behaves with the same program. First let's have a look at the program itself:

Here's my solution for Level 32. It involves direct (COPYFROM 14) and indirect adressing mode (COPYFROM [19]).

init:
    00: 20 0e ; COPYFROM 14
    02: 30 13 ; COPYTO 19
    04: 30 10 ; COPYTO 16
    06: 00 00 ; INBOX 
    07: 30 0f ; COPYTO 15
nexttile:
    09: 28 13 ; COPYFROM [19]
    0b: 90 19 ; JUMPZ outputcount
    0d: 50 0f ; SUB 15
    0f: 90 15 ; JUMPZ inccount
inctileaddr:
    11: 60 13 ; BUMP+ 19
    13: 80 09 ; JUMP nexttile
inccount:
    15: 60 10 ; BUMP+ 16
    17: 80 11 ; JUMP inctileaddr
outputcount:
    19: 20 10 ; COPYFROM 16
    1b: 10 00 ; OUTBOX 
    1c: 80 00 ; JUMP init

(This is the output of my Assembler)

The corresponding Logisim memory dump (machine languag, ready for loading into Logisim) is:

v2.0 raw
20 0e 30 13 30 10 00 30 0f 28 13 90 19 50 0f 90 15 60 13 80 09 60 10 80 11 20 10 10 80 00 

Below we can see it is loaded into the program memory (PROG) of the CPU:

Now let's see the Inbox:

We'll load 5 elements: 1, 2, 5, 3 and 4 into the INBOX. As we have to load first the number of elements, it is in total 6 items:

INBOX
0x05
0x01
0x02
0x05
0x03
0x04

In Logisim format that is:

v2.0 raw
05 01 02 05 03 04

We load the INBOX in Logisim:

In this level, we also have to pre-load the tiles in MEMORY. Here's the file:

v2.0 raw
02 01 04 02 03 04 01 02 01 04 03 02 01 02 00

Let's pause and count mentally how many of each item we have in the Tiles:

Item	Count
0x01	4
0x02	5
0x03	2
0x04	3
0x05	0

(That is what we expect to get in the OUTBOX)

Before running the program, let's clear the OUTBOX:

And finally we run the program:

The program will finish when the last item in the inbox is processed. Let's see the result we get in OUTBOX:

OUTBOX
0x05
0x04
0x00
0x02
0x03

Indeed, we can verify that this is the total count of each item (from the INBOX) in the tiles: 4 x 0x01, 5 x 0x02, 0 x 0x05, 2 x 0x03 and 3 x 0x04.

So it works!!!

¡Este soy yo ahora!

Ahora me queda terminar de pasar todo a Verilog, y que funcione en FPGA :)...

[Gabriel Marturano]

Excelente trabajo !

Si mas adelante tienes interés en trabajar en algún proyecto conjunto avisame, tengo cosas que te resultarán quizás interesantes.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.

Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/74876e5c-e052-4071-97ea-38d62f0acd0b%40googlegroups.com.