ONetSwitch30

ONetSwitch30

Overview

ONetSwitch30 is an All Programmable open networking innovation platform.

ONetSwitch30 is based on the Xilinx Zynq-7000 SoC, and mainly adopts the Gigabit ports. It can achieve a comprehensive experiment platform integrating calculations, storage, networks and interconnection by extension. Both its software and hardware can realize custom programming. Its reference designs are abundant and flexible, can be used to various researches on the evolution of network prototypes, and the development of customized network products. Especially, the features of the miniaturization and low power are adapted to the multi-node network tests and deployments.

Features

• General
• Main Silicon XC7Z030-2SBG485
• Power Supply DC 12V
• Primary Config. TF card
• Auxiliary Config. QSPI flash/JTAG
• Processing System
• Processor _Dual ARM Cortex-A9@800MHz_
• Cache (L1)32KB Inst. + 32KB Data per core; (L2)512KB; (OCM)256KB
• DRAM DDR3 1GBytes
• Flash Quad SPI flash 256Mb
• DMA 8 channel (4 for Programmable Logic)
• Ethernet 1x GE RJ45
• Peripherals USB / USB-UART / USB JTAG / TF card
• Programmable Logic
• FPGA Logic 125K LCs, Kintex-7, ~1.9M ASIC gates
• Host I/F AMBA AXI4 interconnect, max 100Gbps between PS-PL
• DRAM DDR3 2GBytes
• Ethernet 4x GE RJ45
• Peripherals 2x PMOD
• User IO user LEDs/push buttons/DIP switch
• Extension mini PCIe for wireless NIC or SSD

Block Diagram

Board Layout

Specification

For details of the board hardware, please download the ONetSwitch30 Hardware User Guide.

workflow

Overview

A bottom-up approach is recommended when developing on the Xilinx Zynq SoC-based ONetSwitch.
The figure below from Xilinx Wiki shows a high level block diagram of the Xilinx design flow for Zynq AP SoC.

For any layer or component in this hierarchy, you can either download the pre-built images for quick use, or modify then generate it by yourself in the way described below.

Get Prepared

• Prepare the Boot Medium
  

Xilinx Zynq SoC offers different types for system booting, on your demand.
Here in the GitHub for an ONetSwitch, the SD boot is chosen as default. An FAT partition in the size of 512MB is used for storing the boot and kernel images, while an EXT partition typically larger than 1GB is for the root file system and the applications(e.g. OpenFlow switch software).
For the detailed how-to, please refer to Xilinx Wiki Prepare Boot Medium.

• Setup a Serial Console
  

It is a must to use the USB-UART when running an interactive program on the platform or debugging. Here's a helpful link on Xilinx Wiki Setup a Serial Console.

• Get a Linux Environment
  

Software development on ONetSwitch requires a Linux environment for easy cross compilation.
Ubuntu 12.04 LTS x86_64 may lack some needed 32-bit libraries. This can be fixed by installing ia32-libs.
Ubuntu 14.04 LTS x86_64 may also lack some needed 32-bit libraries. This can be fixed by installing libc6-i386.

• Install Xilinx Tools
  

Xilinx Vivado and SDK must be installed for ONetSwitch development. Download
Notice that, by 2014 Q4, all our projects are developed with Vivado 2013.4.
When working in a Linux environment, especially for software developers, remember to setup the environment variables for cross compiler and the Vivado/SDK tools.

<source lang="bash">export CROSS_COMPILE=arm-xilinx-linux-gnueabi- source <path-to-installation>/Vivado/<version>/settings32.sh # OR source <path-to-installation>/Vivado/<version>/settings64.sh</source>

Use Pre-Built Images

The pre-built images can be fetched mainly from

• common-bin
  

This repo stores the common FSBL, SSBL(u-boot), Linux kernel(uImage) and root file system(rootfs), as well as the SDN/OpenFlow executables. It is easy to find them in the repo according to the folder and file names.
The boot loaders are board-dedicated, while the kernel image and the rootfs are applicable to all ONetSwitch boards.

• ready-to-download
  

This is a sub-folder associated with each project, usually contains the FPGA image(system.bit) and the project-specific devicetree blob(devicetree.dtb).
The boot.bin, which is created by Xilinx SDK, always consists of the common FSBL and u-boot from common-bin above, and the project-specific system.bit.

An example here to prepare for an OpenFlow software switch (ofs-sw) on ONetSwitch30 using pre-built images.
You need to collect following items and make copies of them to the FAT partition.

