arrowzip VS wbuart32

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

Try this one.

For example, some time after I built my own first serial port transmitter and receiver, someone tried using them in composition: A host (i.e. PC) would transmit a bunch of data, get received by the FPGA, processed by the receiver, and then the data would be sent back to the host via the transmitter. This is a hard test to get right, and my own design failed at the task. (It only returned every other byte!) What I learned from this is that the transmitter must take exactly (10*BAUD_CLOCKS) to transmit a byte. That also means that READY must be high on the last clock cycle of the byte to avoid falling behind. Let's just say that my own serial port wasn't (initially) up to the task. Among other things, the serial port receivers output "VALID" was only one cycle long, and didn't get latched anywhere if the transmitter wasn't ready for it. As I recall, we spent many days scratching our heads at the problem. Eventually, the person using my FPGA switched his host to sending 2-stop bits and things started working. Later, and only a long time later, did I ever find the off-by-one bug in the STOP bit state. My point? Serial port composition is an exacting test, and therefore a good one to work with. You ought to try it.

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.