UART Peripheral (UART 0, and UART1) implementation on ZedBoard, a development board for Zynq 7000

Abstract:  UART is one of the most common wired communication protocols used in low data rate applications. There are two UART controller interfaces, namely UART 0, and UART 1, readily available in PS part of Zynq 7000, which can be used to communicate with external devices equipped with UART interface. In this tutorial, Both UARTS are implemented over MIO Pins, where UART1, and UART0 are connected to USB UART, and Pmod E  over MIO 48-49, and MIO 14-15 respectively.

Implementation: The block diagram illustrated in the following figure provides an overview of implementation of UART(s) in ZedBoard.

pic

The PS part of Zynq 7000 contains many I/O peripheral (IOP) controller interface for data communication. The two UART interfaces ,UART 0 and UART 1, in PS enable Zynq to communicate with any external devices that incorporates UART interface. These UART interfaces can be mapped to either MIO or EMIO. MIO pins allow PS to directly exchange information with external device over UART interface, while EMIO pins make possible the data exchange between PL and PS within Zynq.

In this tutorial both UARTs are implemented over MIO pins, where UART 0 and UART 1 are mapped on MIO 14-15, and MIO 48-49 respectively. MIO 14-15 pins are mapped to PmodE 9-10 in ZedBoard, therefore external UART pins should be connected on these pins. MIO 48-49 pins are mapped to USB UART connector, hence any micro USB connected on this connector should be able to exchange data. It is worth noting that  these UARTs can be mapped on other MIO or EMIO pins.

The TCL file available in the following GitHub link can be used to generate the UART 0, and UART 1 related hardware files in Vivado. The SDK project containing the C driver files of UART interfaces are available in this GitHub Link. Each link has read me files instructing to build the complete project.

The video given below explains all the steps needed to implement UARTs over MIO interfaces in ZedBoard.

Part 3: Implementation of GPIO via EMIO in All Programmable SoC (AP SoC) Zynq 7000

Abstract: In this tutorial, ZedBoard is used to implement GPIO via EMIO. Here, the GPIOs i.e., 5 buttons, 8 sliding switches, 8 LEDs, and Pmod A B C D which are not directly accessible in PS of ZedBoard are used. These GPIOs are controlled and monitored by PS through PL via EMIO interface.

Implementation: The block diagram illustrated in following figure provides an overview of implementation

1

