Designing a shield for Alambra

[Jesus Arias]

Hi,

I'm planing to build a board to provide the Alhambra2 with the convenience connectors for video and audio, mainly because my ratnest of wires disintegrates every time I touch it. This board will include:

- An AP-VGA video intergface.

- Stereo audio output with low-pass filters for either PWM or Sigma-Delta waveforms.

- Mono audio input with an analog sigma-delta modulator.

- PS2 keyboard / mouse connector with level shifters.

- An SD-card holder connected as SPI. (It uses the 4 analog pins of the Alhambra)

Let me attach some 3D views of the board:

And also the schematic.

This is still in a design phase, so, comments (and bug reports ;) are welcome. Mi idea is to order some bare PCBs from PCBWay and to build a prototype.

Good night

[charli va]

I want one of these! If I can help in any way, please let me know!

It looks so good, and it's going to save us so many headaches :)

A lot of thanks !!

--
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...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/9d73a81a-6b57-4517-ac8c-3883cde610c8n%40googlegroups.com.

[charli va]

Hi Jesús! I really love this project — it has great potential for implementing a bunch of different systems very easy.

I’m throwing out a few ideas that overlap with things I’m working on and that I think could fit in somehow — but as always, just disregard them if they don’t make sense.

On one hand, since you’re already including the PS/2 connector, maybe you could add a USB connector in parallel (so you could use either USB or PS/2), for example to connect a USB joystick. I published the joystick controller some time ago along with the USB mouse one — maybe it’s trying to squeeze too much in and doesn’t really make sense, but I’ll throw it out there in case you see any potential in it.

On the other hand, what I do see as more interesting would be adding a PSRAM. I’m using this model:
https://w.electrodragon.com/w/images/0/04/LY68L6400_0.3.pdf
I’ll share some blocks with you soon. The results seem excellent considering how inexpensive they are (I still need to test with other PSRAM chips that theoretically use the same protocol — I already have them but haven’t soldered them yet).

The idea would be to literally place it in parallel with the microSD, with the CS inverted, so we can select either the microSD or the PSRAM. It’s not a huge memory, but 64 Mbit is already enough for many things, and the read speed comfortably doubles that of the Alhambra’s flash, while the write speed is literally the same as the read speed (which would be a big improvement).

The only pity is not having two extra lines available to use it in QSPI mode, which makes a big difference (we’d get very interesting speeds from the memory there, but oh well — it is what it is). Although the I²C pins from the ADC are still free, with their pull-ups and the risk of the ADC recognizing a command by accident, contention would be guaranteed.

To make everything fit, what comes to mind is using vertical connectors for the microSD and for the USB (or only for the PSRAM, or only for the USB).

I used this one not long ago and the result was excellent — it’s easy to solder by hand and insertion and removal are super convenient:
https://www.digikey.es/es/products/detail/aces-connectors/MSDV-2108-BK33T/22208760?gad_source=1&gad_campaignid=20199916455&gbraid=0AAAAADrbLli-krHhKF9oRUCs5n11i2zR6&gclid=CjwKCAjw6vHHBhBwEiwAq4zvA5SFw1x14raSUUmMCzUaXamZVd8pWAU29zEOVTLHj6kSHs4aANStoxoCi7sQAvD_BwE&gclsrc=aw.ds

By placing it vertically, I think the PSRAM could fit perfectly in parallel within the same footprint where you currently have the microSD lying flat.

These are just a few simple ideas in case you find them interesting.

Good afternoon!

[charli va]

I made a mistake in combining the CS, I would have to use a high SPDT type switch, but I still think it would fit.

[Jesus Arias]

Hola Carlos,

I think I chose the wrong language for this tread ;) But anyway lets keep it... 

The components you mention are very interesting, but the big problem we're facing, apart from the small card size, is the reduced number of pins. So, some signals have to be shared / multiplexed. This has to be carefully studied. A hand-controlled switch for device selection is something I don't like very much...

