Investigaciones previas sobre CHAMELEON96

Placas completas (con o sin programador incorporado): Terasic, Altera, "chinas", etc
zx81
Veroboard
Mensajes: 4
Registrado: 07 Sep 2020, 13:42

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por zx81 » 30 Sep 2020, 22:25

Para empezar, diré que nunca antes había tenido o programado una FPGA de ninguna clase, así que para mí esto es bastante complicado, siendo generosos.

En el manual tenemos descritos los 3 relojes que hay, basados el reloj principal, el de periféricos y el de la SDRAM. Mi falta de experiencia en estas lides me hace desconocer si eso es suficiente o no. Desde luego, todo sale del HPS que, según donde lo leas, y suponiendo que lo interpreto bien, es un método desaconsejado expresamente por ALtera para coger un reloj por los problemas de jitter. Algunos conocedores del código me han asegurado que ese mismo reloj también lo usan en el proyecto MiSTer para algún core. Si es lo que hay, habrá que apañarse.

Lo de usar QSYS (cuyo nombre actual es en realidad Platform Designer) me temo que es la solución, si no la más rápida, sí la más simple. Una vez generado el proyecto mínimo, que a mi me ha costado varios días de lucha encarnizada con el Quartus, el resto ya lo programas de una forma más "normal". Lo de tener que borrar la dichosa línea del archivo .qip es debido a que, al menos en mi proyecto mínimo, no he añadido el manejo de la DDR3, cosa que en un SoC con un ARM dual-core se espera que se tenga. Una vez que sigues el nada evidente o trivial proceso de añadir los pines, ya no hace falta borrar la línea nunca más.

En todo caso, el problema que he visto es que copiando los parámetros de la DDR3 del proyecto CV96 original en mi proyecto, no funciona. O no consigo hacerlo funcionar por la complejidad del proceso, que esa es la segunda parte de la historia. El SoC tiene una cantidad salvaje de partes configurables, PERO, siempre hay uno, únicamente se pueden configurar inmediatamente después de un "cold boot". Eso obliga a, partiendo del QSYS y con ayuda del SoC FPGA, a generar unos ficheros .h que deben usarse para recompilar el u-boot con soporte de spl y, si vas a usar Linux, generar el nuevo device-tree adaptado a tu proyecto. Hay muchas cosas que programando únicamente la parte de la FPGA no se consigue nada, porque falta la otra. Debo reiterar, una vez más, que el proceso completo es complejo y nada evidente. Un usuario de Telegram, Marcus Jordan, ha portado a un u-boot del 2017 los cambios necesarios para que soporte la Chameleon 96. Ojo, porque este proceso es inherente al funcionamiento del SoC, y sucede lo mismo en la MiSTer. Solo que esta última lleva ya varios años de desarrollo de ventaja. Que yo sepa, el framework de la MiSTer permite reprogramar los relojes sin usar QSYS. Pero tampoco me parece algo gravísimo tener que usarlo para iniciar el proyecto.

Me he tirado una semana peleando con un par de docenas que no conocía ni entendía bien, y al final he podido manejar vía LOANIO los 4 LEDs de usuario que están colgando del HPS, generando el u-boot correspondiente de por medio. Afortunadamente, el manual es bastante completo, pero eso no quita la dificultad de manejo de un SoC tan bestia como es éste.

Efectivamente, del TDA no hay nada de nada. Pero sí existe lo justo como para inicializar un modo de 720p o de 1080p. A mi me preocupa más lo de después, tener bien preparada la conexión entre la FPGA y el TDA para enviarle los datos que hay que mostrar a partir de un framebuffer en la memoria DDR3. Pero bueno, la MiSTer lo hace, de modo que imposible no es. Por el medio hay que intentar no reinventar la rueda y aprender a manejar el interfaz I²C2 que está conectado al TDA para configurarlo, pero no como si fueran líneas GPIOs, sino usando la funcionalidad del interfaz I²C de verdad. Yo tengop muy claro cómo usar esos interfaces desde Linux (de hecho, el TDA lo inicializa u-boot, no Linux) a base de mapped-IO, pero ni idea aún de cómo usarlos desde Verilog.

Si empezar con un HDL es duro, empezar con éste SoC es tremendo y la implementación en la C96 no facilita las cosas, pero en Telegram un usuario portó los BASIC de 6502, 6809 y Z80 en unos cuantos ratos, funcionando bien vía consola serie. Compré la placa para aprender y espero que aún me sirva para eso, aunque no todo sea miel sobre hojuelas. A fin de cuentas, como tú mismo dices, esto va de entretenerse aprendiendo a base de martillazos.

Solo he encendido 4 LEDs, pero he aprendido en esa semana más que si hubiera iluminado el árbol de navidad del Rockefeller Center.

