Abstract
The need for higher performance applications is driving the requirement for a new age of on-chip communication infrastructure.This project examines the advantages of the new AMBA 4.0 using Advanced eXtensible Interface (AXI-2.0) protocol for on-chip bus infrastructure, and how it revolutionizes the future of high-performance system-on-chip (SOC) interconnect. It describes the AMBA 4.0 (AXI-2.0) protocol feature set that makes it suitable for the new high-performance, low-latency and low-power designs.
AMBA is a solution for the blocks on single chip to interface with each other without using PCI buses. It is a high speed, high bandwidth, high clock frequency bus that supports multi-master bus management to maximize system performance.
About AMBA
• Amba is the registered trademark of ARM ltd.which is one of the leading semiconductor company.
• This project is based on implementation of ADVANCE MICROCONTROLLER BUS ARCHITECTURE (AMBA) using SYSTEM ON CHIP TECHNOLOGY (SOC)
• The designing of AMBA is based on AXI(Advance extensible interface)-PROTOCOL.
About AXI Protocol
• Advanced Extensible Interface(AXI) is a part of AMBA, a family of microcontroller buses first introduced in 1990.
• AMBA AXI protocol is targeted at high-performance, high frequency system designs and includes a number of features that makes it suitable for high speed submicron interconnect.
System On Chip(SOC)
• SOC refers to integrating all components of a computer or other electronic system in to a single integrated circuit chip.
• The important aspect of SOC is not only, which components or blocks it houses, but also how they are interconnected.
• It can content digital, alalog, mix signals & often RF functions.
• A typical application is in the area of embedded systems.
Key Features Of AMBA
• Separate address/control and data buses.
• Burst-based transactions with only start address issued.
• Seperate read and wite data channels to enable low-cost Direct Memory Access(DMA).
• Ability to issue multiple outstanding addresses.
• Easy addition of resister stages to provide timing closure.
Objectives Of AMBA
• Be suitable for high-bandwidth and low-latency designs.
• Enable high-frequency operation without using complex bridges.
• Meet the interface requirements of a wide range of components.
• Provide flexibility in the implementation of interconnect architectures.
• Be suitable for memory controllers with high initial access latency.
• Be backward compatible with existing AHB and APB interfaces.
About Addressing Options
• The AXI protocol is burst-based, and the master begins each burst by driving transfer control information and the address of the first byte in the transfer.
• As the burst transaction progresses, it is the responsibility of the slave to calculate the addresses of subsequent transfers in the burst.
• Bursts must not cross 4KB boundaries to prevent them from crossing boundaries between slaves.
Burst Length
• The AWLEN or ARLEN signal specifies the number of data transfers that occur within each burst. As Table 4-1 shows, each burst can be 1-16 transfers long.
• Burst length encoding
• For wrapping bursts, the length of the burst must be 2, 4, 8, or 16 transfers
Burst Size
• Table shows how the ARSIZE or AWSIZE signal specifies the maximum number of data bytes to transfer in each beat, or data transfer, within a burst
• Burst size encoding
• The AXI determines from the transfer address, which byte lanes of the data bus to use for each transfer.
• The size of any transfer must not exceed the data bus width of the components in the transaction.
• For incrementing or wrapping bursts with transfer sizes narrower then the data bus, data transfer are on different byte lanes for each width of the bus.
• The address of a fixed burst remains constant, and every transfer uses the same byte lanes.
Burst Type
The AXI protocol defines three burst types described in:-
• Fixed Burst
In a fixed burst, the address remains the same for every transfer in the bus. This burst type is for repeated accesses to the same location such as when loading or emptying a peripheral FIFO.
• Incrementing Burst
In an incrementing burst, the address for each transfer in the burst is an increment of the previous transfer address. The increment value depends on the size of the transfer. For example, the address for each transfer in a burst with a size of 4 bytes is the previous address plus four.
• Wrapping Burst
The wrapping burst is similar to an incrementing burst, in that the address for each transfer in the burst is an increment of the previous transfer address.
However, in a wrapping burst the address wraps around to a lower address when a wrap boundry is reached. The wrap boundary is the soze of each transfer in the burst multiplisd by the total number of transfers in the burst.
Boundary condition = size * beat
where, beat = 2, 4, 8, 16
and, size = 4 byte
About Channels
• There are five different channels used in AMBA - 4.0(AXI - 2.0 protocol) for data transfers, controls and responses.
• Each of the five independent channels consists of a set of information signals and uses a two-way VALID and READY handshake mechanism.
• The information source uses the VALID signal to show when valid data or control information is available on the channel.
• The destination uses the READY signal to show when it can accept the data.
• Both the read data channel and write data channel also include a last signal to indicate when the transfer of the final data item within the transcation takes place.
Write Address Channel
• Write transaction has their own address channel. The appropriate address channel carries all of the required address and control information for a transaction.
• It has variable lenght bursts, from 1-16 data transfers per burst.
• Burst with a transfer size of 8-1024 bits.
• It consists of wrapping, incremanting, non-incrementing bursts.
• The master can assert the AWVALID signal only when it drives valid address and control information. It must remain asserted untill the slave accepts the address and control information and asserts the associated AWREADY signal.
• The default value of AWREADY can either be HIGH or LOW.
Write Data Channel
• Write data channel conveys the write data from the master to the slave.
• It includes the data bus that can be 8, 16, 32, 64, 128, 512, or 1024 bits wide.
• Write data channel information is always treated as buffered, so that the master can perform write transactions without slave acknowledgement of previous write transactions.
• During a write burst, the master can assert the WVALID signal only when it drives valid write data. WVALID must remain asserted until the slave accepts the write data and asserts the WREADY signal.
• The default value of WREADY can be HIGH, but only if the slave can always accepts the write data in a single cycle.
• The master must assert the WLAST signal when it drives the final write transfer in the burst.
Write Response Channel
• Write response channel provides a way for the slave to respond to write transactions. All write transaction use completion signalling.
• The completion signals occurs once for each burst, not for each individual data transfer within the burst.
• The slave can asserts the BVALID signal only when it drives a valid write response. BVALID must remain asserted until the master accepts the write response and assert BREADY.
• The default value of BREADY can be HIGH.
Read Address Channel
• Read transaction has their own address channel. The appropriate address channel carries all of the required address and control information for a transaction.
• It has variable lenght bursts, from 1-16 data transfers per burst.
• Burst with a transfer size of 8-1024 bits.
• It consists of wrapping, incremanting, non-incrementing bursts.
• The master can assert the ARVALID signal only when it drives valid address and control information. It must remain asserted untill the slave accepts the address and control information and asserts the associated ARREADY signal.
• The default value of ARREADY can either be HIGH or LOW.
Read Data Channel
• Read data channel conveys both the read data and any read response information from the slave back to the master.
• It includes the data bus that can be 8, 16, 32, 64, 128, 512, or 1024 bits wide.
• A read response indicating the completion status of the read transaction.
• The master can assert the ARVALID signal only when it drives valid address and control information. It must remain asserted until the slave accepts the addresss and control information and asserts the associated ARREADY signal.
• The default value of AREADY can be HIGH or LOW.
About Interface and Interconnect
• A typical system consists of a number of master and slave devices connected together through some form of interconnect.
• The AXI protocol provides a single interface definition for describing interfaces, between a master and the interconnect, between a slave and the interconnect, between a master and a slave.
• The interface definition enables a variety of different interconnect implementations. The interconnect between devices is equivalent to another device with symmetrical master and slave ports to which real master and slave devices can be connected.
• Most systems use one of three interconnect approaches, shared address and data buses, shared address buses and multiple data buses, multilayer, with multiple address and data buses.
• In most systems, the address channel bandwidth requirement is significantly less than the data channel bandwidth requirement. Such systems can achieve a good balance between system performance and interconnect complexity by using a shared address bus with multiple data buses to enable parallel data transfers.
Address Generator Coding
-- Company:
-- Engineer:
--
-- Create Date: 18:49:52 03/26/2011
-- Design Name:
-- Module Name: address_generator - Behavioral
-- Project Name:
-- Target Devices:
-- Tool versions:
-- Description:
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
----------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
entity address_generator is
port(start: in std_logic_vector(31 downto 0);
awlens:in std_logic_vector(3 downto 0);
s1,slin,sels1,sels2: in std_logic;
sl_wrap:in std_logic_vector(1 downto 0);
s: in std_logic_vector(2 downto 0);
clk,reset: in std_logic;
zs:out std_logic_vector(31 downto 0));
end address_generator;
architecture beh of address_generator is
component mux_81
port(
s : in std_logic_vector(2 downto 0);
y : out std_logic_vector(31 downto 0));
end component;
component mux_21
port(start,cpu : in std_logic_vector(31 downto 0);
sel : in std_logic;
x : out std_logic_vector(31 downto 0));
end component;
component adder
port(x,y : in std_logic_vector(31 downto 0);
stop:in std_logic;
z : out std_logic_vector(31 downto 0));
end component;
component wrap2
port(z,start : in std_logic_vector(31 downto 0);
clk,reset:in std_logic;
w2 : out std_logic_vector(31 downto 0));
end component;
component wrap4
port(z,start : in std_logic_vector(31 downto 0);
clk,reset:in std_logic;
w4 : out std_logic_vector(31 downto 0));
end component;
component wrap8
port(z,start : in std_logic_vector(31 downto 0);
clk,reset:in std_logic;
w8 : out std_logic_vector(31 downto 0));
end component;
component wrap16
port(z,start : in std_logic_vector(31 downto 0);
clk,reset:in std_logic;
w16 : out std_logic_vector(31 downto 0));
end component;
component wrap_mux
port(w2,w4,w8,w16 : in std_logic_vector(31 downto 0);
sl_wrap: in std_logic_vector(1 downto 0);
wout: out std_logic_vector(31 downto 0));
end component;
component incr
port(z : in std_logic_vector(31 downto 0);
clk,reset:in std_logic;
incr_out : out std_logic_vector(31 downto 0));
end component;
component wimux
port(wout,incr_out : in std_logic_vector(31 downto 0);
slin:in std_logic;
cpu : out std_logic_vector(31 downto 0));
end component;
component counter
port ( clk,reset:in std_logic;
awlen:in std_logic_vector(3 downto 0);
sel:in std_logic;
stop:out std_logic);
end component;
component mux2
port(cpu_add:in std_logic_vector(31 downto 0);
feedback:in std_logic_vector(31 downto 0);
sel:in std_logic;
cpuout:out std_logic_vector(31 downto 0));
end component;
component regist
port(rin:in std_logic_vector(31 downto 0);
clk,reset:in std_logic;
rout:out std_logic_vector(31 downto 0));
end component;
component mux21
port(cpu_add:in std_logic_vector(31 downto 0);
feedback:in std_logic_vector(31 downto 0);
sel:in std_logic;
cpuout,moss:out std_logic_vector(31 downto 0));
end component;
signal temp1,temp2,tt,w2,w4,w8,w16,ww,wout,incr_temp,cpu,start1,tins,temp8: std_logic_vector(31 downto 0);
signal stops:std_logic;
begin
u1 : mux_81 port map
(
s => s,
y => temp1);
u2 : mux_21 port map
(cpu => cpu,
sel=>s1,
start=> start1,
x => temp2);
u3 : adder port map
(x => temp2,
y => temp1,
stop=>stops,
z => tt);
u4 : wrap2 port map
(z =>tt,
start=>start,
clk =>clk,
reset=>reset,
w2=>w2);
u5 : wrap4 port map
(z =>tt,
start=>start,
clk =>clk,
reset=>reset,
w4 =>w4);
u6 : wrap8 port map
(z =>tt,
start=>start,
clk =>clk,
reset=>reset,
w8 =>w8);
u7 : wrap16 port map
(z =>tt,
start=>start,
clk =>clk,
reset=>reset,
w16 =>w16);
u8 : wrap_mux port map
(w2 => w2,
w4 => w4,
w8 => w8,
w16 => w16,
sl_wrap => sl_wrap,
wout => wout);
u9 : incr port map
(z =>tt,
clk =>clk,
reset =>reset,
incr_out=>incr_temp);
u10 :wimux port map
(wout => wout,
incr_out => incr_temp,
slin => slin,
cpu => cpu);
u11 :counter port map
(clk=>clk,
reset=>reset,
awlen=>awlens,
sel=>slin,
stop=>stops);
u12 :mux2 port map
(cpu_add=>start,
feedback=>tins,
sel=>sels1,
cpuout=>start1);
u13 :regist port map
(rin=>temp2,
clk=>clk,
reset=>reset,
rout=>temp8);
u14 :mux21 port map
(cpu_add=>temp8,
feedback=>temp2,
sel=>sels2,
cpuout=>tins,
moss=>zs);
end beh;
