Sorry, you need to enable JavaScript to visit this website.

Redirecting Peripherals from MIO to EMIO


A great question was posted by maw41 on the forums today:

maw41 wanted to know if he could pull the signals for the Ethernet MAC within the Processing System (PS) of the Zynq-7000 AP SoC device, out through the Programmable Logic (PL).  The answer is yes!

I thought I would take this opportunity though to talk about how to move signals from the MIO pins (those that are dedicated to the MIO Bank) to the EMIO pins (those that are available to the PL).

First, create a PlanAhead project targeting your Zedboard and add an embedded source (to see how to do this check out this forum post:

Once you have completed the BSP Wizard, you will be presented with the main screen displaying System Assembly View that looks like this:

Find the I/O Peripherals list on the left side of the PS and click on it.


After you click the IO peripherals list you will see that the same list of peripherals displayed in the System Assembly View, is now displayed in a pop-up with additional configuration information.


Now for maw41, they will select the Enet 0 option and switch the selection from "MIO 16 .. 27" to "EMIO".  EMIO is an internal bank of IO that dumps directly into the PL of the Zynq device.  In the event that you as a designer wanted to configure any additional ports, this is the same process you would follow, however you would select different peripherals.

Now, here it is important to note that not all peripherals are supported within EMIO.  An example of this is USB.  There are dedicated PHY's within the IO structures of the MIO bank that are needed to use USB.  These primitives do not exist within the PL portion of the device.  Take some time to play around with what peripherals can and can not be used via EMIO.

Next, we will check to ensure that our Enet 0 device was correctly placed within our Ports tab within the System Assembly View.  Click the Ports tab on the top of the System Assembly View and explained the the "processing_system7_0" item within the list.  Under that item, the tree will be populated with the various external ports the PS has.  Scroll down and you should see a line that reads: "(IO_IF) ETHERNETIF_0 ... Not Connected".  Great!  We have successfully added the Enet 0 peripheral to the Ports list, now we just need to connect it to the internal EMIO bank within the PS.

To connect the port to the EMIO pins we will need to select the pull down that currently says "Not Connected to External Ports" and select "Make Ports External".  This will cause the Stub that gets generated within PlanAhead to include these signals within it, so they can be used within the PL.

That's it!  Run your Design Rule Check (DRC) check, and save your project.  Once you exit XPS you will be back to PlanAhead and you can create your Stub HDL wrapper for your processing sub system by choosing "Create Top HDL" from the right mouse click menu on your module_1 source file. (if you are having trouble with this, check out the blog post I linked in the beginning of this post).  Once you have generated your stub you will be able to browse to see that it includes your added ports:

Well that is the flow for switching between MIO and EMIO pins on the Zynq-7000 APP SoC using PlandAhead and XPS.


Happy Zynq'ing!


austin's picture


I thought that I would add that I had been told that on the ZC702, the second hard UART could not be used, and that recently I cleared that up as being in error.

One can route the second UART TX and RX through to PL IO pins, and hence off the device, even if the MIO pins are already all in use.

If anyone has done this, it would be nice to see such an example documented (as I need to do it, too!!!).

fletch's picture

The procedure for exposing the PS UART through to the PL is exactly the same as what ZynqGeek showed for the ethernet. Find your free UART in the PS Peripheral Configuration tool, enable it, and then connect it to EMIO. Make the ports external, and connect them in the UCF.

maxman's picture

Thanks for your post.
But I have a question.
If we do as you described, are we able use both embedded MAC and custom MAC inside PL?
Or if we route Ethernet pins to EMIO, internal MAC becomes unavailable.

fletch's picture

When you route the PS Ethernet to EMIO, you are connecting the PS internal MAC to PL pins. The procedure for using a custom MAC built in the PL and routed to PL pins is completely different.

sdominiak's picture

Thanks for the post.
I was just wondering if anyone has got this working together with the FMC-ISMNET card for Ethernet? We have been having trouble trying to redirect the MDIO signals to EMIO and no reference design is currently provided for that card (although it is on the roadmap:'s picture

. I was going through the user guide of zed boards and I see that USB-UART interface lines, UART_TX and UART_RX, of the board are connected to the UART peripheral of processor subsystem of the Zynq FPGA . Is it possible that the mapping is also available to the Programmable FPGA section, where other design UART peripheral will be present ? Is it possible that USB-UART bridge is accessible to other UART peripheral in the Zynq FPGA (Programmable section)?

fletch's picture

This post talks about routing PS peripherals through the EMIO to the PL pins. Unfortunately, it does not work in reverse. You are not able to access MIO pins from the PL. Therefore, on ZedBoard, the USB-UART bridge is only accessible to the PS UART.
Your other alternative is to purchase a USB-UART bridge Pmod and connect it to one of the PL Pmods on ZedBoard.,401,928&Prod=P...

tbernath's picture

So, when you bring the ETH0 to EMIO, it comes out GMII, instead of RGMII. I noticed in the image, there are a bunch of entries not defined in GMII, nor the hardware docs. Any ideas on what needs to be done to ties these off successfully? I want route the ethernet signals through some logic and hook Chipscope to it, and it looks like this is the way to do it.

The other question, since this mapping from the internal MAC to the PHY is via UCF, would it be easier to just divert the mapping to a piece of user code, and twiddle the signals from the PHY before they go to the internal MAC?

Any suggestions?


output processing_system7_0_ENET1_GMII_TX_EN_pin;
output processing_system7_0_ENET1_GMII_TX_ER_pin;
output processing_system7_0_ENET1_MDIO_MDC_pin;
* output processing_system7_0_ENET1_PTP_DELAY_REQ_RX_pin;
* output processing_system7_0_ENET1_PTP_DELAY_REQ_TX_pin;
* output processing_system7_0_ENET1_PTP_PDELAY_REQ_RX_pin;
* output processing_system7_0_ENET1_PTP_PDELAY_REQ_TX_pin;
* output processing_system7_0_ENET1_PTP_PDELAY_RESP_RX_pin;
* output processing_system7_0_ENET1_PTP_PDELAY_RESP_TX_pin;
* output processing_system7_0_ENET1_PTP_SYNC_FRAME_RX_pin;
* output processing_system7_0_ENET1_PTP_SYNC_FRAME_TX_pin;
output processing_system7_0_ENET1_SOF_RX_pin;
output processing_system7_0_ENET1_SOF_TX_pin;
output [7:0] processing_system7_0_ENET1_GMII_TXD_pin;
input processing_system7_0_ENET1_GMII_COL_pin;
input processing_system7_0_ENET1_GMII_CRS_pin;
* input processing_system7_0_ENET1_EXT_INTIN_pin;
input processing_system7_0_ENET1_GMII_RX_CLK_pin;
input processing_system7_0_ENET1_GMII_RX_DV_pin;
input processing_system7_0_ENET1_GMII_RX_ER_pin;
input processing_system7_0_ENET1_GMII_TX_CLK_pin;
input [7:0] processing_system7_0_ENET1_GMII_RXD_pin;
inout processing_system7_0_ENET1_MDIO_pin;

fletch's picture

I'm not sure how to tie the undefined entries. I suggest you open a case with Xilinx support -- Sounds like the documentation in this area needs improvement, and a support case is the best way to get the ball rolling for this.
Regarding your question about using code to route out to the PL pins instead of UCF, you need to use the UCF. The tools have to physically create these routes, which is not possible from code. Additionally, with the pin-out in the UCF, the tools will cross-check for timing and placement to make sure things don't get broken in the process.

lodup29's picture

Just wondering about the tradeoffs one has to make to use EMIOs from the PS. Besides the documented ones (ex : not all PS IO peripherals can be routed though EMIOs) I'd like to confirm that the following 2 are correct:

- PS must boot with the PL configured. Runtime PL reconfiguration must be done through partial configuration to avoid IO disruption
- Power consumption increase is limited to PL static and IO consumption


fletch's picture

For question #1, I'm not sure I understand. In Zynq, the PS controls configuration of the PL. So PS boots and then the PS configures the PL. Partial reconfiguration is also controlled through the PS. See the following example design
You should be able to estimate Power consumption using the Xilinx Power Estimator

ashish_k29's picture

I was trying to follow the steps mentioned, but in my case when I open the IO pop-up box, GPIO is not a dropdown list but a single menu item.
this is what it basically looks like. Also I get very strange errors if I try to continue after making those changes.

zynqgeek's picture

It looks like you are in some flavor of Linux.  Are you using a supported OS?  Here is the list of supported operating systems by Xilinx:
If you are using one, I suggest contacting your local FAE as it could be a larger configuration issue with your environment.

tbernath's picture

Still trying to tie off the Zedboard via the EMIO, and wondering if it's even feasible to still use the Marvel PHY. Looks like the only connection information I can find is the RGMII, but EMIO only accepts the GMII, so now we have rx0-7/tx0-7, etc.

So, if we route to the Zynq out the EMIO, it goes to PL, and not possible to get back to PHY?

Anyone have some ideas on this?

fletch's picture

I may be misunderstanding what you are asking.  Are you asking if you can take the PS GEM interface out through EMIO into the PL and then back to MIO to reach the Marvell PHY on the PS MIOs?
The short answer is that it is not possible to get from PL back to the PS MIOs.
It might help if you explained why you are trying to do this, then we might have some other suggestions for you.

Steve Bennett's picture

@tbernath Take a look at

Should answer your questions

tbernath's picture

Thanks Steve,
I did come across this one. The rub was that it is still a GMII to GMII, and not the RGMII that is on the zedboard. There was a lot of interesting things in the Verilog, but their 'connector' was simple. There is a GMIItoRGMII IP core that is intended for the Zynq, however, that core has some funky MDIO connections and clocking that I cant figure out.

Two steps forward, three steps back it seems.

mohamed.amr's picture

Thanks for this great post!

I am working on a Xilinx Zync zc702 Evaluation kit. I also use a FMC XM105 debug card to be able to reach signals routed through EMIO.

My wish is to route the SPI peripheral signals (MOSI, MISO, CLK and SS) and also to have one GPIO reached via the FMC connector.

I tried to follow this tutorial but I am stuck. I selected EMIO in IO peripherals window in XPS, but can't find ports in ports tab

I really still miss some concepts about routing through EMIO, there are many pins in the Zync package (484). How would I know on which pins will the routed signals be (to reach it physically by the FMC connector)? I can't find this information anywhere. Can you please clarify this point?

Thanks in advance.

santiago's picture

I have the same problem. In contraint file apear 3 wires bidirectional and we need 4, MOSI,MISO,CLK and SS.

ashish_k29's picture

Is it necessary to Create Top-HDL from PlanAhead ? I prefer to directly use XPS to generate bitstreams, would that be ok ? I manually assign the EMIO pins through the system.ucf.

insekt's picture

According to the user guide UG585 for Zynq Ethernet controller can be programmed to use clocks from PL (Figure 16-2, p. 466).
How this task can be done?
Without this action redirecting Ethernet pins to PL is useless.

TroutChaser's picture

The signals you redirected from Ethernet 1 to the PL are the interface from the MAC inside the Zynq Processor Section (PS) to a PHY that you will need to supply. Figure 16-8 in the Zynq-7000 AP SoC Technical Reference Manual (UG585) is a good illustraion.
Just as the Ethernet 0 MAC on the ZedBoard is connected via the MIO pins to a Marvell PHY with an RGMII interface you will need to connect Ethernet 0 via the EMIO/Programmable Logic section via MII/GMII interface to an external PHY that you provide. On a ZedBoard that probably means adding an FMC daughter card with a PHY. Typically the board with the PHY will have an oscillator to generate clocks for the PHY which will in turn supply the required clocks to clock capable input pins on the Zynq programmable logic section. These are the signals you will connect to the Ethernet 1 MAC via EMIO.
Here is an example of a ZedBoard compatible FMC PHY card:

ymarkosc's picture

hello ,
I'm using vxworks as RTOS , and my questions is beside doing the redirection from MIO to EMIO , are there changes i the BSP software layer, if someone is using vxworks , please provide what are the changes