Avatar de Usuario
jepalza
Spartan 3
Mensajes: 216
Registrado: 14 Ago 2018, 18:51

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por jepalza » 03 Oct 2020, 07:02

Los relojes, he llegado a la misma conclusión: "solo" hay tres, y en muchas ocasiones, es insuficiente. Por ejemplo, el HDMI usa el suyo propio de 100 al menos, el core otro, digamos que 25mhz, y luego, quizás otro para la memoria, 133mhz, otro para el audio, digamos 8....

He visto cores con 7 relojes!!! También es cierto que se pueden luego recrear en VHDL o Verilog, cogiendo uno mayor, y reduciendo a la mitad sus ciclos, con lo cual podemos conseguir 50 desde 100, o incluso valores decimales, como 33.333, pero ya no son lo mismo, no son "reales", sino "simulados".
Ademas, como ya he dicho, el QSYS no deja muchas opciones en cuanto a valores arbitrarios, solo deja valores aproximados, y eso, por ejemplo, si se necesitan exactos 27.8 para una salida VGA, es un problema.

La línea de la memoria a tener que borrar, cierto, se puede evitar usando memoria DDR3, pero hay muy pocos cores que la emplee. La DDR3 no es adecuada por sus tiempos y velocidad, para cores viejos. (por cierto, para borrar la línea, me he hecho un simple programa que lo hace, sin tener que ir contínuamente a hacerlo a mano)

Para recompilar el uboot y el preloader viewtopic.php?f=29&p=1485#p1484 (no sé si será el mejor método, pero a mi me funciona)

Es una placa para aprender, que por lo que ha costado, no duele. Produce dolor de cabeza tanta información y tanto tiempo a invertir, para encender un solo led. Llegado el momento, acabas dejando todo para el día siguiente, por que no da para mas ese día.

Los que la han comprado esperando cores bestiales en poco tiempo, tendrán que esperar un buen tiempo. Por ahora, para ellos, es dinero mal invertido, pero 32 euros puede estar en el cajón unos meses.

zx81
Veroboard
Mensajes: 4
Registrado: 07 Sep 2020, 13:42

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por zx81 » 03 Oct 2020, 13:07

Como soy un novato en estas lides, desconozco la problemática de solo tener 3 relojes (realmente, no tienes ninguno directo, todos vienen desde el HPS). Pensaba que se pueden usar PLLs o incluso divisores sencillos si las frecuencias cuadran. ¿Qué problema hay en usar PLLs?.

La verdad es que, teniendo HDMI, ni me planteo usar VGA, siempre que seamos capaces de programar el TDA y se consiga definir un framebuffer en la DDR3 desde donde enviar los datos al TDA. Pero eso es algo que ya hacen en MiSTer, de modo que imposible no es.

La DDR3 no es preciso que la uses, solo que la definas, le pases las señales a tu módulo TOP y el Fitter asigne los pines. Hecho eso, se acabó el problema.

Poner a funcionar el invento va a costar, sobre todo por la pequeña cantidad de personas implicadas capaces de desarrollar o portar cores. Y en cuanto un par de esos se cansen... kaput!.

Avatar de Usuario
jepalza
Spartan 3
Mensajes: 216
Registrado: 14 Ago 2018, 18:51

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por jepalza » 03 Oct 2020, 21:38

No se pueden usar relojes PLL (hasta donde sé, de esta placa) por que no hay reloj externo en un PIN de la FPGA, sino en uno del HPS. Se pueden desviar los pines HPS hacia la FPGA (tú mismo lo has probado), pero ¿desviar el reloj?, lo veo raro. Entiendo que la CPU necesita "su" reloj para funcionar al inicio (reset), y si "se lo quitan" ¿funciona?
No lo sé, pero la lógica dice que no es posible. Otra cosa sería poner un reloj de 50mhz en uno de los pines FPGA libres, que ese reloj sí sería controlable con PLL, como se hace en el UnAmiga. (pero repito, hablo desde el desconocimiento, solo con la lógica)

En la placa DE10-Nano del Mister, hay varios relojes, uno de ellos directo al HPS, por que "lo necesita". Los otros van a la FPGA (creo que tiene tres externos)

Por cierto, estoy tratando de entender como funcionan la FPGA SOC-ARM, con un "ligero" manual bajado de Intel, de "solo" 3500 páginas!!!!

A mi las dos cosas que me está echando atrás en esta placa, es el tema de los relojes, y los pocos pines FPGA directos. Eso hace que cualquier core de todos los que tengo hechos, fallen estrepitosamente, o no se puedan no compilar (falta de SDRAM, o de SRAM, o de salida VGA). No obtener resultados visibles (en pantalla) durante tantos días, agota. Cierto que por RS232, o con leds, tenemos algo, pero hasta no ver una imagen, aunque sea u nsimple ZX81, no estaré contento.

