zipcpu VS verilog-axi

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

You can also use an AXI lite crossbar like this one: https://github.com/alexforencich/verilog-axi/blob/master/rtl/axil_crossbar.v

does anybody knows some sort of AXI4 Crossbar or maybe even an Interconnect with good performance in terms of latency? If I have something like the following scenario, the idea is that M1 txns must have very low access latency in the sense of making the CPU capable of processing at least one instruction per cc. For M2 it's fine to take more time, but what I'm observing is that with this solution for instance, I cannot achieve constant fetching from the CPU, there's always a 1 cc delay between req/resp what hits bad my IPC. Also, S1 cannot be tightly coupled to the CPU because sometimes M2 might require to also fetch from IRAM/ROM. Is it better to switch to another protocol to achieve such good performance latency? if so, what open source available solution can have interesting perf. num, wishbone / AHB?

You can also look at some of my code, which is all MIT licensed: https://github.com/alexforencich/verilog-axi

AXI DMA, or the datamover core that the AXI DMA core uses internally, depending on your use case. I also have an open source AXI DMA module that's comparable to the Xilinx datamover core here: https://github.com/alexforencich/verilog-axi/blob/master/rtl/axi_dma.v

Xilinx soft IPs: I use the Xilinx IPs: AXI DMA, AXI-Stream Datawidth converter, AXI-Stream Clock converter...etc, for which I'm able to find open source RTL designs here, here and here.

I'm thinking of synthesizing it with ASIC tools such as Synopsys DesignCompiler to check the area & timing. I found some open source projects with Verilog IPs for AXI (zipcpu, alexforencich) and AXIS (alexforencich) modules, and I think I can replace the Xilinx IPs with them. After publishing my paper, I'm planning to release my code as open-source as well.

Thanks for the reply! I ran a particular testbench from your repository but when I placed print statements(print(tb.dut.S_DATA_WIDTH.value) in each test (run_test_write,run_test_read) , I found that it prints out the default parameter value (32) every time.

Here's one of my cocotb testbenches for reference: https://github.com/alexforencich/verilog-axi/blob/master/tb/axi_adapter/test_axi_adapter.py .