Re: Compilación de correos para fpga-wars-explorando-el-lado-libre@googlegroups.com - 3 publicaciones en 2 temas

7 views
Skip to first unread message

Tim Rudy

unread,
Dec 18, 2025, 10:24:32 PM (11 hours ago) Dec 18
to fpga-wars-explora...@googlegroups.com
Interesting, Charli:

> a new module that will act as an inout proxy

This is probably the same as the vision I had to enable inouts! With Yosys and real FPGAs, inout ports are only allowed at the top level of a design so they map to real FPGA ports. Inserting any gates like a multiplexer pushes the inout port downward so it is "internal" to a design. This (*I mean, the fact that it breaks!) was not what I wanted: I was creating "tri-state" 74xx chips. These are supposed to be wired up in modules - Verilog modules - for full generality. For that purpose the inout ports of my devices and their tri-state buses would cross module boundaries. They need to work "internally".

Well, the inout port is an abstraction, and it's perfectly, fully available in Icestudio already - and supported by Yosys.

One way to get that to work was I observed that you created the Plug-in system for Icestudio... I would create an Icestudio layer, a Plug-in, which would basically take the modules living within a main.v file and "tweak" them (rewrite main.v). It would take responsibility for Icestudio acting like inout is supported, on the interface of any Verilog module. It would probably rewrite the ports as multiplexers. That is the general way to run buses these days: convert the tri-state buses to mutually-exclusive-access buses.

Finally any tri-state bus that exists at the top level of a design - say, 74xx buffers or other registers or devices that have tri-state outputs - 8, 16 or 32 lines, whatever is available for a given FPGA - would be left as it is: synthesized by Yosys as a real-world tri-state bus on the FPGA. Then the FPGA can interact with other inout/tri-state hardware as expected, if the designer is really interested in that.

Similar to your vision?

  - Tim

On Thu, Dec 18, 2025 at 7:02 PM <fpga-wars-explora...@googlegroups.com> wrote:
charli va <char...@gmail.com>: Dec 18 09:58PM +0100

* ENGLISH BELOW *
 
Buenas a todos! os comento avances, he aparcado mis módulos psram porque
creo que es muy interesante dar juego al micro ordenador de Jesús, podemos
aprender mucho con el.
 
Me he puesto manos a la obra y he corregido el módulo PSRAM de Jesús, he
encontrado varios errores de timing y protocolo, ahora ya funciona en quad
con total estabilidad siempre y cuando la tarjeta SD no esté conectada
(ahora os cuento esta aventura).
 
También he estabilizado el módulo de la sd y la interacción con la psram y
system, el resultado es que ahora me funcionan todas mis tarjetas sd, he
probado con 6, 2 de ellas recién compradas para las pruebas (además baratas
del chino de esas que dices... falla seguro... pues no, las lee
estupendamente, incluidas las que inicialmente no leía).
 
Lo que no he conseguido es poder usar a la vez la tarjeta SD y la PSRAM,
pero de igual forma he aprendido muchísimo esta semana y ha sido un viaje
interesante, de echo tengo idea de documentarlo y pasároslo porque hay
pruebas de osciloscopio muy chulas.
 
El tema es que básicamente tenemos dos problemas y lo cuento por si pueden
surgir ideas para futuras revisiones de la tarjeta.
 
1) *Problema hardware,* con las resistencias que tenemos por medio la señal
llega muy deformada y a 25MHz vamos al límite de que la psram funcione
"estable". si no hay sd, la señal tira, de echo en mis módulos solo con la
psram, a 100Mhz con cdc funciona perfecto. Pero al meter la SD sube la
impedancia de la linea y ya con eso muerte súbica, la psram en cuanto
realiza operaciones con ciclos largos de datos llegan muchos corruptos. En
el código que s paso con la sd insertada llega a leer bien el tamaño de la
psram pero luego la validación no es válida.
 