zx81
Veroboard
Mensajes: 4
Registrado: 07 Sep 2020, 13:42

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por zx81 » 04 Oct 2020, 11:38

Tengo hecho un ejemplo de Blink en el que meto el clock de 100 Mhz que viene del HPS a la entrada de un PLL y saco un reloj de 3.546910 Mhz (yo pido uno de 3.546900, así que no está mal) con el que hago parpadear los LEDs de WiFi y BT, uno al ritmo del clock del PLL y otro al ritmo del FLASH del Spectrum. El PLL permite sacar hasta 9 relojes, pero no he experimentado para saber si con 9 a frecuencias diferentes o 9 salidas de la misma frecuencia.

El reloj del SoC es de 25 Mhz y, ahora que ya tienes el manualito de Altera, en la página 69 hay una visión general del Main PLL y en la página 102 tienes descrita la configuración que permite dirigir la salida C5 del Main Clock PLL a la FPGA, cosa que en esta placa no es opcional porque no hay más. Hay otro registro, justo antes de ese, que permite configurar el multiplicador y divisor a usar para configurar la frecuencia de la salida C5. Como ves, no le quitas nada al HPS. La pega de todo esto es que, como ya has visto, no puedes cambiar nada de la configuración sin generar un nuevo bootloader con su SPL. Al final, habrá que hacer como en la MiSTer, decidir una configuración, generar un boot y no tocarlo de ahí en adelante.

Hacer funcionar un core de ZX81 es la única manera de darle honorabilidad a la placa. Antes que eso, solo es un ladrillo... :D

Avatar de Usuario
jepalza
Spartan 3
Mensajes: 216
Registrado: 14 Ago 2018, 18:51

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por jepalza » 10 Oct 2020, 21:36

He retomado la placa estos dos pasados días (hasta ahora la había "aparcado").
No cambia mi opinión respecto a lo complicada que es de manejar. Eso de tener que pasar por el QSYS para la mayoría de cosas, me desespera, sobre todo los relojes, aunque he aprendido a hacer relojes PLL desde HPS.
Pero ya voy controlando poco a poco. Por ahora, he conseguido la mas simple, colarle un ZX81 simple, con solo salida de vídeo compuesto, PS2 para el teclado, y lectura de cintas por EAR.
Tengo que pulirlo, por que fallan los sincronismos. Creo que es por el tema del voltaje de 1.8v (he probado con 3.3v, pero no se ve nada en pantalla). El PS2 se resiente, por que estoy usando 3.3v para alimentarlo, y las señales que le llegan a la FPGA son de casi el doble de lo que espera (de 3.3 a 1.8) y corro el riesgo de fundirla.
Trataré de mejorarlo mañana domingo, y si queda bien, subo los fuentes.

Imagen

He probado con VGA simple, de solo 12 colores (r2, g2, b2), y funciona, pero se ve incluso peor aun que con video compuesto, y supongo que es por lo mismo, por que empleo 1.8v para alimentar la VGA.

Avatar de Usuario
jepalza
Spartan 3
Mensajes: 216
Registrado: 14 Ago 2018, 18:51

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por jepalza » 11 Oct 2020, 09:32

Cosas que NO entiendo de esta placa (por mas pruebas que hago).

misterio uno:
Si cambias algo dentro del QSYS (Platform Designer), el QUARTUS te pide que recompiles el preloader, y te deja los fuentes preparados. Los compilas, y obtienes el binario correspondiente. Opcionalmente, segun he leído, puedes compilar el uboot.
Luego, se supone que los grabas en la SD. Hasta aqui todo correcto en teoría, pero no en la práctica. No he logrado NI UNA SOLA vez que funcione un preloader compilado por mi, en cambio, si dejo el preloader y uboot originales, el que viene con la placa, funciona todo lo que hago, pero siempre que use un reloj de 100mhz que llega desde HPS. No sé que ocurre, pero nada compilado por mi (me refiero a los fuentes en C, no en VHDL), ha funcionado hasta ahora.

misterio dos:
se supone que si cambias el voltaje de referencia de los pines externos a leer/escribir, estos deberían indicar ese voltaje. Pero no funciona. He probado a cambiar de 1.8v por defecto, a 3.3 (o incluso 2.5) , pero nada sirve, siempre salen 1.8v.
La prueba mas simple es sacar 3.3v para encender un led en uno de los 8 pines fpga, pero nunca salen 3.3, solo 1.8. Imagino que están "atados" internamente a 1.8. Por los esquemas, deduzco que así es, dado que en la hoja 8 de 17, se ve que el bloque 8A, donde van 6 de los 8 pines FPGA, se alimenta de 1.8v
Si esto es cierto, no se puede hacer nada, siempre están alimentados a 1.8, y no se pueden sacar 3.3 para alimentar "a gusto" la salida VGA o Video Compuesto, o el PS2. No veo puentes en la placa que permitan cambiar esos voltajes.

