[Microprocesadores][Off-topic] Curiosidades del 4004

[Juanma Rico]

Intentando emular a Obijuan con el Simplez-F, estaba buscando la posibilidad de rediseñar un microprocesador pero esta vez uno real, que se haya estado usando a lo largo de la historia en circuitos... Me acordé del 4004 el primer microprocesador de Intel, es el más sencillo que he encontrado.

Buscando información (hay abundante) he dado con una copia de los planos originales.
La cuestión es que me ha llamado la atención, entre tan avanzada tecnología de la época, en 1976, descubrir un apellido hispano (Gutiérrez). Lo podéis ver en el cajetín de los planos. ¿Alguien sabe quién podría ser?

Aparte de la curiosidad del nombre, una de las páginas principales es la de Federico Faggin uno de los diseñadores del 4004, es esta, pero hay multitud de páginas dedicadas a este micro.

En openCores hay una implementación en Verilog y es curioso que apenas ocupa unas 1250 líneas de código en Verilog.
Si dispongo de algo de tiempo tengo intención de implementarlo en la IceZum Alhambra (espero que quepa) y ver qué puedo hacer con ello, si lo consigo os informo... si hay algún interesado más en el proyecto que avise y así unimos fuerzas.

Saludos.

[JJ Merelo]

Genial, Juanma. Adelante. Yo no tengo ni idea del tema, pero sí me interesará lo que hagas, a ver si se puede usar en docencia en el departamento.

--
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/753fa916-50b6-4da7-8ec6-d1cc02f69a03%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

JJ

[Juanma Rico]

Pues con el apoyo de JJ (gracias :D) hoy me he animado y me he descargado el código del 4004 del openCores, el código está en Verilog y lo mantiene Reece Pollack.
Tiene un blog donde está intentado diseñar el mismísimo 4004 simplemente con transistores, cometió el error de empezar el diseño con Eagle y el cambio de políticas del software freeware de Eagle lo tiene un poco parado hasta que se pueda pasar a KiCAD (nada como el software libre para evitar sorpresas futuras...).

Un vistazo al datasheet del dispositivo 4004 ya te alucina (el datasheet es de Marzo del 87) y su simplicidad te atrapa. La cuestión es que no he podido esperar (soy impaciente por naturaleza) y sin echar ni una mirada al código, más que por encima, he intentado compilar con Apio. Pensando que me iba a dar errores por muchos sitios y así iba a calmar el SAV, me ha sorprendido que la síntesis no ha dado ni un solo fallo... al final únicamente he tenido que definir los pads del dispositivo (i4004.pcf) para que arachne no se quejara y al parecer, ha generado sin problemas el bitstream en formato ASCII (un simple apio verify y un apio build).

After placement:
PIOs       11 / 96
PLBs       9 / 160
BRAMs      0 / 16

place time 0.12s
route...
pass 1, 0 shared.

After routing:
span_4     10 / 6944
span_12    6 / 1440

route time 0.07s
write_txt hardware.asc...

Me he quedado con las ganas de descargarlo en la IceZum Alhambra pero me he tenido que contener.
Calmado el SAV inicial queda hacer alguna simulación y generar una ROM y una RAM para que se comunique con el 4004. Siendo tan simple y teniendo como tengo tantas EPROM y tantos circuitos RAM de memoria estática en el taller, me estoy planteando el soldarlas sobre una shield de prototipos del arduino y dejarlos en una placa externa a la FPGA. Lo investigaremos, de momento queda crear el test bench para las simulaciones.


Saludos, seguiremos informando. :)

[Juan Gonzalez Gomez]

Bravo Juanma! Es un proyectazo!!

--
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/ee47768b-5e2e-4112-aac3-363fb8b8784e%40googlegroups.com.

[Cristóbal Contreras Rubio]

Espectacular Juanma ;-)

El 13 de febrero de 2017, 21:32, Juan Gonzalez Gomez <obijua...@gmail.com> escribió:

Bravo Juanma! Es un proyectazo!!

El 13/2/2017 9:13 p. m., "Juanma Rico" <juan...@gmail.com> escribió:

Pues con el apoyo de JJ (gracias :D) hoy me he animado y me he descargado el código del 4004 del openCores, el código está en Verilog y lo mantiene Reece Pollack.
Tiene un blog donde está intentado diseñar el mismísimo 4004 simplemente con transistores, cometió el error de empezar el diseño con Eagle y el cambio de políticas del software freeware de Eagle lo tiene un poco parado hasta que se pueda pasar a KiCAD (nada como el software libre para evitar sorpresas futuras...).

Un vistazo al datasheet del dispositivo 4004 ya te alucina (el datasheet es de Marzo del 87) y su simplicidad te atrapa. La cuestión es que no he podido esperar (soy impaciente por naturaleza) y sin echar ni una mirada al código, más que por encima, he intentado compilar con Apio. Pensando que me iba a dar errores por muchos sitios y así iba a calmar el SAV, me ha sorprendido que la síntesis no ha dado ni un solo fallo... al final únicamente he tenido que definir los pads del dispositivo (i4004.pcf) para que arachne no se quejara y al parecer, ha generado sin problemas el bitstream en formato ASCII (un simple apio verify y un apio build).

