boxlambda/understanding-vera/

[giscus[bot]]

boxlambda/understanding-vera/

Frank van den Hoef’s VERA Versatile Embedded Retro Adapter, used by the Commander X16 project, is a standalone FPGA with an 8-bit external bus interface. I spent some time studying its Video Controller implementation, out of interest, and because I need a good understanding of VERA to be able to integrate it properly into the BoxLambda SoC.

https://epsilon537.github.io/boxlambda/understanding-vera/

[jsyk]

Thanks for the article.
In the beginning you write about VRAM (128kB) and later on you speak about Main RAM. Is this the same or distinct?
Is VRAM implemented inside of FPGA (as BlockRAMs), or is it outside of FPGA as a memory chip? If inside, do they use dual-ported or single-ported memory blocks? --> 128kB is rather a lot for a lot of small FPGAs (I am thinking about ICE40LP/HX which has max 128k-bits (!) of RAM blocks)
My understanding is that VERA is a proper slave on the CPU's memory bus, i.e. there is no bus-mastering (DMA) to the CPU RAM, right? (That would imply VRAM == Main RAM in your description).
Apropos, which FPGA did Frank use? I could not see this basic info by my quick glancing on his code repo. How large (LUTs) is it? (Again, I am thinking about ICE40HX4K in a TQFP package, and having an open-source toolchain.)
Jaroslav.

[epsilon537]

Hi Jaroslav,

VRAM and Main RAM are the same. Main_ram.v is just the name of the verilog module implementing the VRAM, hence the ambiguity. The term Main RAM here has nothing to do with overall system main memory.
I noticed the ambiguity yesterday and was going to update the post, but I didn't get around to it yet.

The VRAM is implemented as single port Block RAM. SP256K is the primitive being used. The Lattice ICE40UP5K has four such memory blocks, i.e. 4x256Kbit=1024Kbit=128KByte. VERA is using it all for VRAM.

I intend to integrate VERA into my Arty A7 based SoC. I will also be using block RAM for VRAM. The problem with external RAM is that it's typically SDRAM-based, with complex memory access cycles and hard-to-predict/guarantee memory access latencies.

VERA is indeed a pure slave connected to the CPU via an 8-bit bus. There is no bus mastering from VERA to the CPU RAM. Also the access from the CPU to VERA's VRAM is limited. It's not memory-mapped. The CPU has to access the VRAM indirectly using a narrow register interface. See VERA's programmer's reference for details: https://github.com/fvdhoef/vera-module/blob/rev4/doc/VERA%20Programmer's%20Reference.md

The FPGA used for Frank's VERA is a Lattice ICE40UP5K in the 48-pin QFN,

[jsyk]

Hi again, and thanks for the explanation!
In the meantime I implemented VERA into my own 65C02-based computer.
It is a work in progress, of course, but I can already run CX16 ROM and execute a Basic program:
https://github.com/jsyk/x65
I hope my design will be more tinker-friendly and forward-thinking than the CX16 is.
Jaroslav.

[epsilon537]

I'm glad you found it useful :-)
Best of luck with your ambitious project! Looks like you're pretty far along already. It'll be interesting to see how the Aura FPGA works out.