The USB is another interface I had in mind, but we have to chose between Host or Device, and between fast or slow for the host case. We can share the PS2 pins (connect one or another, but not the two interfaces) And the 200ohm resistors in series with the pins can also degrade the signals (I don't think this is going to be a problem for slow USBs, for for full-speed ones I'm not so sure. Ideally these resistors should be around 22ohm, that added to about the same resistance in the FPGA pin results in 45ohm in series with D+/D-, or 90ohm for differential signals) An USB in Device mode can also require an extra pin for pull-up activation...

Good night

[Jesus Arias]

Hi again,

I carried out some simulations about the impedance mismatch in the USB cable. Let me present the results, first with a proper 45ohm series resistance and a 12 Mbit/s datastream through a 4 meter cable:

The green curve is the signal at the receiver side.

But now our resistance is 200ohm plus another 25ohm from the FPGA pin:

Here the RX signal is very degraded. So, this full-speed USB is hardly going to work.

But that was for a 4 meter cable. With shorter cables the degradation is going to be lower. Next simulation is for a 1 meter cable:

So, here the RX signal is still quite easy to decode and the USB is going to work at full-speed. We just have to avoid long cables. Of course, for low-speed USBs the cables can be up to 8 times longer, so they are no problem.

After this test I'm going to modify the board in order to include an USB connector with both the host and device possibilities. I think a vertical female type A conector is a good one because there are lots of adapter cables around.

I'm also going to squeeze the PSRAM into the board, and with a 4-bit interface. This will require more pins, so I think I'm going to remove one of the two output audio channels. And, of course, the SDA and SCL pins are going to be used as chip selects. Because only one of the two pins are going to be active (low) at a given time, there will be no unintentional commands sent to the Alhambra I2C converter. 

I'll post another schematic when more or less complete...

Nice day.

[charli va]

Thank you so much, Jesús, for this detailed analysis! If I can help you with anything, please let me know. I'm giving it some more thought to see if I can contribute anything.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/744457fb-252c-4dc8-b01b-06dee1e655c7n%40googlegroups.com.

[Jesus Arias]

Hi,

I'm attaching a revised schematic with the changes.

At the end I'm using two configuration jumpers: One for activating the PS2 level converter and another for USB termination (in device mode)

And some look at the vertical connectors and their possible placement (the 3D models are for different but similar parts, so they don't fit the footprints very well, yet, they can show more or less how the board will look)

Good night

[charli va]

It's going to be a super useful board! One thing I can't estimate with the 3D render: leave a few millimeters of space around the USB connectors so the plastic is thick around the male USB connector. Otherwise, in many cases, it will hit the microSD card (which will also stick out upwards).

Have a good start to the day!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/9731d7a3-2d87-4ef9-bb76-c32877f8206en%40googlegroups.com.

[Obijuan]

Hola Jesus!!

La placa tiene una pintaza increible! Muchísimas gracias por diseñarla... ¡Necesito una! :-)

Saludos, Obijuan

[charli va]

I'm sorry about the quality of the photo. I'm doing a proof of concept following the HAT schematic, and although I've had to improvise the microSD reader and the contacts fail from time to time, reading and writing are good (currently only at 6MHz).

As soon as I get a decent SD connector or can solder, I'll close the module and send it to you. Right now, it's very inefficient because it writes or reads byte by byte, requiring you to set up the rest of the block in a completely inefficient way. But I've already thought about how to invert a BRAM intermediate cache block. This could be very useful!

--
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...@googlegroups.com.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/5c85908a-abd4-4fe4-bb1f-5944a176517an%40googlegroups.com.

[Jesus Arias]

Hola de nuevo

Ya tengo la PCB completa

Adjunto también los PDFs con el esquemático y las dos caras del layout

Y también he subido los fuentes a Github. (El diseño está hecho con Proteus, de Labcenter Electronics)

https://github.com/jesari-git/Alhambra2media

Si alguien ve algún bug, inconveniente, etc.  please comment...

(por cierto, acabo de ver que tal vez las 6 resistencias de la VGA estarían mejor en la cara de debajo, con el resto de los SMDs)

Saludos

[charli va]

Jesus, that's a silly idea. I was thinking that for assembly, this type of connector might be useful instead of the normal pins. This way, it would be practical for debugging both the board and anything else you're doing, and it would make inserting probes much easier.

