Demonstration AXI4(Full) slave -- AXI Addr is a helper core used for calculating the “next” address in a burst sequence. It's based upon the algorithm discussed here.
See this post for a discussion of these crossbars.
These cores rely not only on the skidbuffer listed above, but also upon a separate address decoder that is common to all of them.
All three cores are supported by the (dev branch of) AutoFPGA.
AXIMM2S. Supports unaligned transfers, but only fully aligned stream words.
AXIS2MM. Doesn't yet support unaligned transfers. It may eventually, but it will also only ever support full word transfers through the stream.
AXIDMA. Supports unaligned transfers.
AXIVFIFO. A virtual FIFO, using an external AXI device for memory backing--perhaps even an SDRAM. It doesn't really matter--it just needs to be AXI.
AXIVCAMERA. Writes a video stream to a memory frame buffer.
AXIVDISPLAY. Reads a frame buffer from memory to generate a continuous AXI-stream video source output.
AXI to AXI-lite. Supports 100% throughput even across burst boundaries, unlike other (similar) bridges of this type you might come across.
AXI-lite to AXI. A “no-cost” bridge.
-- Read side
-- Write side
-- A following (optional) arbiter will connect read and write sides together into the same WB bus. Alternatively, each of the two sides can be submitted separately into a WB Crossbar.
-- Read side
This core, together with its sister core, migsdram, form the basis for my approach to accessing DDR3 SDRAM memory through an AXI interface using Xilinx's MIG controller. Other than the lag in going through the bridge, this solution works quite well--achieving full (nearly 100%) bus throughput when loaded.
AXI3 to AXI4. See the internal documentation of the AXI3 write deinterleaver for the details of the write deinterleaving algorithm.
The AXI4 to AXI3 bridge is still missing. This will be more difficult than its AXI3 to AXI4 sister above, since it will need to break apart large AXI4 burst requests into smaller AXI3 bursts, sort of like the AXI4 to AXI4-lite bridge does.
These follow from the discussion in this article about how to simplify a bus interconnect into something allowing easier integration of multiple slaves into a design. They work by aggregating the signaling logic across many slaves together. See the headers for each of the cores for the specifics of the standard subsets they support.
AXI Single, the companion to the AXI Double core has not yet been written. The design for it should be nearly identical. The big difference between single and double AXI slaves is that single slaves can have only one address, and that address must always be available for reading.
The goal of these firewall(s) is to create a core that, when placed between the bus master and slave, will guarantee that the slave responds appropriately to the bus master---even in the presence of a broken slave. If the slave is broken, the firewall will raise a flag that can then be used to trigger a logic analyzer of some type so you can dig deeper into what's going on.
As a bonus, the firewall may also have the capability of resetting the downstream core upon any error, so that it might be reintegrated later into the rest of the design for additional testing.
These are used to simplify interconnect generation. When there are no slaves connected to an interconnect, the interconnect generator can automatically connect one of these slaves (depending on the protocol) and be guaranteed that the protocol will still be followed. All requests, however, will return bus errors.
Asynchronous FIFO -- support function