vgasim VS openarty

I have built a lot of open-source C++ tooling for design verification. You can find a lot of my C++ models posted on my Github. Example C++ models include: UART, SPI/DSPI/QSPI Flash, SD-Card (SPI-based interface), VGA Video, Ethernet MDIO, PS/2 mouse, OLED display, SDRAM and more. (I've even simulated PLLs using C++ models ...) I have also written extensively about doing so at ZipCPU.com.

Most of the graphical images I've seen won't fit in block RAM on on an FPGA. (Think of an 800x600 pixel image, with 8bits per pixel, and it only gets worse from there.) The image needs to be stored elsewhere. That means, you need ports associated with feeding your image to your Sobel processor. This can happen one of two ways. You can either use a external Video frame buffer reader, or you can drive the memory bus yourself. You haven't said what type of memory bus your system has, so let me instead assume the external reader.

Definitely. To see how this might build up, consider this video sprite module. At each stage, counting from the end, the READY backs up.

Ahm ... I've certainly added C components to my test bench to create and simulate graphical interfaces. Here's one for VGA, and another for HDMI. This isn't really a "nobody does this" task. It's much easier to debug a graphical component graphically than it is to debug it with a wave file. Indeed, I owe my success in one particular video decompression example to being able to stop the simulation in real time in order to find and trace a bug.

Yes--I've done that with both VGA and HDMI. You can find the example here if you want to see how I did it.

Check out this page describing these techniques, or even the repository containing my simulator.

Why not try a Verilator based simulation like this one? You'd then be able to see the (broken) design on a window of your simulation host's screen, and capture a VCD file to see what's going on (or not)? You should be able to just place the VGA outputs into the VGASIM class to be able to see the image on your screen. Multiple video modes are supported, so select the one you need. (The demo works with all modes, but the memory mapped frame buffer's image is only built for 1280x1024, and hence the requirement in the demo).

For an example, you might wish to take a look at the histogram design I posted. Other valuable examples might include the slow filter, the slow linear phase filter, the downsampler, or even the FFT Window function. I've also got a sprite video design that I'd like to write about, but haven't had the chance to test yet. All of these designs need to deal with and work around these issues with internal block RAM.

I have a variety of C++ simulation sources that I use which can create either VGA or HDMI signals to input into a test bench--together with a couple example designs that demonstrate these test benches. They work nicely with Verilator.

This demo shows how the AXI stream framed data can be turned to pixels and sent to a screen--should that be your wish.

I have built a lot of open-source C++ tooling for design verification. You can find a lot of my C++ models posted on my Github. Example C++ models include: UART, SPI/DSPI/QSPI Flash, SD-Card (SPI-based interface), VGA Video, Ethernet MDIO, PS/2 mouse, OLED display, SDRAM and more. (I've even simulated PLLs using C++ models ...) I have also written extensively about doing so at ZipCPU.com.

The repo is the example design. It was used by software, though, that's not (currently) posted. A lot of math went into the coefficients as well--that's all in the software.

Here's the flash controller repo I use. There's a flash controller in there for SPI, Dual SPI, and Quad SPI. The Dual and Quad SPI controllers need a device specific startup script to get them into the right mode. This script should be fairly well explained by the comments. You should find at least one of these controllers that works for you. More recent versions of the controller have a Wishbone arbiter within them -- they're just not checked in the repo yet. (DSPI, QSPI). This makes it so the design fully supports two two Wishbone ports: a config port by which you can send any value and the memory mapped read port. (You can't use both at the same time.)

You can compare my configuration file for the Spansion flash with my config file for the Micron flash to see that these are the only two hardware differences between the two

I'd then recommend Verilator for simulation testing--but only after your formal design checking is complete. You can find online C++ models of a QSPI flash, RAM, and a serial port which should be good enough to get you going here. When you are ready for more permanent storage, there's also a decent C++ model of an SD card (SPI only).