The first AXI module.
  FPGA proven NO
  ASIC proven NO
The ARM® AXI® interface is used by many IP providers. In this directory you
will find the first of, hopefully many more, AXI modules. The testbench also contains a behavioural
module which can generate AXI bus cycles. The docs directory has a short description.
Modules which multiplex two, three .. five AXI busses into one. They can be used for full AXI or AXI light.
For usage with AXI-light you can removed the unused ports or not connect to them and
let the synthesis tool take care of that.
- The axi_mux*rr.v selects the input port on a round-robin** basis.
- The axi_mux*p.v selects the input port on priority basis. (Port 0 has the highest priority)
- The number specifies the number of input ports.
The code is 99% combinatorial (6 registers).
In future I might bring out 6, 7 and 8 input muxes. For now you can cascade them. e.g. two 4 input muxes will give you 7 ports.
Or if you urgently need one contact me by email. (See main page)
The code can be found here.
As usual the code comes complete with the test benches I used to verify the operation. The test-bench IS self-checking.
For the testbench you need to download the other modules on this page: the AXI testmaster and the AXI dual ported memory.
You will also need my standard synchronous FIFO module.
Modules which splits an AXI bus into two, three or four busses. It can be used for full AXI or AXI light.
For usage with AXI-light you can removed the unused ports or not connect to them and
let the synthesis tool take care of that.
The splitter is a bit more complex then the mux so there is a manual which tells
more about how it works, but more important why I designed it that way.
This splitter requires my synchronous FIFO which can also be downloaded from this web site
here.
I am working on a 4 output splitter.
The code can be found here.
As usual the code comes complete with the test benches I used to verify the operation. The test-bench IS self-checking.
For the testbench you need to download another modules from this page: the AXI testmaster.
This test bench requires a split check module which you can find alongside the axi_split2_testbench.
The decode_error module gives the correct AXI error response on all incoming signals.
For example on reads it returns the correct number of read data units (all set to zero),
each with the error response: decode error.
For writes it returns a single b-response error code.
This prevents the AXI system from locking up if an address is selected which is not serviced by any AXI slave.
It is intended to be used with a splitter, where all unmapped address space is routed to a separate port.
The testbench is NOT self checking for writes but it is for reads. The correct write operation has
been verified 'visually'. The testbench is derived fromthe axi_split2 testbench.
The code can be found here.
The axi_testmaster module can be setup to generate AXI master read and write cycles. Special features of the testmaster:
It can generate write cycles where the write address and the write data have a defines phase (clock cycles) against each other,
even where the write data arrives before the write address.
Read and check result. The user can specify a read cycle and at the same time has the option to specify what
read data is expected back. The testmaster will then check if this is the case.
There is a short manual which describes the features of the test master and has an example usage.
The code can be found here.
You will also need my standard synchronous FIFO module.
The axi_dpm32 module is a dual-ported memory with an AXI interface. Altough originally intended as pure behavioural model
the code turned out to be very well synthesizable.
As the module was targeted as end-point for the mux testing it has not been parametrised much.
At the moment it only supports a 32-bit wide memory.
The code can be found here.
You will also need my standard synchronous FIFO module.