https://tienda.bricogeek.com/varios/780-conector-hembra-arduino-10-pines.html?srsltid=AfmBOorMqhdWYJbEYfGdtmiCHYxkY-JtDX8dE3F2rBSLVVB0i7cEHC7B

If the idea "worked," I think you'd have to move the PS2 a few mm to the right because I think it touches the pin footprint, and if you used this type of connector, it wouldn't fit. XD

Personally, I don't like the pinout as such, but at least for some debug boards, I think it could be interesting.

On the other hand, your design has been useful to me to test the VGA palette calculator that I prepared this summer for future things :) and I was delighted to see that everything matched up with your calculations. I have uploaded it so that whoever wants to play can do so. It helped me understand how the handful of resistors were translated into colors (in addition to being useful for being able to adjust custom color palettes at certain times).

And it will also generate a very rich and vivid color spectrum :)

If anyone wants to play or is designing a DAC for VGA, you can try it if it helps, I have in mind to include some other typical ladder-type scheme or similar and increase the number of bits, for now as it is a proof of concept it is with 2 which is what we are using in general:

https://icestudio.io/play/vga-dac-calc

Good night!

--
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...@googlegroups.com.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/556ab1ed-ad37-4db6-87f9-0d138c6204ebn%40googlegroups.com.

[Jesus Arias]

Hi Carlos

I moved a little the connectors in order to make room for the female pins. (notice the audio jacks are really close to each other, the 3D model is narrower than the real part)

And about your DAC calculator. Maybe you can also include this sort of R-2R DAC:

I'm using this DAC in my SIMRETRO board, and with 4-bit per color component we can achieve 4096 colors. The DAC has a maximum output amplitude of 1.4V and an output resistance of 75ohm, so, when connected to a monitor the final amplitude is 0.7V and the cable impedance is matched on both ends (I was a bit too paranoid about impedance matching at that time).

Good night

[charli va]

Hi Jesús! I'm doing some testing to get a head start on debugging the cards. I think if we set up a test bench, it could serve as usage examples and also as a test of the assembly.

With the microSD card, I'm testing with several cards and I've found that with most of them (I have 4 and it's happened with 3), the reading doesn't work unless I use an external pull-up resistor. If I use the FPGA's internal pull-up resistor, the MISO reading is always 0.

As I mentioned, one card works fine with the FPGA's internal pull-up resistor, and then two of them work fine with and without an external pull-up resistor.

Although the standard theoretically recommends a pull-up resistor, many cards supposedly work without one, but...

I mention this because if that's the case, the pull-up resistor would need to be connected to MISO. I'm not sure if it's specific to the card models I have, but I'm mentioning it just in case. I'll run more thorough tests this weekend and confirm it 100%.

This started happening when ramping up to high speeds, possibly because the internal pull-up resistor is degrading the signal too much or isn't able to sustain or raise the voltage quickly enough. Externally, with a 10k resistor, everything is working perfectly.

If this is confirmed, it might make sense to also add pull-up resistors to CS and MOSI to stabilize them at startup. I had to add a large counter at the start of the circuit because the fluctuating startup peak of the Alhambra caused the card to malfunction in many cases. Once I added a buffer time for the Alhambra to stabilize and the SD card to start up smoothly, everything worked perfectly. Perhaps adding a "crutch" to CS and MOSI would make it more robust against this initial noise.

Although it doesn't add much, I'll leave you with a screenshot of the analyzer showing the traffic between the FPGA and the SD card already flowing smoothly.

Good night!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/2cb83451-4e9d-40f8-8357-3cbbf979c1d8n%40googlegroups.com.

[Jesus Arias]

Hi Carlos,

That's weird since all SPI signals are of the push-pull type, MISO included. There are no open-drains here. But MISO is left in high impedance until the card has some data to send back to the FPGA, and a floating MISO pin can pick up noise and get randomly some valid tokem (the start of a data block is a single byte: 0xFE, an easy value to find among noise). Maybe this is the source of the problem. Anyway, a pullup won't hurt either, so I'll add it to the board. 

Good point! 

& Good night

[Jesus Arias]

Hi again,

The pullup resistor is included in the last revision of the board:

https://github.com/jesari-git/Alhambra2media

Also, I found another possible issue when using the USB in device mode. I tough the 5V switch in the Alhambra was a simple switch, but in fact it is a MOSFET, and it can keep conducting when it is supposed to be open if 5V are applied from the USB connector, so, I included a jumper in the board to disconnect the 5V entirely if the board is connected to a host with a double-male USB-A cable.

Nice day

[charli va]

Hi Jesús! I'm improving the DAC calculator with your model (as always, very interesting). I'll update you tomorrow; I still have a few details to add.

The first model is very simple to calculate, but after receiving your model, I thought it would be interesting to expand it to easily incorporate more possible models in the future, extend the tool, or make it usable for other things (it's clear that any simulation program like SPICE or KiCad itself can be used, but the idea is to have some visualization beyond just voltage calculations, for example, in this case, to see the color palette. For me, it's an interesting exercise that I think could be useful for other things in the future).

To get to the point, since I'm getting lost, as your model is more complex, I used a computational model (Kirchhoff's current law + solving systems of equations by Gaussian elimination) and I got 0.622V as the final output voltage after accounting for impedances, load resistance, etc. I don't know if I've overlooked some pre-existing resistance that you've included, or if that's the value we should use (or maybe I made a mistake in the calculation).

