An IPbus AXI4-lite master

[jhegeman]

Howdy,

Please have a look at this pull request. It implements an IPbus slave that behaves as an AXI4-lite (i.e., mainly: no bursts) master. The Xilinx examples have been updated along the lines of the existing examples, even though this is not strictly Xilinx-only.

In my particular case the reason to develop this was to interface to the Xilinx AXI4 External Memory Controller core. For simplicity the example (ab)uses an AXI4 GPIO interface to demonstrate readback via an independent path.

Cheers, Jeroen

[tswilliams]

Hi @jhegeman

Thanks for adding this!

A couple of general questions (apologies if they show my ignorance about some details of AXI signalling - I've been reading some parts of the AMBA AXI & ACE protocol specification today to try to get up to speed, but I may have missed quite a few subtleties / important points):

• In the AMBA spec, it states that awsize & arsize are not supported for AXI4lite, but I see that axi4lite_interface and ipbus_axi4lite_master both have a 'size' output port. Was this port added to be able to connect up Xilinx IP cores that have an AXI4 interface rather than AXI4lite, or did you find that some/many Xilinx AXI4lite IP cores actually have a 'size' port (or is there a different reason behind this port)?
• From my (naive, AXI-newbie) perspective, an alternate method of connecting an AXI4lite slave to IPbus signals would be to directly connect the two sets of signals (e.g. directly connect the address and data lines) with appropriate delays and/or simple logical mappings (e.g. driving ipb_err with (bresp != OKAY) or (rresp != OKAY) as appropriate). One limitation of that approach would be that wstrb would be hardcoded to 0xf. Were there other reasons as well that you adopted the approach from this pull request (i.e. exposing the AXI transaction parameters - addr, data, read vs write, etc - as separate registers in the IPbus address space) in order you to interface to the Xilinx AXI4 External Memory Controller core?

[jhegeman]

Hi @tswilliams,

Yes, technically this is neither AXI4lite, nor AXI4. I'm not a true expert on AXI details either, but I believe the current implementation is more than AXI4lite because it supports different transfer sizes, but not full AXI4 because it does not support burst transfers. We could make the name less specific, but that does not change the functionality. The name now at least reflects the fact that one can connect this to any AXI4lite interface, and not necessarily to any true AXI4 interface. (As far as I know.)

The reason behind the support of strobe != 0xf and the size is exactly the connection to the memory controller. In our case this has to support a 16-bit PROM interface where one can have either a dual-size transaction of 32 bits and the strobe set to 0xf, or a single-size transaction of 16 bits with the strobe set to either 0x3 or 0xc depending on the address (odd or even).

Given that AXI is made up of five independent channels (write address, write data, write response, read address, and read data), I'm not sure an IPbus/wishbone to AXI connection could be achieved with mere logic alone.

Cheers, Jeroen

[tswilliams]

OK, thanks. I think it's fine leaving axi4lite in the name (since as you say it can be connected to any AXI4lite slave) - I just wanted to make sure I understood the functionality correctly.

[tswilliams]

Run tests, please.

[jhegeman]

Hi guys,

Is this still waiting for something? It would be good if this could be merged. Then I can drop my own version of this, clean up, and move on.

Thanks! Jeroen

[tswilliams]

Hi,

I just wanted to take another look at the code before clicking the merge button. All looks good. Merging now.

Cheers, Tom

[jhegeman]

Awesome. Thanks Tom!