zbasic VS arrowzip

Here's sort of a generic repo you can look at which might give you some ideas.

Let me also point out that I rarely use Verilators -exe flag. I tend instead to build my designs in steps: 1) Run Verilator, 2) run make -f Vtoplvl.mk in the obj_dir directory, 3) turn my test script into an object file, and only then 4) link everything together into an executable. I've also been known for peeking at Verilator's internal variables during a simulation run--but that may be another topic entirely.

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 components found in ZBasic will split the stream into two. The key files you'll want there are dbluartsim.cpp and (again) netuart.cpp. To use dbluart, you'll need three pieces: First, you'll need to call setup() to set the baud rate, then once per clock cycle you'll want to call the operator() method--which is really just a rename for the tick() method.

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.