The palette looks good, but I wanted to know if you've calculated or measured the actual final value of the channel to see if I'm doing something wrong and to fine-tune the model.

Thanks!!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/998a5dc3-4cd7-4a65-a3ca-173449bf9b1bn%40googlegroups.com.

[Jesus Arias]

Hi,

The R-2R DAC has an output resistance of value R, that is 180ohm, and its maximum voltage is Vdd * 15/16 = 3.09V.

Now, connecting the 130ohm resistor in parallel with the output we get an output resistance of Req=180*130/(180+130) = 75,48ohm, and the max. voltage is Vmax= 3.09 * 130/(130+180) = 1.3V.

So, when matched to the monitor the voltage is going to be half that value, or 0.647V.

Of course, the 2R value isn't the exact 360ohm, but but about 330+25 = 355ohm, and therefore, the DAC isn't very linear (but for 4 bits it is enough). All resistors are rounded to the nearest available value.

I'm attaching a C program for the exact calculation.

Good night

[Jesus Arias]

Sorry, I did a mistake in the previous code (in the function  "genDAC()") I'm attaching it again

[charli va]

Thank you very much! Reviewing your simulator, it was very similar to what I had done, but I had the elephant in the room and couldn't see it: I had slipped in and entered R31 in series instead of parallel, which was the source of the biggest discrepancy.

I've simplified it to use only one value for the pin's resistance, as can be configured to approximate the resulting palette. I think that's enougth.

Now the calculations are closer to the actual theoretical value:

| Parameter | Obtained Value | Expected Value | Error |
|----------------|----------------------|----------------------|---------|
| V_max       |   0.656V            |.             0.647V |  1.4% |
| R_eq          | 176.5Ω             | ~180Ω               |     0    |

I'll post it in a new thread later so as not to clutter this one and to avoid going off on a tangent about our rhizomatic trends.

Have a good day!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/ddf4dcdd-1f5c-47b8-b70d-88b23e152aacn%40googlegroups.com.

[Jesus Arias]

Hola a todos

Gracias a la entusiasta colaboración de Charliva ya tenemos los primeros prototipos montados y las pruebas que hemos hecho han salido todas bien:

A la izquierda sobre fondo rojo las placas montadas por Carlos, con pines macho-hembra para facilitar la depuración. A la derecha la mía, con pines sólo macho, y enchufada a la Alhambra-II

Saludos

[Jo mo]

Congratulation Jesus  e Charli,

Beautiful and compact design !

You now have plenty of interfaces to play with! ;-)

i am impatient to see the future designs that you will load on your "expanded Alhambra boards"

Have a great week guys !

[Obijuan]

Enhorabuena! La placa tiene una pinta tremenda! Muchísimas gracias!

¿Cómo podría conseguir una? 😀

La placa es genial para temas educativos, sin duda

