Next step after RV32I + UART on FPGA (Traps vs VGA vs something else)

[ZiaCheema]

I am making a project i.e full stack hardware to OS from scratch on an FPGA(nexys3).

https://github.com/ZiaCheemaGit/pc-one

Thing is I dont have any mentor and all I was doing was based on intuition and a strong requirement. Now even intuition is a bit off and I feel lost.

Currently c/cpp prints can be seen over UART. Next I am unable to decide between VGA and cpu traps. I dont even know if these are the correct ones to be under discussion and entirely some other thing is required. Goal at the end is to run a pc with linux inspired terminal OS but very small obviously and run terminal programs.

Cpu traps are only required when in OS layer and not at baremetal level. VGA will be ok but then display if to be controlled by cpu would need a proper driver and that driver is an OS layer thing.

What should be implemented next? VGA or CPU TRAPS or something else?

[Demindiro]

I just so happen to also be working a RV32I SoC for a FPGA (VHDL + Vivado + Arty A7-100T), though I only have a functional UART at this point. I don't intend to make a pure RISC-V CPU though, I only use it because I don't want to port a toolchain at this time.

I would implement VGA first. You can get quite far without interrupts or traps. Strictly it isn't even needed but it is useful for more advanced systems of course.

I don't see it in the README, but I would make sure to use DMA as much as possible. DMA transfers can be performed without interrupting the CPU, which will definitely save some cycles.

[alexfru]

I am making a project i.e full stack hardware to OS from scratch on an FPGA(nexys3).
...
What should be implemented next? VGA or CPU TRAPS or something else?

If you already have UART, you may add booting over UART.

VGA is pretty rewarding. You can begin with text modes. After that adding basic graphics modes will be easy, although you'll need to write some code to display various primitives (boxes, lines, bitmaps). Bonus points for doing that in hardware at a later point.

Though, if you intend to support some Unicode in text modes and more than 256 visually distinct characters, it'll take need some software or hardware to translate Unicode code points to the corresponding characters in the font. Also, if you'd like to design your own font or want to make it small memory-wise, you can do that too. This is the font I made recently: 512_8. It's 8x8, trivially scalable to 8x16 or 16x16, supports some 50+ languages with Latin, Greek, Cyrillic and Hebrew scripts, all in just 512 characters.

Supporting storage is nice. Have something to at least read (and maybe even boot off) SD cards.

USB keyboards are definitely a lot of fun compared to PS/2 ones.

None of this strictly requires interrupt support. Polling will do. Interrupts can be added later.

[alexfru]

I just published SediCiPC. Had a lot of fun implementing basic computer parts in SystemVerilog on an FPGA. You too can do something similar.