En esto he probado cosas como cambiar la resistencia de la línea
compartida, he reforzado el pull-up cambiándola por 2k y luego por 1k,
aunque no ha funcionado , en tests de escrituras largas se ha vuelto super
estable, de echo ahora tengo la placa tuneada con la resistencia de 1k
espero que esto os funcione igual de estble que a mi, voy a ver si me monto
otra con 10k y asípuedo hacer comparaciones.
 
2) *Y por otro lado tenemos otro problema y es que el diseño no supera los
25Mhz*, si en el pnr en el Makefile cambiamos la frecuencia objetivo de 8
por 25 no consigue nuncca sintetizar el circuito (al menos mi versión con
fixes, la original ahora mismo escribiendo esto me he dado cuenta que no la
he probado). Esto es debido posiblemente a que en el módulo psram la lógica
combinacional genera un camino muy largo y el npr no es capaz de garantizar
la temporización, porque por casualidad estamos al límite de uno de los
rangos especificados en el manual del propio chip pra 25Mhz, así que claro
si estamos justo en el límite para que la psram funcione y nuestro circuito
no garantiza siempre esa velocidad mínima, con la sd insertada ya la hemos
liado.
 
Tengo la teoría que bajando la velocidad del sistema podríamos funcionar
con la sd y la psram con el mismo código pero no lo he probado ya que la
vga es fundamental y la perderíamos, pero bueno para futuras pruebas ahí
queda eso.
 
De momento creo que el sistema es más que funcional e interesante pudiendo
usar sd ó PSRAM.
 
Espero que os valga este código de algo. Si alguien está interesado en que
desgranemos algo más etc decidlo.
 
Mis módulos PSRAM los he dejado aparcados de momento porque quiero
replantear la interfaz para no usar inout, he aprendido bastante en el
proceso y aunque funcionan muy bien si están solos, si queremos
interaccionar con la sd (o poder en el mismo sistema cambiar entre sd y
psram) yosys no es capaz de sintetizarlo correctamente aunque el verilog
sea correcto. En cuanto hago un mux con la sd yosys se pierde y rompe el
inout. He probado un montón de alternativas sin éxito aunque con todo lo
aprendido tengo en mente una refactorización y un nuevo módulo que hará de
proxy inout que creo será muy interesante y solucionará este problema, pero
esto más adelante ahora quiero avanzar cosas entorno a esta maquinita.
 
Un abrazo!
 
 
* ENGLISH. *
 
Hello everyone! I’d like to share some progress. I’ve put my PSRAM modules
on hold because I think it’s very interesting to give some attention to
Jesús’s microcomputer — we can learn a lot from it.
 
I got down to work and fixed Jesús’s PSRAM module. I found several timing
and protocol errors; now it works in quad mode with complete stability as
long as the SD card is not connected (I’ll explain this adventure in a
moment).
 
I’ve also stabilized the SD module and its interaction with the PSRAM and
the system. The result is that now all my SD cards work. I’ve tested six of
them, two of which were newly bought just for testing (cheap ones from a
Chinese shop that you’d normally think “this will definitely fail”… well,
they don’t — they work perfectly, including the ones that initially didn’t
work).
 
What I haven’t managed to do is use the SD card and the PSRAM at the same
time. Still, I’ve learned a huge amount this week and it’s been a very
interesting journey. In fact, I’m planning to document it and share it with
you, because there are some really cool oscilloscope captures.
 
The point is that we basically have two problems, and I’ll explain them in
case ideas come up for future board revisions.
 
1.
 
*Hardware problem.* With the resistors we currently have in place, the
signal arrives very distorted, and at 25 MHz we are right at the limit of
stable PSRAM operation. If there’s no SD card, the signal works fine. In
fact, on my modules with only PSRAM, it works perfectly at 100 MHz with
CDC. But when the SD card is added, the line impedance increases and that’s
basically instant death: as soon as the PSRAM performs operations with long
data cycles, a lot of corrupted data appears. In the code I’m sharing, with
the SD inserted it can correctly read the PSRAM size, but the validation
then fails.
 