The PS in ZedBoard can communicate with PL via EMIO interface. The PS uses Bank 2 ( Pins 54–85 ) and 3 ((Pins 86–117 ) to access and configure the EMIO interface. Each 32-bit bank independently controls 32 EMIO pins with each pin can be configured either input or output at a time. The EMIO pins are wired to PL, communicating with buttons, LEDs, sliding switches and PMODs.

The TCL file available in the following GitHub link can be used to generate the EMIO relatd hardware files (i.e., bitstream file) in Vivado. The SDK project containing the C driver files of EMIO interfaces are available in this GitHub Link. Each link has read me files instructing to build the complete project.

The video given below explains all the steps needed to implement GPIO via EMIO interfaces in ZedBoard.

Part 2: Implementation of GPIO via MIO on ZedBoard by using Vivado

Abstract: In this tutorial, ZedBoard is used to implement GPIO via MIO. Here, the GPIOs i.e., two buttons, one LED, and Pmod E which are directly accessible in PS of ZedBoard are used to implement the MIO concept.

Implementation : There are following two ways to implement the above-mentioned GPIOs in Zedboard.

  1. Go to following GitHub link Click here for GitHub Link and follow the instructions given in this link.
  2. The second way is explained here:

Open Vivado, select the zedboard from Boards, and click on finish.

1

Create block design and click OK.

2

Select Zynq7 Processor System from search box and run Run Block Automation and click Ok

3

4

Double click on processing_system7_0, deselect the reset, AXI interface, clock and some peripherals (PS-PL configuration>General>Enable Clock Reset>FCLOCK_RESET0_N, PS-PL configuration>GP Master AXI Interface> M AXI GPO interface, Clock Configuration>PL Fabric Clocks>FCLK_CLK0, Peripheral I/O Pins>TTC0, and USB0), and click Ok. You would have the following beautiful figure.

5

validate you design, generate output products and create HDL wrapper

6

Lastly, export hardware and launch the SDK. In SDK environment create application project and select hello world and finish it. Copy the code following code and paste it into helloworld.c file

/***************************** Include Files ********************************/
#include “xparameters.h”
#include “xgpiops.h”
#include “xstatus.h”
#include <xil_printf.h>
#include “sleep.h”
/************************** Variable Definitions **************************/
XGpioPs Gpio;    /* The driver instance for GPIO Device. */
XGpioPs_Config *ConfigPtr;
/*****************************************************************************/
int main(void)
{
int Status;
u32 InputData;
/* Initialize the GPIO driver. */
ConfigPtr = XGpioPs_LookupConfig(XPAR_XGPIOPS_0_DEVICE_ID);
Status = XGpioPs_CfgInitialize(&Gpio, ConfigPtr,
ConfigPtr->BaseAddr);
if (Status != XST_SUCCESS) {
return XST_FAILURE;
}
//GPIO_PS
XGpioPs_SetDirectionPin(&Gpio, 50, 0);
XGpioPs_SetOutputEnablePin(&Gpio, 50, 0);
XGpioPs_SetDirectionPin(&Gpio, 7, 1);
XGpioPs_SetOutputEnablePin(&Gpio, 7, 1);
//PMOD//////////
//output
XGpioPs_SetDirectionPin(&Gpio, 0, 1);
XGpioPs_SetOutputEnablePin(&Gpio, 0, 1);
XGpioPs_SetDirectionPin(&Gpio, 9, 1);
XGpioPs_SetOutputEnablePin(&Gpio, 9, 1);
XGpioPs_SetDirectionPin(&Gpio, 10, 1);
XGpioPs_SetOutputEnablePin(&Gpio, 10, 1);
XGpioPs_SetDirectionPin(&Gpio, 11, 1);
XGpioPs_SetOutputEnablePin(&Gpio, 11, 1);
//output
XGpioPs_SetDirectionPin(&Gpio, 12, 1);
XGpioPs_SetOutputEnablePin(&Gpio, 12, 1);
XGpioPs_SetDirectionPin(&Gpio, 13, 1);
XGpioPs_SetOutputEnablePin(&Gpio, 13, 1);
XGpioPs_SetDirectionPin(&Gpio, 14, 1);
XGpioPs_SetOutputEnablePin(&Gpio, 14, 1);
XGpioPs_SetDirectionPin(&Gpio, 15, 1);
XGpioPs_SetOutputEnablePin(&Gpio, 15, 1);
while(1){
// PS_GPIO
InputData = XGpioPs_ReadPin(&Gpio, 50);
usleep(100);
XGpioPs_WritePin(&Gpio, 7, InputData);
// PMOD E
XGpioPs_WritePin(&Gpio, 0, 1);
XGpioPs_WritePin(&Gpio, 9, 1);
XGpioPs_WritePin(&Gpio, 10,1);
XGpioPs_WritePin(&Gpio, 11,1);
XGpioPs_WritePin(&Gpio, 12,0);
XGpioPs_WritePin(&Gpio, 13,0);
XGpioPs_WritePin(&Gpio, 14,0);
XGpioPs_WritePin(&Gpio, 15,0);
usleep(100);
XGpioPs_WritePin(&Gpio, 0, 0);
XGpioPs_WritePin(&Gpio, 9, 0);
XGpioPs_WritePin(&Gpio, 10,0);
XGpioPs_WritePin(&Gpio, 11,0);
XGpioPs_WritePin(&Gpio, 12,1);
XGpioPs_WritePin(&Gpio, 13,1);
XGpioPs_WritePin(&Gpio, 14,1);
XGpioPs_WritePin(&Gpio, 15,1);
//printf(“yess”);
}
return XST_SUCCESS;
}

Finally, on the run icon click Run As> Launch On Hardware (System Debugger). Congratulation, you are able to control or monitor external signals via MIO on PS of Zedboad.

 

Part 1: Implementation of GPIO via MIO and EMIO in All Programmable SoC (AP SoC) Zynq 7000

Abstract: The tutorial provides a brief overview of available input/output peripherals (IOPs) and their relation with multiplexed input/output (MIO) and extended MIO (EMIO) in Zynq 7000. After that, a comprehensive detail of general purpose input/output (GPIO), which is one of the available IOPs in Zynq 7000, and its programming via MIO and EMIO is explained. Lastly, the GPIOs are implemented by making use of Vivado and Zedboard as a software and hardware platform respectively.

To facilitate the learners, this tutorial is sub-divided into three parts:

  • A theoretical overview of IOPs and detailed version of GPIO with their relations with MIO/EMIO,
  • Implementation of GPIO via MIO on Zedboard, and Vivado,
  • Implementation of GPIO via EMIO on Zedboard and Vivado.

Part 1: Implementation of GPIO via MIO and EMIO in All Programmable SoC (AP SoC) Zynq 7000

The IOPs (e.g., USB, UART, I2C and so on) can interact with Zynq 7000 SoC via either MIOs or EMIOs. The processor system (PS) part of Zynq 7000 has many built-in IOP controller with each controller provides its own driver available in the form of C code, enabling the users to integrate the external IOPs with PS without any extra overhead. In the following tutorials, we will be using these drivers to configure external IOPs. It is important to note that these controller are only available in PS part, so IOPs can only communicate with this part of Zynq 7000 SoC. If someone is interested in using IOPs in programmable logic (PL) part of Zynq 7000 SoC, he shall design the pertaining accelerator or can used Xilinx accelerator in PL. PS of Zynq directly can interact with the external IOPs via MIO.  The MIO pins however are limited in number.  Xilinx also provides its solution by introducing EMIO pins. So, EMIO can be used to exploit IOP controllers available in PS to make direct communication between PS and PL or to interact with the external IOPs via PL in case if all the MIO pins are occupied. The available IOP controllers in PS of Zynq are shown in the following figure.

GPIO: General purpose input/output (GPIO) ,shown in red dotted rectangle in the above figure, is one of the IOPs supported by Zynq 7000. According to Wikipedia “GPIO is an uncommitted digital signal pin on an integrated circuit or electronic circuit board whose behavior—including whether it acts an input or output—is controllable by the user at run time. GPIOs have no predefined purpose and are unused by default”.  It is cleared from the definition of GPIOs that their functions and IO directions are fully configurable. Their application includes but not limited to monitor and control the other circuitry. They can be used to implement low data rate communication standards (e.g., 12C, UART, SPI, etc.).  In Zynq 7000, PS can use GPIO to monitor or control the signals in PL and in external world via EMIO and MIO respectively.

The GPIO peripheral provides a software with observation and control of up to 54 device pins via the MIO module. It also provides access to 64 inputs from the Programmable Logic (PL) and 128 outputs to the PL through the EMIO interface. The GPIO is organized into four banks of registers that group related interface signals.

Each GPIO can be independently and dynamically programmed as input, output, or interrupt sensing. Software can read all GPIO values within a bank using a single load instruction, or write data to one or more GPIOs (within a range of GPIOs) using a single store instruction. The GPIO control and status registers are memory mapped at base address 0xE000_A000 [ug585].

  • Bank0: 32-bit bank controlling MIO pins[31:0]
  • Bank1: 22-bit bank controlling MIO pins[53:32]
  • Bank2: 32-bit bank controlling EMIO signals[31:0]
  • Bank3: 32-bit bank controlling EMIO signals[63:32]
Banks of Register related to GPIO [ug585]

Functional Description of GPIO banks: All the registers used to configure GPIO bank(s) (bank0 and bank1) are shown in the following figure and the functions of the registers are summarized as follows:

  • DATA_RO enables software to observe the value on the device pin,
  • DATA allows all 32 bits data to write at one time,
  • MASK_DATA_LSW and MASK_DATA_MSW enable any combination of up to 16 LSB or MSB bits to write respectively,
  • DIRM control the direction of the respective bank (e.g., when DIRM[x]==0, the output driver is disabled), OEN enables the outputs ( e.g., when OEN[x]==0, the output driver is disabled),
  • INT_MASK (read only) shows which bits are currently masked or enabled,
  • 1 to any bit of INT_EN register enables/unmasks that signal for interrupts,
  • 1 to any bit of INT_DIS register masks that signal for interrupts,
  • INT_STAT register shows if an interrupt event has occurred or not. Writing a 1 to a bit in this register clears the interrupt status for that bit.
  • INT_TYPE register controls whether the interrupt is edge sensitive or level sensitive
  • POLARITY register controls whether the interrupt is active-Low or active High (or falling-edge sensitive or rising-edge sensitive).
  • If INT_TYPE is set to edge sensitive, then INT_ON_ANY register enables an interrupt event on both rising and falling edges. This register is ignored if INT_TYPE is set to level sensitive.
Functional Description of GPIO [ug585]

Detailed explanation of AP-SoC Zynq 7000 Architecture

Zynq 7000 AP SoC ,as shown in Figure given below, mainly consists of two parts: Processor System(PS), Programmable Logic(PL). PS literally employs to implement software functions of a hybrid system while hardware related functions are realized in PL. The PS part in Zynq 7000 is further composed of Application Processor Unit (APU), Memory interfaces, Central interconnects, Input Output Peripherals (IOPs), and Multiplexed IO (MIO). APU is the central part of the PS which controls and regulates all parts of PS.APU can have either single CPU or dual CPU. Two independent L1 D cache and I cache are, respectively, employed for data and instructions in each CPU. Snoop Control Unit (SCU) are exploited to maintain the coherency between L1 caches of both processor. Coherency ensures that caches in the respective CPU have updated data. L2 caches further act as bridge between L1 cache and DDR ram. DDR ram are relatively bigger memory (e.g. 512MB in Zedboard). Besides L1, L2, and DDR ram, there is 256KB On Chip Memory (OCM) which can be used for the application which requires low latency. Watch Dog Timers (AWDT, SWDT) are utilized to reset the PS when it malfunctions.

Additionally, Timers (private timer, TTC) can be employed as timer or counter.  There are 8 Direct Memory Access (DMA) in PS as well which also plays considerable role in improving the performance of the PS. The key feature of MMU is the address translation. It translates addresses of code and data from the virtual view of memory to the physical addresses in the real system. It enables tasks or applications to be written in a way which requires them to have no knowledge of the physical memory map of the system, or about other programs which might be running at the same time. This makes programming of applications much simpler, as it enables to use the same virtual memory address space for each.
5

The generic interrupt controller (GIC) is a centralized resource for managing interrupts sent to the CPUs from the PS and PL. The controller enables, disables, masks, and prioritizes the interrupt sources and sends them to the selected CPU (or CPUs) in a programmed manner as the CPU interface accepts the next interrupt. Central interconnect acts as a bridge between IOP, memory interfaces, memory interfaces, and General port (GP). As shown in the Figure 1 that there many IOP controllers in PS. The I/O Peripherals (IOP) are a collection of industry-standard interfaces for external data Communication. IOP controller can access both OCM and DDR ram via central interconnects. IOPs can be accessed via 54 pins MIO which are dynamically shared among different IOPs.

In Zynq 7000 SoC, The PS and PL can be tightly or loosely coupled using multiple interfaces and other signals that have a combined total of over 3,000 connections. This enables user to effectively integrate user-created hardware accelerators and other functions in the PL logic that are accessible to the processors and can also access memory resources in the processing system. The PS and the PL are on separate power domains, enabling the user to design power efficient design. Extended MIO (EMIO), GP, High Performance (HP) ports, and accelerator coherency port (ACP) enable the users to connect the PL with PS for variety of applications. IOPs of PS can be passed to PL via EMIO. GP are low data rate interface which are mainly used to configure the custom accelerators in PL part. HP port are used for data flow. HP port can access OCM and DDR ram respectively, for low latency and relatively larger data storage. ACP has even lower latency than HP and like HP it can access OCM and DDR depending upon the application. Any kind of logic can be implemented in PL part of SoC. It has 12 ADC as well. Programmable IO enables PL to talk with the external world. The Zynq-7000 AP SoC can be booted securely or non-securely. The PL configuration bitstream can be applied securely or non-securely. Both of these use the 256b AES decryption and SHA authentication blocks that are part of the PL. Therefore, to use these security features, the PL must be powered on.

AP SoC (Zynq 7000) Hybrid Hardware Architecture Basics

In this series of tutorial I planned to explain the Zynq 7000 architecture in details. The series is divided into three parts:

  • Firstly,  the peripheral interfaces of processor and FPGA will be explained and implemented in vivado.
  • Secondly, AXI interfaces (AXI4, AXI-Stream, and AXI-lite) will be demonstrated.
  • Lastly, Advance features of Zynq 7000 architecture will be realized e.g performance measurements of DMA , OCM, DDR etc.

I, however, find it better to briefly explain the basic concepts that shall be used later in this series.

 hybrid hardware architecture

Nowadays hybrid hardware architecture (HHA) is increasingly being used in embedded systems (ES). A typical ES has processor, memory unit and inputs/outputs (IOs). Processor is the brain that control the entire ES. Memory supports the processor by holding data temporarily or permanently. IOs are used to interact with external world. Sometimes single processor is not enough to meet all requirements. Therefore some other devices such as FPGA or application specific integrated circuit (ASIC) are embedded with processor to meet the given requirements. This kind of architecture is called hybrid architecture. The typical example of HHA is shown in the following Figure. A typical example of this architecture can be seen in ZYNQ 7000 series.

1

System on Chip

In System on Chip (SoC) the electronic components are integrated on a single chip. The components can be analog, digital or mixed signals. Xilinx has introduced a new realm called All Programmable SOC (AP-SoC). In AP-SOC software programmability of a processor and the hardware programmability of an FPGA are integrated in a single chip. A typical example of this architecture can be seen in ZYNQ 7000 series.

In the following series of tutorial I will use ZEDBOARD which is an evaluation board with ZYNQ 7000 AP-SOC together many integrated peripherals.

How an FPGA Works

Before diving into ZEDBOARD, reader should have some basics about how an FPGA works. Assuming reader already knows about processor, I have given a general overview of an FPGA in the following few paragraphs. In this module, an effort is made to explain the general architecture of a FPGA.  A top down approach (from general to specific) is employed in this tutorial.

“A picture is worth a thousand words”   as stated by Fred, therefore we added as many pictures as possible to explain the concepts in easiest way. Following Figure shows the simplest form of an FPGA architecture. It is worth to note that real FPGA are much more complex than this. However, more or less, basic components remains same in all FPGA architectures. An FPGA has mainly three parts: CLB (Configurable Logic Block), routing channel, and IO (Input Output) Bank.

2

CLB are reprogrammable blocks used to implement any kind of logic. Routing channel enables different CLB to communicate with each other and IO bank connect the FPGA with the outer world. New FPGAs have more components like DSP block, but these components are not discussed in this tutorial. Lets goes a bit further to FPGA architecture. Each CLB consists of more than one Slices. Group of LUTs(Look Up Table) and flip-flops constitutes Slices. The Figure ,given below, illustrates the relationship between CLBs and LUTs.

3

LUTs are basically RAMs. Any kind of logic can be implemented by exploiting LUT. Let’s explain this concept by an example. For example, if we want to implement OR gate the contents of the RAM would be like this.

Address_Index(in[1:0])

Out

00

0
01

1

10

1

11

1

The LUT2 illustrated in following figure outputs based on address_index.

4

To make long story short, nny kind of complex logic can be implemented by exploiting the LUTs. Of course, more the complex architecture is, more the required LUTs will be.

In the next lecture, The Zynq-7000 family architecture which is based on the All Programmable SoC architecture will be demonstrated. Furthermore, complete plan about when and which part of the AP SoC will be demonstrated. It is worth to note that I will use Zedboard (an evaluation board based on Zynq-7000 architecture) will be used throughout the lectures.