zbasic VS zipcpu

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.

For example, my most recent ZipCPU DMA design will (eventually) handle 8b, 16b, 32b, or arbitrary transfer sizes for both reading or writing. This has forced me to place a shim both before and after the FIFO to make it work properly.

The Some Assembly Required series on Youtube has a good walkthrough of implementing a 6502, from scratch. Also, /u//ZipCPU has some good documentation of the CPU he built from scratch, as well as some tutorials, at https://zipcpu.com/ and https://github.com/ZipCPU/zipcpu.

check out this usage chart for the ZipCPU's logic usage (also linked above). Each line in the chart beginning with Zip represents a different CPU configuration. If the FPGA speeds were the same (they aren't typically), then each configuration line should have the same CPU speed (not counting interconnect, RAM or peripherals). Two of the columns measure iCE40 4-LUTs and Xilinx 6-LUTs.

If you are looking for an AXI4 cache implementation, the ZipCPU currently supports two (I+D) that you might be able to gain some insights from. There's the AXI instruction cache implementation, and an AXI4 data cache implementation. They are both one way caches. Both were featured in an article on performance measurement last year. The data cache implementation doesn't support exclusive access yet--that's still on my to-do list. You can find these caches demonstrated in my AXI DMA check repo, if you'd like to try them out.

My experience comes from both the ZipCPU (a basic pipelined CPU) and verifying a lot of bus components. I haven't (yet) done an out of order processor, although I will say that verifying a cache gets really basic with formal methods, and I've now verified several cache implementations. The first data cache I wrote took me about two weeks to both write and complete a full formal proof.

I've posted quite a few AXI designs on github. These include an AXI Crossbar, an AX DMA, and even an AXI scatter-gather based DMA. Some of my recent postings even include instruction or [data](instruction caches.

Were this my task, I'd write the core myself. I have, for example, an AXI instruction cache you can reference if you'd like and I'm currently building a data cache following this Wishbone example, only for AXI instead. (I was hoping to offer a Zoom call today for anyone interested, where we'd try verifying this new data cache, but ... I didn't get far enough along on the project to do so today. Perhaps next week.()

In some of my early CPU tests, one of my earlier instruction fetches would just keep reading up to 16 instructions ahead of time. I thought this was great until I started examining the resulting performance. The first problem was that it wouldn't release the bus for either a data load or store, and the next problem was that the request was so long the result was often irrelevant by the time it arrived since the CPU had already branched away from the addresses it was fetching.

That solution isn't all that satisfying to me, so ... I'm trying to do better. My next attempt is going to be 1) using the ZipCPU instead of the ARM (at least for simulation, and certainly instead of a BFM), 2) using AXI instead of Wishbone (Yes, the ZipCPU can now speak either Wishbone or (mostly) AXI), using my own AXI infrastructure (to get rid of the bridges), and using AutoFPGA to compose the design together and handle addressing requirements (instead of Qsys).

Yes, the ZipCPU is modular. It consists of several components: a pre-fetch (of which there are several to choose from), an instruction decoder, an ALU, a divide unit, a multiply unit, and a memory unit (of which there are multiple to choose from again). Each unit has its own unit tests (proofs--not simulations).