Esto no sería un problema, si pudiera controlar los USB y el HDMI, pero por ahora, no lo he conseguido.

Avatar de Usuario
jepalza
Spartan 3
Mensajes: 216
Registrado: 14 Ago 2018, 18:51

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por jepalza » 25 Oct 2020, 14:56

He logrado sacar HDMI, pero a medias. Sale sin sincronía. Ademas, pienso que el sistema que he preparado para enviar datos al I2C del TDA19988 no es correcto, y no llega a inicializar el chip correctamente.
Pero es una buena base para experimentar. A pesar del fallo de sincronía, se ve que hay salida de vídeo.
Dejo los fuentes, para que experimentéis los que entendéis, sobre todo, los que sabéis algo mas de vídeo que yo.
Copiar en la carpeta extraída, la del QSYS, vale cualquiera que entregue 100mhz desde HPS, como los originales, o los del ejemplo del led.

Para el ejemplo, estoy usando unos fuentes cogidos de la placa "zedboard" (xilinx) que lleva un HDMI con chip ADV7511, que se programa como el nuestro, el TDA, por I2C. En el "i2csender" se colocan los datos de inicialización.
Los fuentes originales, los he dejado en una carpeta llamada "zed_hdmi_720p" , por si se necesitan de referencia.

Dentro del fuente, he incluído el parpadeo de los LED naranja y azul, solo para comprobar que funciona, y que los relojes van adecuados, no tiene otro cometido.

A ver si entre todos, logramos hacer andar al menos el HDMI. Con este ejemplo, ya hay una base de arranque. (bueno, si es que sirve para algo, que lo mismo es una KK y no sirve)

Imagen
Última edición por jepalza el 27 Oct 2020, 05:12, editado 1 vez en total.

Avatar de Usuario
boogermann
Veroboard
Mensajes: 1
Registrado: 30 Sep 2020, 07:43

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por boogermann » 26 Oct 2020, 09:27

jepalza escribió:
25 Oct 2020, 14:56
He logrado sacar HDMI, pero a medias. Sale sin sincronía. Ademas, pienso que el sistema que he preparado para enviar datos al I2C del TDA19988 no es correcto, y no llega a inicializar el chip correctamente.
Esta es la secuencia que necesitas:

Código: Seleccionar todo

INITIALIZING HDMI
CEC  => 24'h37ff06
SWITCHING TO PAGE: 00
HDMI => 24'h73ff00
HDMI => 24'h73a002   // RESOLUTION - 02 is 720p@60hz
HDMI => 24'h73cb00
HDMI => 24'h73f000
INITIALIZING HDMI BRIDGE
ENABLING VIDEO PORTS
HDMI => 24'h7318ff
HDMI => 24'h7319ff
HDMI => 24'h731aff
ENABLING MUXING
HDMI => 24'h732045
HDMI => 24'h732123
HDMI => 24'h732201
estas son algunas de las resoluciones que ya he asignado

Código: Seleccionar todo

00 - Custom Resolution
02 - 720p@60
03 - 1080i@60
06 - 1080p@30
08 - 720p@50
09 - 1080i@50
0C - 1080p@25
0D - 1080p@24
0E - 576p@60
10 - 2880x480@41 
11 - 2880x576@34
11 - 2880x576@70
19 - 720x1201@70
23 - 1080i@60
26 - 1080p@60
Debes unirte al telegram o al canal de discord, si usas otro método de comunicación, avísame.
Tenemos el HDMI funcionando la semana pasada, ya tengo prácticamente todo lo que necesitamos mapeado para audio y video, trabajando a través de FPGA y HPS.
Envié una invitación a mi organización de github donde tengo el repositorio que aún es privado. Hay un proyecto base para las pruebas y un framework. Estoy moviendo todas las pruebas exitosas al framework para que sea la base de todos los proyectos nuevos.
Ya tengo Kernel 5.8, U-boot 2007 y buildroot también funcionando correctamente, con el hps_handoff adecuado y 3 relojes para usar, 2 de 50mhz y 1 de 66.66666666mhz.

Avatar de Usuario
jepalza
Spartan 3
Mensajes: 216
Registrado: 14 Ago 2018, 18:51

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por jepalza » 26 Oct 2020, 17:01

Ya he visto lo del "github"(me he unido esta mañana). Gracias.

Como ves , iba por mi cuenta. Es lo que tiene trabajar en solitario. Ahora ya sé lo que me fallaba, y es que, la direccion del I2c en el ejemplo que he usado, la tenía en "7A", y no "73", por eso no enviaba nada.
Lo del telegram, me quité hace un tiempo, pero volveré a conectarme, a ver si entre todos lo sacamos, aunque ya veo que entre uno y otro, ya avanza.

Responder

Volver a “Placas entrenadoras”