File	Repo	Link
boot.bin	onetswitch30	ready-to-download/boot.bin
devicetree	onetswitch30	ready-to-download/devicetree.dtb
kernel	common-bin	kernel/uImage

You need also to extract the compressed rootfs to the EXT partition and then put the application images to somewhere in the extracted folder structure.
In this example, some runtime libs are required so the sw-lib is copied as well.

File	Repo	Link
rootfs (EXT)	common-bin	rootfs/rootfs_ext4.tar.gz
sw-lib	common-bin	lib/*
sw-app	common-bin	ofs-sw/*

Notice that, all the boot.bin are prepared to start the kernel in the EXT partition, using the pre-built u-boot with suffix -ext.elf in its file name. If you want to simply run all in an FAT partition, rootfs as uramdisk and the u-boot with suffix -ram.elf. The FPGA image should be used in the boot.bin regeneration.

File	Repo	Link
system.bit	onetswitch30	ready-to-download/res/onetswitch_top.bit
fsbl	common-bin	fsbl/fsbl-ons30.elf
u-boot (FAT)	common-bin	u-boot/u-boot-ons30-ram.elf
u-boot (EXT)	common-bin	u-boot/u-boot-ons30-ext.elf
rootfs (FAT)	common-bin	rootfs/uramdisk.image.gz

Build the System

Zynq Hardware Design

The Zynq hardware design generates the system.bit, defining the ARM CPU settings in Zynq PS and the FPGA bitstream in Zynq PL.

• Create IP cores and hardware design * Configure the processor * Add and integrate IP cores * Generate the bitstream * Export the hardware design to SDK

The entire process is implemented in Xilinx Vivado tool. See more information in our Hardware Design Guide.

Zynq Software Design

The Zynq software design introduces several steps to build up an entire embedded system, from boot loader to Linux kernel, including * First stage boot loader, FSBL * Second stage boot loader, SSBL, using u-boot * Root file system, rootfs * Device tree * Linux kernel

The process needs Xilinx SDK, and working environment in Linux with cross compiler installed. See more information in our Software Design Guide.

Application Design

The applications, often the final target what we want, run on top of the OS (Linux as we mentioned above, or any others from 'bare-metal' to Android.)
For SDN/OpenFlow application, we have done following and hope to get more from you.

• A vSwitch running a CPqD ofsoftswitch13 ported to ARM ofs-sw
  
• An FPGA accelerated OFS, with both HW and SW flow tables ofs-hw

Integrate and Test

Prepare the Boot Image

The boot image, boot.bin, is created in Xilinx SDK, by assembling the FSBL, the FPGA image, and the SSBL in sequence.
1. Select 'Xilinx Tools' from the SDK menu
2. Choose 'Create Zynq Boot Image', a pop-up appears
3. Add fsbl.elf, system.bit, u-boot.elf sequentially
4. Click 'Create Image' and wait for the generation
5. Rename the output binary to boot.bin

Use the Test Sequence

Project-specific test sequence is provided as a demo. It mainly shows the usage of the board and the features of the application.
Try the test sequence and check the results.

Prepare Boot Medium

Input Files Required

1. Precompiled boot.bin for Reference NIC demo
2. Precompiled uImage
3. rootfs

Output Files Produced

1. bootable SD card

Task Description

The following instructions are taken from the OMAPPedia wiki.

The following instructions assume a Linux system. Furthermore, most commands require root permissions. After completing this steps the SD card holds two partitions which can be read/written under Linux. Windows can - if at all - only access the FAT partition; but even this seems to depend on the card reader/driver used.

Insert SD card and figure out the corresponding device. The last lines of the dmesg output should tell you under which device file the inserted SD card is available in the system. dmesg

Warning: The following commands will use '/dev/sdX' to refer to the SD card device. Replace this with the actual device on your system. Executing the following commands on the wrong device may corrupt your data on other file systems. Also, all data on your SD card will be destroyed.

The fdisk utility does not seem to erase the first few bytes of the first sector in the card when the partition table is saved. Use dd to erase the first sector. <source lang="bash"> dd if=/dev/zero of=/dev/sdX bs=1024 count=1</source>

Calculate the new_cylinders value <source lang="bash">fdisk -l /dev/sdX</source>

The output should look similar to this

Disk /dev/sdb: 8068 MB, 8068792320 bytes

249 heads, 62 sectors/track, 1020 cylinders, total 15759360 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

Look for the size of the device in bytes and calculate the new number of cylinders using the following formula, dropping all fractions: > new_cylinders = <size> / 8225280

For the example output given above, we would write down new_cylinders = 8068792320 / 8225280 = 980.

Partition the SD card. We will create two partitions on the SD card. One 200 MB sized boot partition. And a second partition taking the remaining space on the SD card. <source lang="bash"> fdisk /dev/sdX</source>

The dd command should have wiped all existing partition tables, if this is not the case, delete all existing partitions on the SD card.

Command (m for help):

Partition number (1-4): 1

Repeat this for all valid partitions numbers.

Now configure the sectors, heads and cylinders of the SD card.

Command (m for help): x
Expert command (m for help): h
Number of heads (1-256, default 30): 255
Expert command (m for help): s
Number of sectors (1-63, default 29): 63
Expert command (m for help): c
Number of cylinders (1-1048576, default 2286): <new_cylinders calculated from above>
Command (m for help): r
Now the actual partitions can be created
>Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-15759359, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-15759359, default 15759359): +200M

Command (m for help): n
Partition type:
p primary (1 primary, 0 extended, 3 free)
e extended
Select (default p): p
Partition number (1-4, default 2): 2
First sector (411648-15759359, default 411648):
Using default value 411648
Last sector, +sectors or +size{K,M,G} (411648-15759359, default 15759359):
Using default value 15759359

Now, set the bootable flag and partition IDs

Command (m for help): a

Partition number (1-4): 1

Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))

Command (m for help): t
Partition number (1-4): 2
Hex code (type L to list codes): 83

Check the new partition table and write the changes >Command (m for help): p

Disk /dev/sdb: 8068 MB, 8068792320 bytes
249 heads, 62 sectors/track, 1020 cylinders, total 15759360 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x920c958b

Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 411647 204800 c W95 FAT32 (LBA)
/dev/sdb2 411648 15759359 7673856 83 Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.

Create file systems on the new partitions <source lang="bash"> mkfs.vfat -F 32 -n boot /dev/sdX1 mkfs.ext4 -L root /dev/sdX2</source>

Mount the boot partition <source lang="bash"> mkdir -p /mnt/boot mount /dev/sdX1 /mnt/boot</source> Copy the boot.bin or contents of the release archive to the SD card, e.g. <source lang="bash">cp boot.bin /mnt/boot/</source>

Unmount the SD card <source lang="bash"> umount /mnt/boot</source>

The SD card can now be removed and transferred over to the target platform.

Ref:

1. http://www.wiki.xilinx.com/Prepare+Boot+Medium

Setup a Serial Console

This guide will explain where and how to install the USB drivers and how to install and configure a terminal emulator which allows talking to the board.

Downloading and installing USB to UART drivers

When using a Xilinx Development Board with a USB UART port use your mini-B USB cable to connect the USB UART port on the board to a PC. If the driver for this CP210x USB to UART bridge is recognized by your PC you may go to the next section, suggested HyperTerminal. If your USB to UART is not automatically recognized, the diver can be found and downloaded from the Silicon Labs website linked below.

Silicon Labs Website and installation process:

1. Go to: Silicon Laboratories
2. Select the appropriate driver for your machine (VCP driver Kit)

3. Unzip CP210x_VCP_Windows to a directory
4. Double click on CP210xVCPInstaller_x64 (or X86 depending on the machine)
5. Agree to the license agreement and select finish when complete.

Terminal Emulators

Common terminal emulators are: * Putty : Select under Windows on Intel X86 "putty.exe" (the very first link) * TeraTerm * minicom

But there are plenty more. Just choose the one that fits you.

Connection Settings

The settings for the serial connection may differ from board to board, but a good guess (and they work for zynq) are these settings: * baud rate = 115200 * data bits = 8 * stop bits = 1 * flow control = none * parity = none

The serial device depends on your operating system and cable connection. On Windows the serial devices are usually called comN (N = 1, 2, 3, ...).

On Linux you'll find the serial devices in the /dev directory. Real serial devices are usually ttySN, UART via USB may be called ttyUSBN (again N = 1, 2, 3, ...).

Configuring Putty (Windows)

1. Open your putty
2. Once open, select the option of Serial connection
   

1. Then select Select Serial in the Category section. inlkbuthgrxfthcygukgyftrgetrxychtgyjhbkblknm;l.png
2. To set the "Serial line to connect to" you must open the device manager to see which COM your board is connected. To open you device manager go to Start -> (type in search) Device Manager Go to the "Ports (COM & LPT)" section and look what COM your Silicon Labs USB to UART bridge is connected to
3. Write in the correct COM that your board is connected to.
4. Baud, section specific to the board, thus check the Getting started guide for the board that you have to get the correct baud rate.

Configuring minicom (Linux)

Minicom should be started with the -D <serial device> command line switch e.g. minicom -D /dev/ttyUSB0 In minicom hit ctrl+a z, to get the help up. Navigate to options->serial port setup and configure the line according to your target platform.

Ref

1. http://www.wiki.xilinx.com/Setup+a+Serial+Consol

Install Xilinx Tools

The Xilinx tools provide all required tool chains to compile and link applications for Xilinx supported platforms, create and configure hardware designs and creating bitstreams.

Xilinx Vivado Tools

• Download the Xilinx Vivado tools suite.

Output Files Produced * Installation of Xilinx tools on user's local computer

Task Description

The complete hardware/software work flow for Xilinx devices relies on a number of Xilinx-provided tools. These tools are available as download for Linux and Windows based systems. Please, follow the installer to install the tools on your system. Note that the Xilinx SDK tools must also be installed for embedded linux applications.

Platform specific hints & tips

Ubuntu 12.04 LTS x86_64 users may run into issues related to missing dependencies when installing the Xilinx tools. This release of Ubuntu lacks some needed 32-bit libraries which need to be installed. This can be done by executing: bash$ sudo apt-get install ia32-libs

Setting Up the Tools

Many software items, such as Linux, use the environment variable CROSS_COMPILE, to invoke the cross compiler that is used to build it (SDK must be installed). Also the PATH environment variable has to be extended to find the newly installed tools. <source lang="bash"> export CROSS_COMPILE=<x-tool prefix> source <Xilinx Tools installation directory>/ISE_DS/settings64.sh # use settings32.sh on 32-bit operating systems </source>

The Xilinx tools provide the following cross toolchains:

Ref:

1. http://www.wiki.xilinx.com/Install+Xilinx+Tools

Quick Start

Intro

An ONetSwitch enables users in different development roles to build a complete networking system in a single node. Users can build the embedded system either from scratch, or based on some pre-built images.
In either way, getting-started projects would help you * to get acquainted with the board and its components

• to make quick hardware tests on the main silicon and its peripherals
  
• to understand the usage and be ready for next-stage development

Project List

• Zynq PS Test
  

Project to verify the clocks, resets, memories, etc at the ARM CPU side.

• IBERT
  

Project to verify the rate and SI of the transceivers using PRBS generator.

• MAC Loopback
  

Project to verify the PHYs and the MACs on each of the Ethernet ports.

• PCIe Enumeration
  

Project to verify the Mini PCIe and the configuration of PCIe Root Complex.

• QDRII+ Memory Test
  

Project to verify the calibration of PL QDRII+ SRAM, with traffic generator.

• DDR3 Memory Test
  

Project to verify the calibration and read/write operations on PL DDR3 SDRAM.

The table below shows the applicability.

Reference Design

Intro

An ONetSwitch dedicates to networking applications, as what the product name implies. The 'All-Programmable' allows the users to get any of their inspiration realized by customizing the gateware and/or the software.
Reference designs here would help you * to comprehend the usage of board components in different cases

• to avoid developing from scratch, especially for beginners * to share your mind and contribute to our community

The letter 'O' in the product name stands for 'Open'.

We invite you to share when in such complicated network development.

Project List

• NIC
  

A host running Linux with all Ethernet ports as its NICs.

• Switch
  

A traditional Layer 2 switch, running without Linux.

• OpenFlowSwitch(SW)
  

A vSwitch running OpenFlow, simply on a host with NIC.

• OpenFlowSwitch(HW)
  

A hardware accelerated OFS, with both HW and SW flow tables.

Hardware Design

Intro

The design for ONetSwitch hardware, i.e. the FPGA part as Programmable Logic, commonly follows a Xilinx Vivado flow.
Here we provide a reference tcl script and folder structure, which show a guideline to manage the project generation and organization in Vivado, with IP package and block design integration.
All of our Getting-Started projects and reference designs are organized in this way.

Tcl Script

Project Root

The folder is assigned as the ROOT, when it originally contains following * myproj (folder) stores all the design sources and tcl.

• myproj.tcl (script) to generate the project.

IP Designs

All the design sources of user IPs are listed in the folder ROOT/myproj/ip.
The IPs should be managed in each subfolder, e.g.,
ROOT/myproj/ip/my_ip_0, ROOT/myproj/ip/my_ip_1, ... ROOT/myproj/ip/my_ip_n

In each IP folder, e.g., ROOT/myproj/ip/my_ip_n, contains typically

• src (folder) contains all design sources - hdl, netlist..
  
• my_ip_n.tcl (script) to package single IP to a zip for an IP-repository.

To generate or modify my_ip_n.tcl, please follow the Vivado IP flow.

IP Repository

The script myproj.tcl fetches the ip_list and then sources all the my_ip_n.tcl, storing the zip in a newly created folder ip-repo in the ROOT.
The ip-repo is a runtime folder for IP generation and package.

Modify the ip_list variable in "myproj.tcl" to add IPs to your block design.

Block Design

Only one block design can be supported in this tcl script.
The system block design can be created by sourcing ROOT/myproj/bd/myproj_bd.tcl
The myproj.tcl automatically generates the wrapper for the block design.

The myproj_bd.tcl can be generated by running write_bd_tcl after a complete block design in Vivado. Please follow Vivado tcl scripting guide for details.

Sources and Constraints

Common hdl, netlist and constraint files can be stored and organized in ROOT/myproj/sources and ROOT/myproj/constrs
Hierarchical folder structure is allowed.

Simply modify the source_files and constr_files variables in myproj.tcl to add these sources to your design.

Project Generation

In the Vivado tcl shell, change directory to the ROOT and simply source the tcl. e.g.,
<source lang="bash"> cd ROOT source myproj.tcl</source>

The tcl collects all IPs, blockdesign(s), common hdl/netlist/constraints and then generates the project.
Synthesis and implementation flows can be added after that.

Project Cleanup

Manually (and carefully) delete all files and folders except following * myproj (folder) stores all the design sources and tcl. * myproj.tcl (script) to generate the project.

Build FSBL

An FSBL can be generated within the template in SDK, based on the exported hardware description from Vivado system design.
We have done some patches to the template (for ONS30), and added functions to program the clock generator during the boot stage (for ONS30 and ONS45). So it is recommended to make use of the pre-built FSBLs directly instead of regenerating, unless the following PS clock settings doesn't meet your design. Below is a typical settings for PS Clocks configured during FSBL stage.
Find the pre-built FSBL images for different boards here.
Find the details of FSBL changes comparing to the official version here.

Build SSBL (u-boot)

This step must be done in a Linux environment.
Download our official u-boot repo, and refer to the Xilinx Wiki Build U-Boot for u-boot image generation.
To build u-boot for ONetSwitch execute

<source lang="bash">git clone https://github.com/MeshSr/u-boot-meshsr cd u-boot-meshsr

make zynq_ons20_config # OR make zynq_ons30_config # OR make zynq_ons45_config

make ARCH=arm CROSS_COMPILE=arm-xilinx-linux-gnueabi-</source> Notice that the generated file 'u-boot' should be renamed with .elf extension. And pay attention to the usage of mkimage.

<source lang="bash">cp -rp ./tools/mkimage <somewhere-in-$PATH> mv u-boot u-boot-<any suffix>.elf</source> The official u-boot for ONetSwitch is derived from Xilinx u-boot.
Find the details of u-boot changes comparing to the official version here.

Find the pre-built u-boot images for different boards and types of rootfs here.
Notice that we prefer u-boot-ons*-ext.elf in our reference designs.

Build and Modify Rootfs

Please refer to Xilinx Wiki Build and Modify a Rootfs.
You can download a pre-built one directly from our repo.

For uramdisk.image.gz, you have to put it directly in the FAT partition and use it together with u-boot-ons*-ram.elf.
For rootfs_ext4.tar.gz, you need to extract and copy to the EXT partition with sudoer privilege, use with u-boot-ons*-ext.elf.

Build Device Tree Blob

The Xilinx Wiki Build Device Tree Blob provides two ways to create an original .dts.
Changes has been done on the original tcl-generated .dts when the ONetSwitch and certain applications require more device/driver supporting. The recommended way is to take ours as the baseline, use or make changes on our modified .dts, and finally generate the .dtb using the Linux device tree complier.

<source lang="bash"><path-to-kernel-src>/script/dtc/dtc -I dts -O dtb -o devicetree.dtb devicetree.dts</source> The modification on the devicetree is closely related to the board hardware and the driver support. Please refer to the .dts in each ready-to-download folder for more details.

Build Linux Kernel

This step must be done in a Linux environment.
Download our official Linux repo, and refer to the Xilinx Wiki Build Kernel for kernel image generation.
To build kernel for ONetSwitch execute

<source lang="bash">git clone https://github.com/MeshSr/linux-meshsr cd linux-meshsr

cp -p arch/arm/configs/meshsr_ons_defconfig .config make uImage UIMAGE_LOADADDR=0x8000 ARCH=arm CROSS_COMPILE=arm-xilinx-linux-gnueabi-</source> The official Linux kernel for ONetSwitch is derived from Xilinx Linux.
Find the details of kernel changes comparing to the official version here.

Find the pre-built kernel image here.

Miscellaneous

ONetSwitch repositories

• Getting-Started projects and reference designs for ONetSwitch30
• ONetSwitch series wiki
• The official Linux kernel for MeshSr ONetSwitch
• common binaries for quick getting-started
• The official u-boot for MeshSr ONetSwitch
• OpenFlow controller and application references
• OpenFlow switch software supporting ONetSwitch hardware flow tables.
• OpenFlow switch software running software flow tables ONLY.

By 2014 Q4, all the versions are from Vivado 2013.4

Xilinx Data Sheets and User Guides

• Zynq Product Table Download
  

• Zynq Overview DS190 Download
  

• Zynq (Z-7010 ~ Z-7020): DC and AC Switching Characteristics DS187 Download
  

• Zynq (Z-7030 ~ Z-7100): DC and AC Switching Characteristics DS191 Download
• Zynq Technical Reference Manual UG585 Download
  

• Zynq Software Developers Guide UG821 Download
  

• Zynq Packaging and Pinout UG865 Download
  

• Zynq PCB Design and Pin Planning Guide UG933 Download
• OS and Libraries Document Collection UG643
  

• AXI Reference Guide UG761 v14.3 Download

Xilinx Intellectual Properties

Communications

• LogiCORE IP AXI Ethernet PG138 v6.0
  

• LogiCORE IP Ethernet 1000Base-X PCS/PMA or SGMII PG047 v14.1
  

• LogiCORE IP Tri-Mode Ethernet MAC PG051 v8.1
  

• LogiCORE IP AXI 10-Gigabit Ethernet PG157 v1.1
  

• LogiCORE IP 10-Gigabit Ethernet PCS/PMA PG068 v4.1
  

• LogiCORE IP 10-Gigabit Ethernet MAC PG072 v13.0
  

• LogiCORE IP XAUI PG053 v12.1

Memory and Controllers

• LogiCORE IP AXI DMA PG021 v7.1
  

• Zynq-7000 SoC and 7 Series Devices Memory Interface Solutions UG586 v2.0
  

• LogiCORE IP AXI Block RAM (BRAM) Controller PG078 v3.0
  

• LogiCORE IP AXI External Memory Controller (EMC) PG100 v2.0
  

• LogiCORE IP FIFO Generator PG057 v11.0
  

• LogiCORE IP Block Memory Generator PG058 v8.1
  

• LogiCORE IP Distributed Memory Generator PG063 v8.0

Interface and Interconnect

• LogiCORE IP AXI Interconnect PG059 v2.1
  

• LogiCORE IP AXI4-Stream Interconnect PG035 v1.1
  

• LogiCORE IP AXI Bridge for PCI Express PG055 v2.3
  

• 7 Series FPGAs Integrated Block for PCI Express PG054 v3.0
  

• LogiCORE IP 7 Series FPGAs Transceivers Wizard PG168 v3.1
  

• LogiCORE IP AXI4-Stream FIFO PG080 v4.0
  

• LogiCORE IP AXI GPIO PG144 v2.0

Embedded

• LogiCORE IP Processing System 7 PG082 v5.3
  

• LogiCORE IP Processor System Reset Module PG164 v5.0
  

• LogiCORE IP AXI4-Lite IP Interface (IPIF) PG155 v2.0
  

• LogiCORE IP AXI Ethernet Lite MAC PG135 v2.0
  

• LogiCORE IP AXI IIC Bus Interface PG090 v2.0

Misc.

• LogiCORE IP Clocking Wizard PG065 v5.1
  

• LogiCORE IP IBERT for 7 Series GTX Transceivers PG132 v3.0