arrowzip VS dbgbus

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.

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.)

If it would help, here are two SDRAM controllers: The first is for a winbond W9825G6JH (4M x 4 banks x 16 bits). It was designed for the XuLA-LX25 FPGA board, although it also works on my MAX-1000 board from Arrow as well. Beware, the clock needs to be offset 90 degrees from the data. The second controller works on an ISSI IS42S16100H/IS45S16100H SDRAM. Both use Wishbone (pipeline) interfaces. If you aren't using Wishbone, you might need a converter to ... whatever bus protocol you are using.

I've got a couple different encodings I use to push data over the serial port. Here's the hexbus encoding for example, although I more often use the WBUBUS encoding which you can find attached to many of my projects. They're all based around what I call a "debugging bus" and a "devbus interface". It's really easy to use--once you have it set up.

As examples: - Here's how I process libelf to provide me with an array of section pointers, each containing the address to load the values at - Here's where I then load the values into my design when I'm using an external loader via a debugging bus. - Here's another copy of the same, this time running from within Verilator rather than from within externally controlled logic.

The core component to the single simulated to TCP port can be found here, in uartsim.cpp. You can find a companion software program that will forward the same TCP port to a hardware serial port here, under the name netuart.cpp.

There are also open source versions of many of the pieces you will need. I now use an open source crossbar interconnect for most of my designs. I use AutoFPGA to connect all the pieces together. I mentioned my flash controller above, but I also have a SD Card controller I've used quite successfully. I've also posted a UART to Wishbone bridge and discussed network debugging, both of which I use routinely with the ZipCPU. If for no other reason, these components allow me to load or update software on my CPU even after it's been placed into an FPGA. Of course, many of those components are tied to a Wishbone bus infrastructure. You may find you need a bridge of some type to connect different buses structures together--memory naturally tends to operate at one width and clock, video at another, and your CPU at another, so it helps at times to have a universal bus adapter kit handy.

My personal solution to this problem has been to convert bus commands to UART commands. In my world, however, the PC/host sets up the UART commands and the FPGA decodes them into bus commands and then encodes a return value. This is useful because it can be done in 2 wires. I've also done it for JTAG (similar to SPI as implemented) where it takes 4 wires. Check out my articles on the "debugging bus" if you'd like to read more about this approach. (I now have AXI drivers for my debugging bus as well.)