Introduction to AXI – Custom IP

Introduction to AXI – Custom IP
Cristian Sisterna Universidad Nacional de San Juan Argentina AXI - Custom IP ICTP

Agenda Describe the AXI4 transactions
Summarize the AXI4 valid/ready acknowledgment model Discuss the AXI4 transactional modes of overlap and simultaneous operations Describe the operation of the AXI4 streaming protocol AXI - Custom IP ICTP

Need to Understand Device’s Connectivity
There is a need to get familiar with the way that different devices communicate each other in an Embedded System like a Zynq based system Learning and understanding the communication among devices will facilitate the design of Zynq based systems All the devices in a Zynq system communicate each other based in a device interface standard developed by ARM, called AXI (ARM eXtended Interface): AXI define a Point to Point Master/Slave Interface AXI - Custom IP ICTP

Today’s System-On-Chip
Shared DRAM Memory CPU General Purpose I/O DDR Controller Vide Controller SPI Ethernet Controller The problem is necessary to face in complicated design, is how to interconnect the different modules that are part of the system? …. In today’s maekter contains a large number of different modules, and each modules is responsible for particular process/action, e.g. in this diagram there are a CPU core, video controller core, etc, etc, etc, …. Is a comlex system ensambled with different IP units…. So, the question is how to connect all of them?, also, what happens if I need to connect a new module?...or a set of modules? USB DAC ADC AXI - Custom IP ICTP

AXI4 Defines a Point to Point Master/Slave Interface
Interface Options PLBv46 – Bus Spec Processor PLB AXI Inteconnect P1 Processor M_AXI S_AXI M_AXI S_AXI P1 S_AXI M_AXI PLB P2 M_AXI S_AXI P2 PLB P3 S_AXI M_AXI AXI define a Point to Point Master/Slace Interface AXI Interconnect provided by Xilinx • Memory-Mapped Protocols: In memory-mapped protocols (AXI3, AXI4, and AXI4-Lite), all transactions involve the concept of transferring a target address within a system memory space and data. Memory-mapped systems often provide a more homogeneous way to view the system, because the IP operates around a defined memory map. AXI3-based IP can be integrated into AXI4-based systems for interoperability, however most Xilinx IP natively adopt AXI4 which contains protocol enhancements compared to AXI3. Note: The processing system block in the Zynq-7000 AP SoC devices use AXI3 memory-mapped interfaces. AXI3 is a subset of AXI4 and Xilinx tools automatically insert the necessary adaptation logic to translate between AXI3 and AXI4. NOTE: AXI4-Stream is NOT memory-mapped !!! P3 AXI4 Defines a Point to Point Master/Slave Interface PLB Arbiter Peripherals AXI - Custom IP ICTP

Connectivity -> Standard
A standard All units talk based on the same standard (same protocol, same language) All units can easily talk to each other Maintanence Design is easily maintained/updated Facilitate debug tasks Re-Use Developed cores can easily re-used in other systems So, the besic answer to this question is connectivity….. To solve the problems. We need all the units to talks the same ‘language’, : the swame standard… Maintanence will be facilitate…. Add/sub Cores…. Easy to debug as well Finally, we can create a library of the Cores, we can re-use the Cores in different projects! AXI - Custom IP ICTP

Common SoC Interfaces Core Connect (IBM) WishBone AXI
PLB/OPB (Power PC-FPGA bus interface) WishBone OpenCore Cores AXI ARM standard (more to come ) AXI - Custom IP ICTP

AXI is Part of ARM’s AMBA
APB AHB AXI AMBA 3.0 (2003) AMBA is a family of interfaces used by ARM for all of its processors. Every ARM chip that ships (and there’s a lot of them. ARM microprocessors are used in iPods, Cell Phones, GPS receivers, etc), has IP that sits on at least one of these interfaces. AMBA currently has 3 main interfaces families; APB, which was introduced in AMBA1; AHB, which was added in AMBA2; and AXI, which was added in AMBA3. Each offered successively higher performance. AMBA3 is currently the most broadly adopted version of AMBA, though AMBA4 just came out, as we’ll see. Older Performance Newer AMBA: Advanced Microcontroller Bus Architecture AXI: Advanced Extensible Interface AXI - Custom IP ICTP

Enhancements for FPGAs
AXI is Part of AMBA AMBA APB AHB AXI AXI-4 Memory Map Stream Lite ATB Enhancements for FPGAs AMBA 3.0 (2003) Same Spec AMBA 4.0 (2010) Interface Features Burst Data Width Applications AXI4 Traditional Address/Data Burst (single address, multiple data) Up to 256 32 to 1024 bits Embedded, Memory AXI4-Stream Data-Only, Burst Unlimited Any Number DSP, Video, Communications AXI4-Lite Traditional Address/Data—No Burst (single address, single data) 1 32 or 64 bits Small Control Logic, FSM AMBA ?????? APB ??? AHB ????? AXI ????? ATB ?????? AXI - Custom IP ICTP

AXI – Vocabulary Interface Bus Transfer Transaction Burst Channel
Independent collection of AXI signals associated to a VALID signal Interface Collection of one or more channels that expose an IP core’s connecting a master to a slave Each IP core may have multiple interfaces Bus Multiple-bit signal (not an interface or channel) Transfer Single clock cycle where information is communicated, qualified by a VALID handshake Transaction Complete communication operation across a channel, composed of a one or more transfers Burst Transaction that consists of more than one transfer AXI - Custom IP ICTP

AXI Transactions / Master-Slave
Responds to the initiate transaction Initiates the transaction Write Transaction AXI Master AXI Slave Read Transaction Ips blocks standards interface: AXI !... Every IP need to talk the saem language… AXI is a standard: multi chip can talk each other… Every AXI link contains at least two parts: AXI Master and AXI Slave… The Master is the one that initiates transactions… Rd/Wr AXI Ssalve is the one responds the transaction that initiate the master For the read transaction the data go the slave to the master Wr from the master to the salve In both cases the master initiates the transactions. Two kind of AXI interfaces: AXI Memory mapped intefaces and AXI Stream interfaces. There are different set of signals for read transactions that for write transactions. Another important block of AXI is the Interconnecto block !!! So, the three main blocks of an AXI based system are: AXI Slave Module, AXI Master Moduleand AXI Interconnect Module. Transactions: transfer of data from one point on the hardware to another point AXI - Custom IP ICTP

? ? More than One-to-One AXI Master AXI Master AXI Master AXI Slave
What if we can one master that need to talk to two slaves??? Or viceversa, two masters and one slavE? ??? AXI Interconnect. AXI - Custom IP ICTP

AXI Interconnect AXI is an interconnect system used to tie processors to peripherals AXI Full memory map: Full performance bursting interconnect AXI Lite: Lower performance non bursting interconnect (saves programmable logic resources) AXI Streaming: Non-addressed packet based or raw interface AXI - Custom IP ICTP

? AXI Interconnect AXI Master CPU AXI Master DMA AXI Slave SPI
M_AXI S_AXI M_AXI S_AXI AXI Master DMA ? S_AXI M_AXI AXI Slave GPIO Guess thjat we have this system…. In this system each AXI Master should be able to initiate transaction on each AXI Slave… How this can be done? AXI has a module called AXI Interconnect. Thius module is the responsible for connecting the AXI MasterS and AXI SlaveS. The AXI Interconnect will AXI Slave for the AXI Masters, and it will be a Master device for the AXI Slaves S_AXI M_AXI AXI Slave BRAM M_AXI S_AXI AXI - Custom IP ICTP

AXI Interconnect – Addressing & Decoding
Address Decoding Table GPIO: 0X4000_0000 SPI: 0X4000_1000 BRAM: 0X4001_0000 Address Range: 4K Address Offset: 0X4000_1000 Addresses: X4000_0000 – 0X4000_1FFF Master should use the right address to access the Slave he wants. Address Range: 4K Address Offset: 0X4000_0000 Addresses: 0X4000_0000 – 0X4000_0FFF Address Range: 64K Address Offset: 0X4001_0000 Addresses: X4001_0000 – 0X4001_FFFF AXI - Custom IP ICTP

AXI Interconnect Main Features
Different Number of (up to 16) Slave Ports Master Ports Data Width Conversion Conversion from AXI3 to AXI4 Register Slices, Input/Output FIFOs Clock Domains Transfer In Vivado env it is very easy to change the number of Master and the number of Slaves. It is possible to connect up to 16 ports per each AXI Interconnect. There can be more than one AXI Interconnect in a system (we will see this in a moment). It is possible to have hierarchical AXI Inter. AXI Interconnect are capable to make data width conversion. E.g. on one side data width is 64 and on the other side data width is 32 bits, the AXI Inter is responsible for making the conversion of the data width. Furthermore, AXI Inter is capable of making the conversion between AXI3 and AXI4. For ex. The Xlx PS in the Zynq is operating on AXI3 standard, however the rest of the logic we design in the PL logic are AXI4. These two stardand are very similer. AXI Inter can have slices of registers to improve performance, e.g. implementing pipelining (increase latency, but improve performance). These features are programmable in Vivado env. Finally, the two side of the AXI Inter can run at two diff clock freq. Usually in Vivado env the system uses the same clock. AXI - Custom IP ICTP

AXI Interconnect axi_interconnect component
Highly configurable Pass Through Conversion Only N-to-1 Interconnect 1-to-N Interconnect N-to-M Interconnect – full crossbar N-to-M Interconnect – shared bus structure Decoupled master and slave interfaces Xilinx provides three configurable AXI4 Lite Slave AXI4 Lite Master AXI4 Slave Burst Xilinx AXI Reference Guide(UG761) The AXI interconnect is added as any other component to the hardware in IP Integrator’s Block Diagram and then connected to the target processor and various IP bus cores provided by Xilinx. The processor is always a master on the bus. The actual implementation of the AXI interconnect is with slice combinatorial logic to implement the ORed structure of the decoupled address, data, and controls signals. The context of “decoupled” refers to the fact that all the signals are unidirectional as inputs and outputs; that is, data in and data out, as opposed to a 3-state structure. The concept of a master is the bus agent that starts the transaction and owns the address out and control out signals. The Xilinx implementation of the AXI interface is documented in the Xilinx AXI Reference Guide (UG761). AXI - Custom IP ICTP

AXI Interface Example AXI - Custom IP ICTP

AXI Slave Signals AXI - Custom IP ICTP

Basic AXI Rd/Wr Process
AXI - Custom IP ICTP

AXI Channels Use A Basic “VALID/READY” Handshake
1 Master asserts and hold VALID when data is available Slave asserts READY if able to accept data DATA 2 AXI Master VALID AXI Slave 3 Data and other signals transferred when VALID and READY = ‘1’ READY 4 Master sends next DATA/other signals or deasserts VALID ACLK 5 Slave deasserts READY if no longer able to accept data 3 3 3 3 4 4 1 1 5 5 5 2 2 2 AXI - Custom IP ICTP

AXI Channels (AXI4 and AXI Lite)
Read Address Channel Address and Control AXI4 Master AXI4 Slave AXI4 Read Read Data Channel Read Data Read Data Read Data Read Data Write Address Channel Address and Control How AXI Works This section provides a brief overview of how the AXI interface works. Consult the AMBA AXI specifications [Ref 1] for the complete details on AXI operation. The AXI specifications describe an interface between a single AXI master and AXI slave, representing IP cores that exchange information with each other. Multiple memory-mapped AXI masters and slaves can be connected together using a structure called an Interconnect block. The Xilinx AXI Interconnect IP contains a configurable number of AXI-compliant master and slave interfaces, and can be used to route transactions between one or more AXI masters and slaves. The AXI Interconnect IP is described in Xilinx AXI Interconnect Core IP, page 30. Both AXI4 and AXI4-Lite interfaces consist of five different channels: • Read Address Channel • Write Address Channel • Read Data Channel • Write Data Channel • Write Response Channel Data can move in both directions between the master and slave simultaneously, and data transfer sizes can vary. The limit in AXI4 is a burst transaction of up to 256 data transfers. AXI4-Lite allows only one data transfer per transaction. (UG1037) As shown in the preceding figures, AXI4: • Provides separate data and address connections for reads and writes, which allows simultaneous, bidirectional data transfer. • Requires a single address and then bursts up to 256 words of data. Write Data Channel AXI4 Master AXI4 Write Write Data Write Data Write Data Write Data AXI4 Slave Write Response Channel Write Response AXI - Custom IP ICTP

AXI Slave - Channels AXI - Custom IP ICTP

Write Response Channel
(Full) AXI4 Read Address Channel Address and Control AXI Master AXI Slave Read Data Channel Sometimes called “Full AXI” or “AXI Memory Mapped” Single address multiple data Burst up to 256 data Data Width parameterizable 32, 64, 128, 256, 512, 1024 bits Read Data Read Data Read Data Read Data Write Address Channel Address and Control Write Data Channel AXI Master Write Data Write Data Write Data Write Data AXI Slave Write Response Channel Write Response AXI - Custom IP ICTP

AXI4 Stream No address channel, no read and write, always just Master to Slave Just an AXI4 Write Channel Unlimited burst length Supports sparse, continuous, aligned, unaligned streams Write Data Channel AXI Master Write Data Write Data Write Data Write Data AXI Slave AXI4-Stream Protocol: Use the AXI4-Stream protocol for applications that typically focus on a data-centric and data-flow paradigm where the concept of an address is not present or not required. Each AXI4-Stream acts as a single unidirectional channel with a handshaking data flow. At this lower level of operation (compared to the memory-mapped protocol types), the mechanism to move data between IP is defined and efficient, but there is no unifying address context between IP. The AXI4-Stream IP can be better optimized for performance in data flow applications, but also tends to be more specialized around a given application space. Combining AXI4-Stream and Memory-Mapped Protocols A common approach is to build systems that combine AXI4-Stream and AXI memory-mapped IP together. Often a DMA engine can be used to move streams in and out of memory. For example, a processor can work with DMA engines to decode packets or implement a protocol stack on top of the streaming data to build more complex systems where data moves between different application spaces or different IP. (UG107) The AXI4-Stream protocol defines a single channel for transmission of streaming data. The AXI4-Stream channel models the write data channel of AXI4. Unlike AXI4, AXI4-Stream interfaces can burst an unlimited amount of data. There are additional, optional capabilities described in the AMBA4 AXI4-Stream Protocol Specification [Ref 1]. The specification describes how you can split, merge, interleave, upsize, and downsize AXI4-Stream compliant interfaces. AXI - Custom IP ICTP

AXI Stream Data Data AXI Slave AXI Master AXI Slave AXIS_M AXIS_S
---- Video There are several application in which a set the data is processed by a system then it passes the data to the next system… that is, a stream of data flowing through our hardware. In these cases where a module needs to transfer data to the next module, there is no need for addresses for the specific amount of data. Furthermore, the direction of the data is always unique, from module A to module B, it does never happens that you need to transfer data from module B to module A. So, in other words module A is always writing to module B, and no address for this data transfer are required. This builds the principles of axi stream interface. An axi stream interface can be seen as a write transaction channel: ready, valid and data ; are the main signals …. AXI - Custom IP ICTP

AXI4 Lite Read Address Channel Address and Control AXI Master AXI Slave No Burst Single address, single data Data Width 32 or 64 bits (Xilinx IP only support 32) Very small size The AXI Interconnect is automatically generated Read Data Channel Read Data Read Data Read Data Read Data Write Address Channel Address and Control AXI4-Lite is similar to AXI4 with some exceptions: The most notable exception is that bursting is not supported. The AXI4-Lite chapter of the ARM AMBA AXI Protocol Specification [Ref 1] describes the AXI4-Lite protocol in more detail. The AXI4 (Advanced eXtensible Interface) protocol has been designed to offer different variants of the interconnect. The full AXI4 specification offers a diverse range of powerful features including variable data and address bus widths, high bandwidth burst operations, advanced caching support, out of order transaction completion, and various transaction protection and access permissions. Although this specification provides the user with enormous flexibility and control, it is often desirable to implement a much simpler peripheral which uses only a subset of these features. For that reason, a reduced feature variant of the AXI4 specification exists in the form of “AXI4-lite”. This subset of the specification supports uses cases where only basic interconnect transactions are required, and removes some of the more advanced capabilities of the interconnect such as cache support, burst support, and variable bit widths for the address and data buses. The AX4-lite interconnect is therefore perfect for applications where simple control and status monitoring capabilities are required for a custom built IP block. This guide discusses how to build a custom IP block in the PL, implement memory mapped registers, and make them available via the AXI4-lite interconnect so that they are visible to the processor. This guide will also discuss the creation of some basic device drivers, showing how software can be written to access the registers on the custom peripheral. Write Data Channel AXI Master Write Data Write Data Write Data Write Data AXI Slave Write Response Channel Write Response AXI - Custom IP ICTP

AXI4 Lite Read AXI Master AXI Slave
Read Address Channel Address and Control AXI Master AXI Slave Read Data Channel Read Data Read Data Read Data Read Data AXI4-lite Protocol; The Five Channels The AXI4-lite protocol has been written with a modular design flow in mind. There are five channels which make up the specification; the read address channel, the write address channel, the read data channel, the write data channel, and the write acknowledge channel. It is important to understand the function of each of these channels before starting to develop the custom IP block. For the purposes of clarity, this guide discusses the concepts of read and write transactions from the processor’s perspective. The read address channel allows the processor to signal that it wishes to initiate a read transaction. As the name suggests, this channel carries addressing information and some handshaking signals. The read data channel carries the data values that are transferred during a transaction, along with their associated handshaking signals. Together, these two channels contain everything that is needed for a successful read transaction. AXI Video There is a set of signals for Rd Trans. And another set of signals for Write transactions. In the Read transaction we have this two group of signals involved: 1- Read Address and Control signals: the master, in order to be able to read data from the axi salve, has to provide the address from which it desires to get the data (to perform the read operation) from the slave. These set of signals are called CHANNEL…. 2- then, the axi slave answers the request from the axi master, with the requited data through the data channel. AXI - Custom IP ICTP

AXI4 Lite Write Write Address Channel Address and Control Write Data Channel AXI Master Write Data Write Data Write Data Write Data AXI Slave Write Response Channel Write Response The write address channel allows the processor to signal that it wishes to initiate a write transaction. It is identical to the read address channel in every other way. The write data channel performs an equivalent function to be read data channel, except that the data flows in the opposite direction (i.e. towards the slave). For write transactions an additional channel is used in the form of the Write Response Channel. This last channel is used to allow the slave peripheral to acknowledge receipt of the data, or to signal that an error has occurred. ---- VIDEO For Write Trans 1- AXI master needs to provide to axi slave a set of signals with the required write address. 2- the axi master should send the data that it wants to be writen to the specified address on the axi slave 3- the axi slave should respond to the axi master if the data is written correctly or no… this is the response channel. AXI - Custom IP ICTP

AXI4 – AXI Lite: Signals Available

AXI4-Lite Custom IP The VHDL Underneath

AXI4-Lite Signal Names The AXI4-lite signal names are completely flexible from the point of view of the VHDL design. During the creation of a Xilinx IP block, the Vivado tools can be used to map each AXI signal onto the signal name that the designer used when creating the IP. However in order to make the life of the designer much easier, the signal names shown here are recommended when designing a custom AXI slave in VHDL. Using these signal names will allow the Vivado design tools to automatically detect the signal names during the “create and package IP” step (described later on). This will save time, effort, and confusion when debugging the design. AXI - Custom IP ICTP

AXI4-Lite Signal Names During the creation of a Xilinx IP block, the Vivado tools can be used to map each AXI signal onto the signal name that the designer used when creating the IP However in order to make the life of the designer much easier, the signal names shown here are recommended when designing a custom AXI slave in VHDL The AXI4-lite signal names are completely flexible from the point of view of the VHDL design. During the creation of a Xilinx IP block, the Vivado tools can be used to map each AXI signal onto the signal name that the designer used when creating the IP. However in order to make the life of the designer much easier, the signal names shown here are recommended when designing a custom AXI slave in VHDL. Using these signal names will allow the Vivado design tools to automatically detect the signal names during the “create and package IP” step (described later on). This will save time, effort, and confusion when debugging the design. Using these signal names will allow the Vivado design tools to automatically detect the signal names during the “create and package IP” step (described later on). AXI - Custom IP ICTP

AXI4-Lite Address Decoding
In previous versions of the Xilinx design flow (where PLB and OPB peripherals were typically used) it was necessary for each IP peripheral connected to the processor to individually decode all transactions that were presented by a master on the bus (“multi-drop”). it was the responsibility of each peripheral to accept or reject each bus transaction depending on the address that was placed on the address bus. With AXI4-lite, the interconnect does not use a multi-drop architecture, but uses a scheme where each transaction from the master(s) is specifically routed to a single slave IP depending on the address provided by the master. This premise permits a completely different design methodology to be adopted by the creator of a slave IP, in that any transactions which reach the slave’s interface ports are already known to be destined for that peripheral. Another important concept to understand before creating an AXI4-lite custom slave peripheral is the address decoding. In previous versions of the Xilinx design flow (where PLB and OPB peripherals were typically used) it was necessary for each IP peripheral connected to the processor to individually decode all transactions that were presented by a master on the bus. This was due to the PLB and OPB buses being designed with so-called “multi-drop” architectures. In essence, all of the address, data, and handshaking signals in the previous PLB/OPB implementation were routed in parallel to each slave IP connected to the bus, and it was the responsibility of each peripheral to accept or reject each bus transaction depending on the address that was placed on the address bus. With AXI4-lite, the interconnect does not use a multi-drop architecture, but uses a scheme where each transaction from the master(s) is specifically routed to a single slave IP depending on the address provided by the master. This premise permits a completely different design methodology to be adopted by the creator of a slave IP, in that any transactions which reach the slave’s interface ports are already known to be destined for that peripheral. As such, it is not necessary for functionality to be added to each slave IP to reject AXI4-lite transactions that are outside the addressable range of the slave IP. The designer merely needs to decode enough of the incoming address bus to determine which of the registers in the slave IP should be read or written. An example of how this might be coded in VHDL is provided here for reference, showing how the incoming S_AXI_AWADDR bus might be decoded to assert a series of write enable signals for a large number of other registers in the design (98 registers in this example), without requiring large quantities of VHDL code to be written. The designer merely needs to decode enough of the incoming address bus to determine which of the registers in the slave IP should be read or written AXI - Custom IP ICTP

My VHDL Code – Address Decoding
Address Decode & Write Enable AXI4-Lite IP AXI - Custom IP ICTP

AXI4-Lite Address Decoding – VHDL Example
Another important concept to understand before creating an AXI4-lite custom slave peripheral is the address decoding. In previous versions of the Xilinx design flow (where PLB and OPB peripherals were typically used) it was necessary for each IP peripheral connected to the processor to individually decode all transactions that were presented by a master on the bus. This was due to the PLB and OPB buses being designed with so-called “multi-drop” architectures. In essence, all of the address, data, and handshaking signals in the previous PLB/OPB implementation were routed in parallel to each slave IP connected to the bus, and it was the responsibility of each peripheral to accept or reject each bus transaction depending on the address that was placed on the address bus. With AXI4-lite, the interconnect does not use a multi-drop architecture, but uses a scheme where each transaction from the master(s) is specifically routed to a single slave IP depending on the address provided by the master. This premise permits a completely different design methodology to be adopted by the creator of a slave IP, in that any transactions which reach the slave’s interface ports are already known to be destined for that peripheral. As such, it is not necessary for functionality to be added to each slave IP to reject AXI4-lite transactions that are outside the addressable range of the slave IP. The designer merely needs to decode enough of the incoming address bus to determine which of the registers in the slave IP should be read or written. An example of how this might be coded in VHDL is provided here for reference, showing how the incoming S_AXI_AWADDR bus might be decoded to assert a series of write enable signals for a large number of other registers in the design (98 registers in this example), without requiring large quantities of VHDL code to be written. AXI - Custom IP ICTP

AXI4-Lite – Implementing Addressable Registers
Using the address decoding scheme above, it is extremely simple to implement registers in VHDL which can receive data values written by a master on the AXI4-lite interconnect. The following extract of code shows how an individual register can be quickly and easily implemented (in this case mapped to BASEADDR + 0x00, as has been coded in the previous VHDL snippet). Read Transaction Using the address decoding scheme above, it is extremely simple to implement registers in VHDL which can receive data values written by a master on the AXI4-lite interconnect. The following extract of code shows how an individual register can be quickly and easily implemented (in this case mapped to BASEADDR + 0x00, as has been coded in the previous VHDL snippet). For read transactions, the data stored in the registers has to be routed back to the S_AXI_RDATA bus, and this can also be achieved very easily in VHDL. Here is an example showing how to implement read transactions from a series of registers, and the associated address decoding that is required to do so. WriteTransaction AXI - Custom IP ICTP

AXI4-Lite – Controlling AXI Transactions
Usually there is a need to implement some logic to control the AXI transactions. This can be achieved by the use of a finite state machine. Here, it is an example of a (simplified) state machine, showing the implementation of some of the states, and how a read transaction might be handled in the design. The example is not designed to cover all of the states required to implement read and write transactions, but should help to illustrate a style of coding suitable for creating the FSM. With all of the aforementioned building blocks in place, it simply remains to implement some logic to control the AXI transactions. This can be achieved by the use of a finite state machine. Here is an example of a (simplified) state machine, showing the implementation of some of the states, and showing how a read transaction might be handled in the design. The example is not designed to cover all of the states required to implement read and write transactions, but should help to illustrate a style of coding suitable for creating the FSM. AXI - Custom IP ICTP

Custom AXI IPs Use of MGPO & MGP1

Standardized IP-XACT representation
Reusing Your IP IP from many sources can be packaged and made available in Vivado All IP available in the Vivado IP Catalog can be used to create IP Integrator designs Any IP Integrator diagram can be quickly packaged as a single complex IP IP Packager Source (C, RTL, IP, etc) Simulation Models Documentation Example Designs Test Bench Vivado IP Integrator Standardized IP-XACT representation IP Catalog Xilinx IP 3rd Party IP User IP Vivado supports reuse of IP is by providing users a means to capture their individual IP or IP subsystems and package that IP, and then make the IP available to other users through the Vivado IP catalog. This approach also benefits third party IP providers, who now have a standard way of providing their IP for both evaluation and purchase, and that IP will be visible through the IP Catalog. Packaging an IP Integrator diagram takes one Tcl command, or several mouse clicks. UG1037 ----- IP Packager The Vivado IP packager lets you create plug-and-play IP and add that IP to the extensible Vivado IP Catalog. Figure 1-1, page 6, illustrates the IP packager, based on the IEEE Standard for IP-XACT (IEEE Std 1685), Standard Structure for Packaging, Integrating, and Reusing IP within Tool Flows. After you have assembled your Vivado IDE user design, the IP packager lets you turn your design into a reusable IP module that you can then add to the Vivado IP Catalog, and that others can use for design work. You can use packaged IP within a Project Mode-based IP flow. You can locate the IP within the project or use a remote location (recommended). See Chapter 8, Creating and Packaging IP for more information about using the Packaging feature. UG896 AXI - Custom IP ICTP

IP Catalog Main Features
Consistent, easy access Support for multiple physical locations, including shared network drives Access to the latest version of Xilinx-delivered IP Access to IP customization and generation using the Vivado IDE IP example designs Catalog filter options that let you filter by Supported Output Products, Supported Interfaces, Licensing, Provider, or Status Using Vivado AXI IP in RTL Projects In the Vivado integrated development environment (IDE), you can access Xilinx IP with an AXI4 interface directly from the Vivado IP Catalog and instantiate that IP directly into an register transfer logic (RTL) design (Figure 2-1, page 13). In the IP Catalog, the AXI4 column shows IP with AXI4 interfaces that are supported and displays the which interfaces are supported by the IP interface: AXI4 (memory-mapped), AXI4-Stream, or none. Xilinx IP are designed to support AXI where applicable. For more information about using IP from the Vivado IP Catalog IP Catalog Features Vivado IP catalog include: • Consistent, easy access The key features of the to Xilinx IP, including building blocks, wizards, connectivity, DSP, embedded, AXI infrastructure, and video IP from a single common repository regardless of the end application being developed. • Support for multiple physical locations, including shared network drives, allowing users or organizations to leverage a consistent IP deployment environment for third-party or internally-developed IP. • Access to the latest version of Xilinx-delivered IP, which is rigorously tested prior to inclusion in the IP catalog. • Access to IP customization and generation using the Vivado IDE or an automated script-based flow using Tcl. • On-demand delivery of IP output products such as instantiation templates and simulation models (HDL, C, or MATLAB® software). • IP example designs that provide capability to evaluate IP directly as an instantiated source in a Vivado Design Suite project. • Access to version history details as recorded in the Change Log. • A <major#.minor#.Rev#> numbering scheme unifies the IP version numbers. For information, see the Xilinx IP Versioning page available from the Xilinx website: • Catalog filter options that let you filter by Supported Output Products, Supported Interfaces, Licensing, Provider, or Status. AXI - Custom IP ICTP

IP Packager The IP Packager allows a core to be packaged and included in the IP Catalog, or for distribution IP-XACT Complete set of files include Source code, Constraints, Test Benches (simulation files), documentation IP Packager can be run from Vivado on the current project, or on a specified directory Using the Create and Package IP Wizard The Vivado IDE Create and Package IP wizard lets you create and package the following: • IP using source files and information from a Vivado Design Suite project • IP from a specified directory • A template AXI4 peripheral that includes: ° HDL files ° Drivers ° A test application ° A bus functional model (BFM) (which requires special licensing) ° An example template The Create and Package IP wizard can generate Xilinx-supported AXI interfaces. These are: • AXI4: For memory-mapped interfaces, which allows burst of up to 256 data transfer cycles with a single address phase. • AXI4-Lite: A light-weight, single transaction memory-mapped interface. • AXI4-Stream: For high-speed streaming data. . UG896 The Create and Package New IP wizard takes you step-by-step through the IP creation and packaging steps. To run the Create and Package New IP wizard: ICTP

IP-XACT Industry Standard (IEEE) XML format to describe IP using meta-data Ports Interfaces Configurable Parameters Files, documentation IP-XACT only describes high level information about IP, not low level description, so does not replace HDL or Software. Enables automatic connection, configuration and integration Enables integration of 3rd Party IP (And Export of your own IP) AXI - Custom IP ICTP

Transfer Data from ARM Bus to PL Logic
Use of MGPO & MGP1 to transfer data from the PS to a AXI Slave in the PL Write transaction to PL through MGP0 Read transaction from PL through MGP1 AXI - Custom IP ICTP

IP Packager The IP Packager allows a core to be packaged and included in the IP Catalog, or for distribution IP-XACT Complete set of files include Source code, Constraints, Test Benches (simulation files), documentation IP Packager can be run from Vivado on the current project, or on a specified directory Using the Create and Package IP Wizard The Vivado IDE Create and Package IP wizard lets you create and package the following: • IP using source files and information from a Vivado Design Suite project • IP from a specified directory • A template AXI4 peripheral that includes: ° HDL files ° Drivers ° A test application ° A bus functional model (BFM) (which requires special licensing) ° An example template The Create and Package IP wizard can generate Xilinx-supported AXI interfaces. These are: • AXI4: For memory-mapped interfaces, which allows burst of up to 256 data transfer cycles with a single address phase. • AXI4-Lite: A light-weight, single transaction memory-mapped interface. • AXI4-Stream: For high-speed streaming data. . UG896 The Create and Package New IP wizard takes you step-by-step through the IP creation and packaging steps. To run the Create and Package New IP wizard: From the Tools menu, select Create and Package IP, as shown in Figure 8-2, page 71. The wizard can be used to accomplish one of these tasks: ° Package a new IP for the Vivado IP Catalog: Guides you through the process of creating a new Vivado IP using source files and information from your current project or specified directory. ° Create a new AXI4 Peripheral: Create a template AXI4 peripheral which includes HDL, driver, test application, and BFM example template. 3. Click Next. 4. Select from the options: ° Package your current project: See Packaging Your Current Project for the option description. ° Package a specified directory: See Packaging a Specified Directory, page 76 for the option description. ° Create a new AXI4 peripheral: See Creating a New AXI4 Peripheral, page 78 for more information. 5. Make your selection, and click Next. The next dialog box option differs, based upon which Choose Create or Package option you selected. ICTP

IP Manager Create and Package IP Wizard Generates HDL template for
Slave/Master AXI Lite/Full/Stream Optionally Generates Software Driver Only for AXI Lite and Full slave interface Test Software Application AXI4 BFM Example AXI - Custom IP ICTP

Create Custom AXI4 IP Creating a New AXI4 Peripheral
To create a new AXI4 peripheral: 1. From the Choose Create Peripheral or Package IP dialog box, select Create a new AXI4 peripheral, and click Next. 2. Enter the IP peripheral details: ° Name: The name of the IP. ° Version: IP version that reflects the <major#.minor#.Rev#> version scheme. ° Display Name: The name of the IP that shows in the IP Catalog. You can have different names in the Name and Display Name fields; however, the Display Name must be intuitive enough that any change in Name can reflect automatically in the Display Name. ° Description: The IP description to share with an end-user of the IP. ° IP Location: IP packager automatically adds the IP repository location. 3. Click Next. 4. Add interfaces to your IP based on the functionality and the required AXI type To include interrupts to be available in your IP, check Enable Interrupt Support (highlighted in Figure 8-10). The figure shows that generated IP supports edge or level interrupt (generated locally on the counter) and those interrupts can be extended to input ports by user and IRQ output. ° Add an interface using the mark. ° Delete an interface using the mark. The data width and the number of registers vary, based upon the AXI4 selection type. 6. Click Next. 7. Review your selections. The details of your IP are listed in the final wizard page (Figure 8-11). AXI - Custom IP ICTP

Create Custom AXI4 IP AXI - Custom IP ICTP

Edit Created Custom AXI4 IP

Hierarchy of My IP AXI - Custom IP ICTP

Package the IP AXI - Custom IP ICTP

Compatibility of My IP AXI - Custom IP ICTP

Updating Generated Files

Checking Parameters and I/O Ports
(This ends the Works on the edit_ip environment) AXI - Custom IP ICTP

Add My IP to the Repository
These steps shold be done in the Vivado Environment AXI - Custom IP ICTP

led_ip Now Available in the IP List

Files created xgui component.xml .bd drivers hdl IP XACT description
Block Diagram tcl file drivers SDK and software files (c code) Simple register/memory read/write functionality Simple SelfTest code hdl Verilog/VHDL source xgui GUI tcl file AXI - Custom IP ICTP

Steps for Custom IP - Summary
Create an AXI Slave/Master IP Core Use the Wizard to generate an AXI Slave/Master ‘device’ Set the number of registers Building the Complete Zynq system Creating a Zynq based System Adding the necessary Ips Adding our custom AXI IP Core Edit Address Space Customize the IP Core File structure of the IP Cores Edit the HDL generated by the wizard Updating the IP Core and repack Rebuild the system Programming the device Open SDK. Creating a Application and BSP project Write the “C” code to Wr/Rd the IP Cores registers Edit Space AXI - Custom IP ICTP

Introduction to AXI – Custom IP

Similar presentations

Presentation on theme: "Introduction to AXI – Custom IP"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Introduction to AXI – Custom IP

Similar presentations

Presentation on theme: "Introduction to AXI – Custom IP"— Presentation transcript:

Similar presentations

About project

Feedback