Saludos, Obijuan

[charli va]

Todo un placer Jesús!, que me hayas dejado participar en "la criatura"  ha sido toda una pasada y en lo que he podido aportar he disfrutado del camino y eso que acaba de empezar!

Va ser una tarjeta que nos va a dar muchísimas posibilidades, se vienen demo en las próximas semanas!!!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/71b54aa5-b17c-4fb7-a053-d5e68479b648n%40googlegroups.com.

[Democrito]

Quiero una!

[charli va]

In English below:

hola a todos!

Comunicaros que entre Jesús y yo, vamos a donar a algunas personas de la lista un prototipo de la shield de Jesús, las hemos producido a mano con mucho cariño con la idea de que esta experiencia sea super enriquecedora para todos y vivirla en comunidad. Espero que la experiencia sea muy buena y sea la primera de muchas más de este tipo :) 

No vamos a poder enviar placas a todas las personas que nos gustaría, cada placa lleva un importante esfuerzo personal y económico y algunas personas se nos quedan fuera de nuestras posibilidades ahora mismo.

Si hubiera interés general en la shield podéis contar conmigo para que organice una remesa a un precio justo para cubrir gastos mínimos, esto lo dejamos en el aire para los próximos meses.

Esta plaquita le va a dar superpoderes a la Alhambra , la va a convertir en una auténtica plataforma de aprendizaje para poder aprender a hacer cosas al más alto nivel, pudiendo trabajar con ella cómodamente desde verilog o Icestudio.

Os dejo un acceso para no sobrecargar el mensaje con fotos del montaje y algún vídeo de inspección de las soldaduras, en el primer prototipo he aprovechado a experimentar con algunos materiales nuevos y la placa es mejorable, pero lo dejo por si a alguno le es de interés:

https://drive.google.com/drive/folders/1axAZUAIw__CJzvaYTYQvh0KHISqWaLon?usp=sharing

English.               :

Hello everyone!

I wanted to let you know that Jesús and I are going to donate a prototype of Jesús’s shield to some people on the list. We’ve made them by hand with great care, hoping this will be a truly enriching experience for everyone and something we can enjoy together as a community. I hope it turns out to be a great experience and the first of many more like this :)

We won’t be able to send boards to everyone we would like to. Each board requires a significant personal and financial effort, and some people unfortunately fall outside of what we can manage right now.

If there is general interest in the shield, you can count on me to organize a production batch at a fair price to cover minimal costs. We’ll leave that possibility open for the coming months.

This little board is going to give the Alhambra superpowers—it will turn it into a true learning platform where you can work at the highest level, comfortably using Verilog or Icestudio.

I’m sharing a link so as not to overload this message with photos of the assembly and a video inspecting the soldering. In the first prototype I took the opportunity to experiment with some new materials, so the board can still be improved, but I’m leaving it here in case it’s of interest to anyone:

If there is general interest in the shield, you can count on me to organize a production batch at a fair price to cover minimal costs. We’ll leave that possibility open for the coming months.

This little board is going to give the Alhambra superpowers—it will turn it into a true learning platform where you can work at the highest level, comfortably using Verilog or Icestudio.

I’m sharing a link so as not to overload this message with photos of the assembly and a video inspecting the soldering. In the first prototype I took the opportunity to experiment with some new materials, so the board can still be improved, but I’m leaving it here in case it’s of interest to anyone:

https://drive.google.com/drive/folders/1axAZUAIw__CJzvaYTYQvh0KHISqWaLon?usp=sharing

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/4d051ef1-e4ea-4f08-bfc9-0936b5172b9cn%40googlegroups.com.

[Alexander Lang]

Hi, 

I would be happy to buy one of the shields for a fair price 😀.  I would cover the shipping too.

Kind regards

Alex

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCZVrgj9%3DiPqG%2BSiXFRH44wCLwYGR9W5TJDnfQzjqXoXcg%40mail.gmail.com.

[charli va]

🙌 We'll see how we can organize ourselves in the coming days, depending on who's interested. Thanks for your interest!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAAunToHcLN0U9HhvCcFWV5P3Q6fNDLNE55rQy55HR4sOcJFC8g%40mail.gmail.com.