I’ve tried things like changing the resistor on the shared line,
reinforcing the pull-up by changing it to 2 kΩ and then to 1 kΩ. Although
this didn’t fully solve it, long write tests became super stable. In fact,
I now have the board tuned with the 1 kΩ resistor; I hope this works just
as stably for you as it does for me. I’m planning to build another one with
10 kΩ so I can compare.
 
2.
 
*Another issue* is that the design doesn’t go beyond 25 MHz. If, in the
PNR in the Makefile, we change the target frequency from 8 to 25, it never
manages to synthesize the circuit (at least my version with fixes; while
writing this I realized I haven’t tested the original version). This is
possibly because, in the PSRAM module, the combinational logic creates a
very long path and the PNR tool is not able to guarantee timing.
Coincidentally, we are right at the limit of one of the ranges specified in
the chip’s own datasheet for 25 MHz. So, if we are already right at the
edge for the PSRAM to work and our circuit doesn’t always guarantee that
minimum speed, once the SD card is inserted everything falls apart.
 
My theory is that by lowering the system speed we could get SD and PSRAM
working together with the same code, but I haven’t tested it because VGA is
fundamental and we would lose it. Still, it’s something to keep in mind for
future tests.
 
For now, I think the system is more than functional and interesting, being
able to use either SD or PSRAM.
 
I hope this code is useful to you. If anyone is interested in digging
deeper into any part of this, just say so.
 
I’ve put my PSRAM modules on hold for now because I want to rethink the
interface to avoid using inout. I’ve learned quite a bit in the process,
and although they work very well on their own, if we want to interact with
the SD (or be able to switch between SD and PSRAM in the same system),
Yosys is not able to synthesize it correctly, even if the Verilog itself is
correct. As soon as I add a mux with the SD, Yosys gets confused and breaks
the inout. I’ve tried many alternatives without success, but with
everything I’ve learned I have in mind a refactor and a new module that
will act as an inout proxy, which I think will be very interesting and will
solve this problem. That will come later though — for now I want to move
forward with things around this little machine.
 
A hug!
Jesus Arias <ges...@gmail.com>: Dec 18 12:08PM -0800

Hola,
 
He portado la máquina de marcianitos "Defender" a la Alhambra-2 con la
placa multimedia. Para probarlo se necesita:
- Un teclado PS2 y el jumper correspondiente conectado en "PS2"
- Ninguna tarjeta SD insertada
- Un monitor VGA, a ser posible de aspecto 4:3
- Ampli de audio conectado al jack "AOUT"
 
Se programa la flash: "iceprog combi.bin"
 
y el videojuego arranca. El sistema ejecuta las ROM originales de
"Defender" y lo primero que hará será entrar en un menú de configuración.
Se resetea pulsando "F12" y al segundo intento arranca el juego. (esto se
debe a que una memoria supuestamente "no-volatil" ha comenzado con sus
datos incorrectos)
 
En el teclado estas son las teclas asociadas a los controles:
F3, F2, F1 : Son los interruptores para insertar "coins"
1, 2 : para arrancar una partida de uno o dos jugadores
Q : Nave arriba
A : Nave abajo
Alt: Encender motor
Shift Derecho: Girar marcha 180 grados
Control: Disparo
B : Bomba
H: Hyperespacio
 
Y para moverse por los menús de diagnóstico y depuración:
U: Auto up
I: Avance (al pulsarla la máquina entra en su "setup")
 
F12: Reinicio
 
Espero que gusten estos clones tan retro ;)
Saludos
[image: 20251218_002332.jpg]
charli va <char...@gmail.com>: Dec 18 09:56PM +0100

No tengo aquí un ps2!!! me voy a morir de ganas de probar esto hasta la
semana próxima!! :)
 
Gracias Jesús!!
 
Has recibido este resumen porque estás suscrito a las actualizaciones de este grupo. Puedes modificar la configuración en la página de pertenencia al grupo.
Para cancelar la suscripción a este grupo y dejar de recibir correos electrónicos, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages