zipcpu VS nes-test-roms

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

nestest is the go-to for testing the CPU with logs. Here's the README, ROM, and log.

either check the results left in $02 and $03, or compare an execution log to e.g. this one.