[Jesus Arias]

Hi,

I uploaded  a design example for the board to Github:

https://github.com/jesari-git/Alhambra2media/blob/main/demo/larvaMM.tgz

It includes:

- VGA Video

- Sound output: sigma-delta DAC, and input: sigma-delta ADC

- SD card: FAT32 format, read-only

- PSRAM: 4-bit mode with mapping controller (a bit buggy, don't try to execute code from the PSRAM yet)

Not yet included:

- PS2 

- USB

Nice day!

[charli va]

Thanks Jesus!! I’m pulishing my psram modules , i’ll send you at the end of the day . This will be direct from the oven but i think is aparently stable .

Tell you later ,have a nice day!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3ca7944a-87b0-49ff-8490-8d9b00d26239n%40googlegroups.com.

[Jo mo]

Ola Jesus and Carlos,

Congratulations for this amazing work ( firmware and hardware code )!
That features.txt file is a pleasure to read.
I also had quick lock a the verilog code files and it looks compact and well documented/easy to read !

For sure i will copy-paste parts of that code for my own designs ;-)

Have a great weekend guys

[Democrito]

I just received my super Shield!

Thank you so much to Carlos and Jesús!

[charli va]

I'm sure you'll get a lot out of it ;)

Go for it!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/1fce9d84-a872-4113-95dc-813837e164cbn%40googlegroups.com.

[Eladio Delgado]

Hola!

Acabo de recibir la mía, muchas gracias Jesús y Carlos!

Muy interesante todo lo que tiene, sobre todo la parte de audio me encanta!

Un saludo,

Eladio

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCZ_bNopo0wv0kSbE25Q3%2B0TyAa2wV1EbFyUneoc7b6u%2Bg%40mail.gmail.com.

[charli va]

in ENGLISH bellow

A disfrutarla!!!! :) Se vienen bonitas demos en los próximos días!

Para los interesados no me he olvidado de nadie, no se va a quedar nadie atrás ;) os iré informando estos días que ando preparando todo!

ENGLISH:

Enjoy it!!!! :) Some great demos are coming in the next few days!

For those interested, I haven't forgotten anyone, no one will be left out ;) I'll keep you updated these next few days as I'm getting everything ready!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAJXdXgSECqkntAj%3DG4mZ9TnqUPtj-DUZq4SPnJ%3DXA5en011vmA%40mail.gmail.com.

[William DesLauriers]

I also want the board!  Will it work with the Alhambra II?  Can you provide a video of the Alhambra II and the shield working together?

Regards,

Wm

[Jesus Arias]

Hi,

I published a video here:

https://youtu.be/zo6V9OOELeM

Nice day

[charli va]

Wou!!!! so coool!!!! i like a lot the "demoscene effect" as a sound visualizer!!

Demos are comming!!!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3704ad0d-6d1d-4ca7-bcc3-69a9a0dfd9c6n%40googlegroups.com.

[Jo mo]

Congratulation Jesus,

This are beautiful results with the Alhambra board !

Have a good evening guys

[Democrito]

It's truly impressive what you can do with that small board!

[charli va]

Hi Jesús! I'm making progress with the Shield and wanted to try your demo. Although everything started up well, I've run into a few problems.

Firstly, I haven't been able to make adjustments and tests with the code yet because I'm working with the latest version of Yosys and it's giving me a lot of errors. I'm looking into creating a wrapper in IceStudio so more people can easily try it out, and that way I can also test things and make adjustments instead of just throwing the problem at you.

Of the three demos, I was only able to try 1 and 2 today. I'll try the one with the waveform generator on Friday.

The PSRAM trick didn't work for me; I've attached a screenshot. I've ruled out a problem with the motherboard because it works fine in my PSRAM Verilog modules. I imagine there might be some slight variation between chips, and the bitbanging software timing is causing it to malfunction. If I need to do anything special, let me know. I'm juggling several things and haven't wanted to bother looking at the PSRAM software code, but I'm mentioning it so you're aware.

