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.

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.

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.

There is no such thing as a PS PHY. Only a PS MAC. The PHY is external.

You can certainly use a PL MAC with an external PHY. In fact, we have a new board coming out that shows how to use a Microchip PHY. If you are interested, start a new forum topic and ask about a Microchip PHY that works with Xilinx.

. 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)?

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.https://www.digilentinc.com/Products/Detail.cfm?NavPath=2,401,928&Prod=P...
Bryan

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?

I'm not sure how to tie the undefined entries. I suggest you open a case with Xilinx support -- www.xilinx.com/webcase. 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.
Bryan

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

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.http://postimg.org/image/9d5dgfijd/
this is what it basically looks like. Also I get very strange errors if I try to continue after making those changes.

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?

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.

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.

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?

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.

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.

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

Dear all,
I tried to use internal ethernet PHY from MAC on PL. The purpose is PHY in ZYNQ7 is controled by Try Mode Ethernet MAC, which is touched by Microblaze. But the gmiis and the mdios have same direction. It means they are not able to be connected.
What is usecase of ethernet MAC swtiched into EMIO?
Best regards,
Kiwamu Okabe

I have implemented a simple design including a zynq processor and a microblaze to comminicate through the UART with Zedboard. I want to have access to the UART from microblaze using zynq processor (zynq is master and microblaze is slave), I have attached my block diagram here. I've tried numorous time to get any output from UART but I was not succesful. Also you can see the link in following has done almost the same. If you can help me regarding communication througfh UART, I would be grateful.https://rseyyedi.github.io/Hello_World_Microblaze/