After placement:
PIOs       11 / 96
PLBs       9 / 160
BRAMs      0 / 16

place time 0.12s
route...
pass 1, 0 shared.

After routing:
span_4     10 / 6944
span_12    6 / 1440

route time 0.07s
write_txt hardware.asc...

Me he quedado con las ganas de descargarlo en la IceZum Alhambra pero me he tenido que contener.
Calmado el SAV inicial queda hacer alguna simulación y generar una ROM y una RAM para que se comunique con el 4004. Siendo tan simple y teniendo como tengo tantas EPROM y tantos circuitos RAM de memoria estática en el taller, me estoy planteando el soldarlas sobre una shield de prototipos del arduino y dejarlos en una placa externa a la FPGA. Lo investigaremos, de momento queda crear el test bench para las simulaciones.


Saludos, seguiremos informando. :)

--
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-lib...@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/ee47768b-5e2e-4112-aac3-363fb8b8784e%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
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/CABqu7xqK6LCmXtQCkv5mpUzwWGYyn1kfX0nJbNo0%2Bj5htPa5mw%40mail.gmail.com.

[JJ Merelo]

Hola,

El 13 de febrero de 2017, 21:13, Juanma Rico <juan...@gmail.com> escribió:

Pues con el apoyo de JJ (gracias :D) hoy me he animado y me he descargado el código del 4004 del openCores, el código está en Verilog y lo mantiene Reece Pollack.
Tiene un blog donde está intentado diseñar el mismísimo 4004 simplemente con transistores, cometió el error de empezar el diseño con Eagle y el cambio de políticas del software freeware de Eagle lo tiene un poco parado hasta que se pueda pasar a KiCAD (nada como el software libre para evitar sorpresas futuras...).

Dentro de muy poco se podrá importar Eagle desde KiCAD. Como dice la frase, "Están trabajando en ellou" (en Granada)Me he quedado con las ganas de descargarlo en la IceZum Alhambra pero me he tenido que contener.

Calmado el SAV inicial queda hacer alguna simulación y generar una ROM y una RAM para que se comunique con el 4004. Siendo tan simple y teniendo como tengo tantas EPROM y tantos circuitos RAM de memoria estática en el taller, me estoy planteando el soldarlas sobre una shield de prototipos del arduino y dejarlos en una placa externa a la FPGA. Lo investigaremos, de momento queda crear el test bench para las simulaciones.


Saludos, seguiremos informando. :)

Estupendo. Un excelente trabajo...

--

JJ

[Juanma Rico]

Hoy solo me ha dado tiempo a acoplar un testbench casi sin señales y vacío al 4004 de Reece Pollack, pero al menos se tienen a la vista las señales internas del 4004 en el gtkwave.
Habrá que tomar el manual de uso y generar las señales apropiadas para que el 4004 reaccione intentando leer la siguiente instrucción de la RAM.



Saludos

[Juanma Rico]

Bueno, un pequeño pasito para el 4004 en Verilog. :)

Hoy he podido enviar desde el testbench las señales correctas de reloj y bien sincronizadas (son 3 distintas) para que me responda el 4004 con cierta lógica.
Aún tengo que aprender del GtkWave como ampliar las señales "a lo alto", pero si os fijáis en el bus data de la imagen adjunta se ve como el contador de programa del 4004 hace pedir instrucciones a los chips externos de la ROM poniendo la dirección (12bits)  en el bus de datos (lo envía en tres nibbles, 4 bits).

El ciclo de instrucción del 4004 ocupa 8 ciclos de reloj (del 0 al 7 en la imagen):

• En los tres primeros (a1, a2 y a3) el 4004 pone en el bus la dirección del banco de ROMs, en los dos siguientes (m1 y m2) toma la instrucción de la ROM y en las tres últimas la ejecuta (x1, x2, x3), en este caso el bus no se usa.

Lo que se observa en la imagen es que el 4004 está cambiando la dirección de petición {a3,a2,a1} (se ve el 1, 2, 3 del primer nibble...) y los dos nibbles siguientes aparece la instrucción que yo pongo en el bus después de la petición (de momento usando un simple case en el testbench). Tal que así:

  always @(negedge clk2)
  begin
        case (a1)
           0 : begin m1 = 4'b0000; m2 = 4'b0000; end   //0x00 NOP
           1 : begin m1 = 4'b1101; m2 = 4'b0001; end   //0xD1 LDM 01 (Carga 1 al acumulador)
           2 : begin m1 = 4'b1000; m2 = 4'b0001; end   //0x81 ADD 01 (Añadir el contenido del registro 1 al acumulador).
           3 : begin m1 = 4'b0011; m2 = 4'b0011; end
           default : begin m1 = 4'b1101; m2 = 4'b1010; end
        endcase
  end

Apenas un par de instrucciones para probar un pequeño programa. Os dejo el resultado de la simulación en la imagen adjunta.



Por hacer quedan varias cosas... lo primero es generar una entidad que simule la ROM (4001) porque el sistema mínimo MCS-4 (así se conoce al conjunto) necesita de ella. Esto permitirá probar un pequeño programa e incluso descargarlo ya en la IceZum Alhambra y empezar a ver lucecitas para encender y apagar. :)

Para ello quiero usa la técnica que usó Obijuan en el Simplez-F: generar un fichero que se pueda modificar en el momento de la síntesis (lo de pasarlo por el puerto serie ya tengo que pensármelo).

Y segundo... como veo que me estoy animando con esto de descubrir la tecnología de hace 40 años y el ingenio que había detrás... incluiré todos los cambios que vaya haciendo en algún proyecto github y así poder compartir más facilmente los progresos,... así también dejo libre los mensajes del grupo para no machacar diariamente con los mismo... :)

¡Un saludo a todos!

[Juanma Rico]

Buenas, ya he creado un proyecto en github y una wiki para el conjunto mcs-4 (incluido el microprocesador 4004). Lo podéis encontrar aquí:

https://github.com/juanmard/msc-4

Aún no hay mucho documentado, pero el código básico y el testbench del 4004 ya está subido. Hoy he estado trabajando en el 4001 (ROM) y el 4003 (Registro de desplazamiento), pero están muy verdes y aún no me he animado a subirlos. Posiblemente si mejoro mis conocimientos en github cree una rama de desarrollo para los que tengan mucho SAV y les guste la aventura... :)

Saludos.

[Juanma Rico]

Hola chicos,

Me he dado cuenta que el programa de yosys al sintetizar el código del 4004 de Reece Pollack da un warning en las puertas triestado.

He estado leyendo pero no me queda claro si está ya o no solucionado o si se ha avanzado en ello.

La cuestión es que el tutorial de Obijuan (https://github.com/Obijuan/open-fpga-verilog-tutorial/wiki/Cap%C3%ADtulo-29%3A-Puertas-triestado) es del 2015 y he visto mensajes del grupo de 2016 donde hay en Icestudio bloques que hacen esta función, pero no sé a qué nivel trabajan.

¿alguien podría decirme si ha usado esta característica directamente desde código Verilog y si lo ha probado recientemente en alguna FPGA libre?

Gracias, saludos.

[Salvador Eduardo Tropea]

Hola Juanma:

Yo hice el bloque para el icestudio.
El soporte en Yosys es prácticamente nulo (lo suficiente como para que
no de error, pero nada usable)
La solución es instanciar los pines de I/O con la primitiva de Silicon
Blue (SB_IO). Eso es lo que hace el bloque.

Saludos, Salvador

El 17/02/17 a las 04:23, Juanma Rico escribió:

--
Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/
INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/
Unidad Técnica Sistemas Inteligentes Av. General Paz 5445
Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA
FAX: (+54 11) 4754 5194 Buenos Aires * Argentina

[Juanma Rico]

Gracias por responder Salvador, buscaré información sobre instanciar los pines con SB_IO.
Está claro que de momento es la única solución y me gustaría en un futuro poder sintetizar algo que funcionara en la Icezum Alhambra.
:-)

[Juanma Rico]

Buenas a todos,

He actualizado el proyecto en github, he creado la ROM (i4001) y el registro de desplazamiento (i4003). Sigo intentando que la ROM imponga en el bus "data" del chip i4004 sus nibbles de código, pero no lo consigo.

Como se ve en la captura, el chip 4004, al pasar a nivel bajo la señal "poc" (reset de nivel) responde correctamente y saca al bus la dirección de la ROM de la que empieza a pedir datos (ciclos de nibbles 0, 1 y 2), pero la ROM no puede imponer los valores (el código que debe ejecutar el 4004 en los otros dos ciclos siguientes) que guarda en el bus (que se supone el 4004 deja en modo lectura) y se queda en el ciclo de nibble 3 sin poder cambiar... mientras, el 4004 sigue pidiendo las sucesivas direcciones de memoria al completar el ciclo, sin importarle nada de las señales de la ROM.

Total, que parece no funcionar... y como parece que "yosys" tiene problemas al poner en alta impedancia los pines de entrada/salida...

¿Alguien sabe si esto también afecta a iverilog en la simulación aunque sean señales internas? ¿Se puede solucionar esto definiendo cada uno de los pines internos como SB_IO (o estoy más perdido de lo que yo me imagino)?

Una pena quedar atascado en estas cosas y no poder avanzar... :(

Saludos

[Juan Gonzalez Gomez]

Hola Juanma,

El iverilog es independiente de yosys. Es decir, a nivel de código verilog primero debería simular correctamente, y luego, probar con la síntesis. Si no simula correctamente es porque hay algún problema en el código que hay que encontrar. La x indica que hay un corto: dos señales enviando al bus valores diferentes.  La depuración de esas cosas da guerra, y son difíciles de encontrar, pero con un poco de paciencia se acaban encontrando. ¡Animo!

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/b0d71670-fd88-4152-a4cb-e237d14dd170%40googlegroups.com.