On the other hand, the audio worked perfectly; I loved it. You're a real pro!I 've attached a test probe (I'm away from home and don't have a decent speaker here, sorry for the poor audio quality, but the sound is quite good, a little noise when the music approaches silence, but very decent)

https://youtu.be/wjPq7Fwm3PI 

Just so anyone else knows, I had to format the  sd card  to FAT16 to could work.

On another note, I wanted to ask if it would make more sense to start a new thread with each new demo we release, for example, beginning the subject line with:

[AlhambraMM] whatever

I say this because I think otherwise this thread will become endless and information will get lost (which would be a shame).

Thanks so much for everything, keep us up!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3704ad0d-6d1d-4ca7-bcc3-69a9a0dfd9c6n%40googlegroups.com.

[charli va]

I have fixed the problems for the new yosys and 

I’m trying to integrate  my psram module , if i’ll succes send you later.

This is only an appointment to advise you in no invest time to fix the code for yosys.

Good day!

[Jesus Arias]

Hum, the PSRAM size found was OK, and that means It is "almost" working. It could be a good idea to take a look to its contents using the debugger. (<ctrl>-C enters the debugger and "m 10000000" lists the start of the PSRAM. "w 10000000" also allows to write new data, byte by byte) 

I also had a lot of trouble with the psram controller, that in some cases also interfered with the SPI bus of the SD card. These parts of the code surely need a redesing. (I should port your PSRAM controller at least...)

On the other hand, I'm using the yosys version that is included in the Icestudio's (0.12 stable)  toolchain directly with no problems. (Some time ago yosys started having trouble finding the "top" module of designs, and that's the reason why now I'm using a lot of  "`include" lines in my codes)

And the FAT32 format in the SD card should be also supported...

Nice day

[Jesus Arias]

Hi again,

Carlos, could you try to pass the PSRAM test with no SD card in the board... Just to be sure there is no interference / loading in the QSPI bus...

[charli va]

Jesus, give me the day to finish it. I'm working on integrating my PSRAM module because I'm developing it a lot (I'll soon have a video-focused DMA mode, and I think it's better to move forward with it than patch yours, which is more ad hoc).

Icestudio 0.12 uses the old Yosys (it works perfectly, but it's less strict). Don't worry, I'll send you the code with the minor corrections later (some rule definitions and small details).

I'm having trouble adapting the PSRAM interface because it's difficult to share the bus with the SD card, due to the tweaks, but I've made good progress in the last hour, and this is starting to look promising.

On the other hand, I tried FAT32, but it didn't work. I did try FAT16 with another card, and I think the problem might be with the card itself and not the format. Anyway, your code is great! I'll check this out more thoroughly later.

And yes, yesterday I tried with and without SD with the same idea as you, but the result was the same.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/fda178b5-2518-4af2-90f6-dc235657136bn%40googlegroups.com.

[charli va]

Jesus, only confirm if you could.  I'm disecting your code XD and i view that you put the debugger into the psram:

*pd++=*ps++; ->Debbugger to PSRAM (0x10000000).

then 

f(); -> Junmp to PSRAM.

If this works i don't understand why the test fails XD

i'm reviewing all in deep, thanks again for this awesome system, this is a great base to  make great things.

[Jesus Arias]

Hi,

The debugger won't run on the PSRAM. This is due to te fact it tries to put the PSRAM into Quad mode using it as an SPI device, and the PSRAM is unmapped from the address space if any of the SPI devices are selected, either the SD card or the PSRAM itself. So, as soon as the code puts /CS low it crashes.

If you want to run it on that memory the code that initializes the PSRAM have to be removed and the application recompiled. 

Anyway, let me attach a code example that runs on the PSRAM ("pps", it can be loaded from the serial port)

And also I have another design for test with an explicit delay in the MISO / QIO lines, just to have a try. I'm suspecting the external SCK line is delayed with respect to the internal clock and this can have a bad effect on the sampling of the incoming data that could be worse on some devices... (maybe I got the Alhambra with the fastest ICE40 ;) 

Good night

[charli va]

I realized that a little later! Sorry for the impatient reply!

You have the fastest FPGA in the West!! XD

This is starting to work for me. I've managed to replace your module with mine, and access to PSRAM is now entirely hardware-based. The SD card is working now (managing the SD card and PSRAM simultaneously while trimming the lines has been quite an adventure, but it's up and running).

