WB2AXIP: A Pipelined Wishbone B4 to AXI4 bridge

Built out of necessity, this core is designed to provide a conversion from a wishbone bus to an AXI bus. Primarily, the core is designed to connect a wishbone bus, either 32- or 128-bits wide, to a 128-bit wide AXI bus, which is the natural width of a DDR3 transaction (with 16-bit lanes). Hence, if the Memory Interface Generator DDR3 controller is running at a 4:1 clock rate, memory clocks to AXI system clocks, then it should be possible to accomplish one transaction per clock at a sustained or pipelined rate. This bus translator is designed to be able to handle one transaction per clock (pipelined), although (due to Xilinx's MIG design) the delay may be up to 27 clocks. (Ouch!)

Since the initial build of the core, I've added the WB to AXI lite bridge. This is also a pipelined bridge, and like the original one it has also been formally verified.

AXI to Wishbone conversion

As of 20181228, the project now contains an AXI4 lite read channel to wishbone interface, and also an AXI4 lite write channel to wishbone interface. A third core, the AXI-lite to WB core combines these two together using a Wishbone arbiter. All four of these designs have been formally verified, and should be reliable to use.

As of 20190101, this AXI-lite to WB bridge has been FPGA proven.

The full AXI to WB bridge, however, ris rather complicated--especially when compared to WB. As a result, while there is a full-fledged AXI4 to Wishbone bridge within this project, this bridge is still not ready for prime time. It is designed to synchronize the write channels, turning AXI read-write requests into pipeline wishbone requests, maintaining the AXI ID fields, handle burst transactions, etc. The only problem is ... this full AXI4 to WB converter doesn't work (yet). At best, it is a work in progress.

If you need an AXI4 to WB capability, consider using this AXI2AXILITE core to bridge from AXI to AXI-lite, and then this AXI-lite to WB bridge bridge to get to wishbone pipeline. If you need WB classic, you can then use this pipeline to classic bridge.

Wishbone pipeline to WB Classic

There's also a Wishbone (pipelined, master) to Wishbone (classic, slave) bridge, as well as the reverse Wishbone (classic, master) to Wishbone (pipelined, slave) bridge. Both of these have passed their formal tests. They are accompanied by a set of formal properties for Wishbone classic, both for slaves as well as masters.

Formal Verification

Currently, the project contains formal specifications for Avalon, Wishbone (classic), Wishbone (pipelined), and AXI-lite buses. There's also a formal property specification for an AXI (full) bus, but the one in the master branch is known to have issues. (I actually have a good set of formal properties for verifying full AXI4 transactions. Those will be available as part of the SymbioticEDA Suite. Previews are available to my sponsors.)

Cross-bars and AXI demonstrators

This repository has since become a repository for all kinds of bus-based odds and ends in addition to the bus translators mentioned above. Some of these odds and ends include crossbar switches and AXI demonstrator cores.

• WBXBAR is a fully function N master to M slave Wishbone crossbar. Unlike my typical WB interconnects, this one guarantees that the ACK responses won't get crossed, and that misbehaving slave accesses will be timed out. The core also has options for checking for starvation (where a master's request is not granted in a particular period of time), double-buffering all outputs (i.e. with skid buffers), and forcing idle channel values to zero in order to reduce power.

  This core has been formally verified.

• AXILXBAR is a fully functional, formally verified, N master to M slave AXI-lite crossbar interconnect. As such, it permits min(N,M) active channel connections between masters and slaves all at once. This core also has options for low power, whereby unused outputs are forced to zero, and lingering. Since the AXI protocol doesn't specify exactly when to close a channel, there's an OPT_LINGER allowing you to specify how many cycles the channel should be idle for in order for the channel to be closed. If the channel is not closed, a clock can be spared when reusing it. Otherwise, two clocks will be required to access a given channel.

  This core has been formally verified.

  While I haven't tested Xilinx's interconnect to know, if the quality of their demonstration AXI-lite slave core is any indication, then this cross-bar should easily outperform anything they have. The key unusual feature? The ability to maintain one transaction per clock over an extended period of time across any channel pair.

• AXIXBAR is a fun project to develop a full NxM configurable cross bar using the full AXI protocol.

  Unique to this (full) AXI core is the ability to have multiple ongoing transactions on each of the master-to-slave channels. Were Xilinx's crossbar to do this, it would've broken their demonstration AXI-full slave core.

  This core has been formally verified.

• DEMOAXI is a demonstration AXI-lite slave core with more power and capability than Xilinx's demonstration AXI-lite slave core. Particular differences include 1) this one passes a formal verification check (Xilinx's core has bugs), and 2) this one can handle a maximum throughput of one transaction per clock. (Theirs did at best one transaction every other clock period.) You can read more about this demonstration AXI-lite slave core on ZipCPU.com in this article.

  This core has been formally verified.

• DEMOFULL is a fully capable AXI4 demonstration slave core, rather than just the AXI-lite protocol. Well, okay, it doesn't do anything with the PROT, QOS, CACHE, and LOCK flags, so perhaps it isn't truly the full AXI protocol. Still, it's sufficient for most needs.

  Unlike Xilinx's demonstration AXI4 slave core, this one can handle 100% loading on both read and write channels simultaneously. That is, it can handle one read and one write beat per channel per clock with no stalls between bursts if the environment will allow it.

  This core has been formally verified.

• AXISAFETY is a bus fault isolator AXI translator, designed to support a connection to a trusted AXI master, and an untrusted AXI slave. Should the slave attempt to return an illegal response, or perhaps a response beyond the internal timeouts within the core, then the untrusted slave will be "disconnected" from the bus, and a bus error will be return for both the errant transaction and any following.

  AXISAFETY also has a mode where, once a fault has been detected, the slave is reset and allowed to return to the bus infrastructure until its next fault.

  This core has been formally verified.

• AXI2AXILITE converts incoming AXI4 (full) requests for an AXI-lite slave. This conversion is fully pipelined, and capable of sending back to back AXI-lite requests on both channels.

  This core has been formally verified.

Commercial Applications

Should you find the GPLv3 license insufficient for your needs, other licenses can be purchased from Gisselquist Technology, LLC. Likewise the AXI4 (full) properties are available to sponsors of the ZipCPU blog.

Thanks

I'd like to thank @wallento for his initial work on a Wishbone to AXI converter, and his encouragement to improve upon it. While this isn't a fork of his work, the pipelined wishbone to AXI bridge took its initial motivation from his work.

Many of the rest of these projects have been motivated by the desire to learn and develop my formal verification skills.