It's still not reading it properly; in fact, I might have found a bug in my module. I'll let you know in a bit. This is proving very useful for getting it up and running on a real system. It's giving me a lot of ideas for improving the module's interface, and in the next few days, if I can get the basic quad mode working, I'll start adding the DMA modes with burst, which I think will be great for video and audio.

I'll let you know how it goes.

[charli va]

Confirmed i have a bug in my psram module because the tests are very basic, and in two alhambras, in one works and in other no......

I think i know whats is the problem, i'm on it! tell you soon.

[charli va]

Hi at all, ths PSRAM module works!!

Yesterday my Alhambra motherboard broke (it must have had some defect because it had been malfunctioning and acting strangely for months), taking the PSRAM with it. It must have fried or damaged it completely, because it's still responding, but it's rubbish. I almost went crazy today XD. The good thing is, although it sounds surreal, while looking for trouble I found a major bug.

I had to perform an emergency "open-heart transplant" XD and now everything is working.

As I said, I've already integrated the module. Tomorrow I'll finish up some demos and send you the package with Jesús's system, including some fixes for the newer versions of Yosys and the integrated PSRAM module.

Good night!

[charli va]

Hi Jesús, I wanted to let you know I'm having some trouble with the single quad, although I'm starting to see the light at the end of the tunnel, yesterday works but it failed more demanding tests.

I'm just mentioning this to keep you all informed. The fact that it works on your Alhambra isn't because it's the fastest in Castilla ;)  , it's because of the Yosys version. :)

In the newer version, which is stricter and seems to be "playing the game," it's eliminating two lines of the PSRAM during synthesis, which is ridiculous.

So, on the one hand, your code works, but only on the older Yosys. Since you mentioned it was "buggy," I imagine you must have noticed something. I only ran your test, and it works perfectly (I did it after discovering the problem).

Now I'm working on how to fix it so that both your code and my integrated module work on the new Yosys.

I'll keep you posted.

[charli va]

    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]

Hi,

Thanks for the upgraded code. I'm aware my PSRAM controller is a pretty mess. I managed to get it working but not without problems. The main teaching here is:

READ the F****** DATASHEET before writing any code ;)

Well, in the Defender game there is my third PSRAM controller, with many differences with respect to Larvas's, and this time it seems to behave a little better, probably because I considered the PSRAM timing constraints from the beginning (but not yet the hold time you mention).

And about your comments:

1- Series resistors. The estimated delay is about RC, with R=220ohm and C below, lets say, 10pF. This is just 2.2ns while a clock cycle @ 25MHz is 40ns, so, this doesn't seem to be a very limiting value. In fact, we can surely get larger delays in the FPGA itself (point 2). Anyway, this delay can relax the hold time requirements as the incoming data is sampled using the internal clock that has its edges in advance with respect to the external SCK clock. (In fact, I'm sampling the incoming data on the falling edges of the clock in order to account for large propagation delays)

And about the SD card. It adds some more capacitance to the bus, sure, but I also found that It interferes with the data lines even if its /CE signal is high until it is properly initialized into SPI mode. Once initialized it no longer affects the PSRAM reading / writing.

2- The design is slow. In fact 25MHz is also near the limit of the LaRVa core itself, but nexpnr reports much lower clock frequencies (about 12.9MHz, and sometimes even less, so I lowered the frequency constraint to 8MHz). But it seems to me that the "slow" block is the "flashcache" controller, that is in fact running at 50MHz without problems, and this is a bit confusing...

But even with all these headaches, the inclusion of the PSRAM in the shield design was a wise one, and with 8MB of RAM it gives the Alhambra board a lot of possibilities. Thanks a lot Carlos for suggesting it!

Nice day

[charli va]

It's a real pleasure, Jesús, to collaborate on this project. Very, very interesting things are going to come out of it... and I think it's going to be a very important learning tool for everyone who joins.

Onward!

--
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...@googlegroups.com.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/67a4cfc7-4ad8-4310-b519-06c19af345a9n%40googlegroups.com.