Implementing and Optimizing MIO on AMD Zynq™ UltraScale+™ MPSoC and RFSoC Platforms

Timestamps:

0:07 – Welcome and Introduction
1:03 – Who is Fidus?
3:02 – Speaker Introduction
3:41 – The Importance of Multiplexed Input/Output (MIO)
4:53 – Understanding MIO and Its Role in Embedded Systems
5:49 – Planning Peripheral Assignments for MIO
7:32 – Configuring Voltage Banks for MIO Optimization
9:01 – Mapping High-Speed Interfaces with Gigabit Transceivers (GTRs)
11:30 – Leveraging EMIO for Overflow Connectivity
13:45 – Practical Applications of MIO Optimization
13:55 – Industrial IoT Gateways
15:12 – High-Bandwidth Video Processing Systems
16:20 – Edge AI Accelerators
17:35 – Aerospace and Defense Systems
18:47 – Medical Imaging Devices
19:58 – Automotive Infotainment Systems
21:10 – Tools for MIO Optimization (Vivado, Vitis, PetaLinux)
22:30 – Q&A Session: Key Challenges and Best Practices
27:15 – Closing Remarks and Resources

****

Welcome and Housekeeping
[0:00]
Welcome everyone to today’s webinar, Implementing and Optimizing MIO on AMD Zynq UltraScale+ MPSoC and RFSoC Platforms.
[0:10]
We’re happy to have you here as we dive into the critical design techniques and strategies for maximizing the potential of these platforms.
[0:20]
Before we begin, let’s go over some quick housekeeping items to ensure a smooth experience throughout the webinar.
[0:25]
We will have a Q&A session at the end, so please submit your questions at any time through the Q&A button on the control panel.
[0:33]
If you need to chat with anybody from our administration team, just send a message through the chat.
Introduction to Fidus
[0:41]
So, who’s Fidus?
[0:42]
We were founded in 2001, and Fidus has since grown into a more than 150-person, all-North-American electronic system design services company.
[0:52]
We serve all industries and markets with three brick-and-mortar locations, two in Canada and one in the U.S. in Silicon Valley.
[0:59]
We’ve been working with embedded systems and FPGA since 2002, and it’d be safe to say that more than 80% of our projects have included FPGA content.
[1:07]
We’re proudest of our repeat customer rate—with close to 95% of our customers returning year over year with new projects and new business.
[1:16]
This is a real testament to the quality and efficiency of our work and improving their time-to-market.
[1:23]
We have a strong partner ecosystem. In fact, our partnership with AMD began over a decade ago when we were invited to become their first-ever Premier Design Services Member in North America.
[1:34]
Since then, we’ve built an exceptionally strong collaborative relationship, working closely with AMD to support clients and train them on their new technologies, like the Versal portfolio series or the AMD Embedded Plus architecture—all about helping our customers bring their solutions to market faster.
[1:53]
We actually were fortunate to have been named AMD’s Partner of the Year this past July.
[2:00]
We’ve been a trusted leader on the Zynq platform since its launch, completing over 50 Zynq UltraScale+ designs in recent years.
[2:08]
From small devices to the largest 19EG parts, we’ve delivered solutions for applications like storage systems, video streamers, and workload accelerators, using proven schematic blocks, thermal strategies, and reusable code to reduce risk and accelerate time-to-market.
[2:25]
As a full-services design firm, our professionals and engineers cover a multitude of service disciplines, including FPGA design, ASIC RTL design and verification, software, hardware, signal and power integrity, and mechanical and thermal design.
[2:42]
We help our customers by supplying some of the expert skill sets directly or by managing the complete project from start to finish.
Speakers Introduction
[2:52]
So now, I’d like to introduce our two speakers.
[2:55]
First up is Scott Turnbull, the CTO at Fidus, where he’s responsible for understanding our client requirements, generating estimates, and leading the advanced tech group here.
[3:04]
With more than 25 years of experience in the design services industry, he brings a degree in electrical engineering, unmatched creativity, and technical leadership to Fidus.
[3:13]
Joining Scott is Jeremy Brooks, a Senior Embedded Software Engineer at Fidus with over 20 years of experience in sectors like aerospace, defense, and IoT.
[3:23]
He’s got much experience working on hardware platforms, including the Zynq portfolio, making him a key resource for today’s session.
[3:30]
Now I’ll hand it over to Scott to get us started.
Introduction to Zynq UltraScale+ MIO
[3:35]
Thanks, Alecia.
[3:37]
Hello, everyone.
[3:37]
First off, thanks for joining us for this introduction to Zynq UltraScale+ and Zynq UltraScale+ RFSoC MIO.
[3:45]
As mentioned, my name is Scott Turnbull, and I’m the CTO at Fidus Systems.
[3:49]
There were two main reasons we wanted to do this webinar.
[3:52]
One, we’ve seen multiple clients that are new to Zynq UltraScale+ incorrectly assign or misinterpret the MIO assignment information.
[4:00]
And two, AMD has created a very large amount of very detailed information and notes to help you understand MIO, and we thought that pulling this information together in one place and talking it through would be valuable.
[4:12]
To jump-start you, just to let you know, Fidus has completed a large number of Zynq UltraScale+ and RFSoC designs, so we wanted to share our knowledge.
Overview of Webinar Topics
[4:22]
Here’s a list of topics we’ll be discussing today.
[4:26]
We’ll start with a very basic MIO talk and then move continually deeper until we finish with a demonstration of the MIO configuration mapping within the AMD tools.
[4:37]
Hopefully, after we’ve gone through all this, you will have an appreciation for the capabilities of the MIO, a level of comfort with how to assign them, and the knowledge that using MIOs is actually relatively simple if you understand some key limitations and if you know where to find the key information.
[4:54]
Thank you for joining us today.
[4:56]
Let’s get started.
Understanding MIO Concepts
[5:01]
Let’s start off with some high-level MIO concepts.
[5:05]
First off, what do we mean by MIO?
[5:08]
MIO stands for Multiplexed Input/Output.
[5:11]
They’re the flexible I/O connected to the Processing System (PS) of an MPSoC.
[5:17]
Just a quick note here, though.
[5:18]
Throughout this presentation, I’ll use the term “PS” to refer to the Processing System and “PL” to refer to the Programmable Logic portions of the Zynq UltraScale+.
[5:27]
The PS is the section that contains the APUs, RPUs, and a large number of other hard functions, whereas the PL is the FPGA fabric portion of the chip.
[5:39]
At this time, I also wanted to introduce you to the term “EMIO,” or Extended Multiplexed Input/Output.
[5:46]
We’ll talk about that a little bit later.
[5:49]
One of the great things about how AMD architected the Zynq UltraScale+ is that all devices have the same MIO block.
[5:59]
Here are the key features of those MIO blocks.
Key Features of MIO
[6:04]
In this table, you can see that the MIO consists of a total of 78 functionally assignable pins, which, for FPGA folks in the room, are split across three banks that are powered by user-provisionable voltage.
[6:19]
Furthermore, although not technically MIO, there are also four GTR Gigabit transceivers with a maximum rate of 6 gigabits per second that are often used in conjunction with the MIOs.
[6:31]
Now you can see the large group of hard peripherals that are accessible through the MIO and associated GTRs.
[6:39]
Before we move on to the next slide, it is important to note that MIOs are not like PL or FPGA GPIO.
[6:44]
They’re not nearly as flexible.
[6:46]
There are more limitations.
[6:48]
However, they are attachable to the hard peripherals shown above.
Documentation for MIO Design
[7:00]
With all that in mind, here’s a snapshot of some of the multitude of AMD documentation and apps that I’ve found most valuable when designing with MIO.
[7:10]
Since the Zynq UltraScale+ is super flexible, the Technical Reference Manual (TRM) for the device is well over 1,200 pages of detailed goodness.
[7:21]
But don’t let that intimidate you.
[7:23]
You don’t have to read all of it, and it is well organized.
[7:26]
But certainly read and understand everything that relates to your design.
[7:29]
I’ll refer to these documents throughout this.
Design Principles for MIO
[7:34]
With all that documentation out of the way, let’s talk about how to start assigning MIO by first noting my guiding principle of designing with Zynq UltraScale+.
[7:45]
Simply put, meet as many of your requirements as possible using PS resources.
[7:52]
I’ve seen clients that are more FPGA-centric resist this thought, but in the end, I truly believe it is the best way to go.
[8:00]
Here are the reasons why:
[8:02]
1. Software tends to be quicker: It’s generally faster to write, implement, and debug software than RTL, so leverage software when you can.
[8:10]
2. Save power: You’ll generally save power using available hard peripherals over programmable logic.
[8:16]
3. Utilize existing hardware: The hard peripherals are already there, and you’re already paying for them, so why not load them up? Save the programmable logic for functions that excel from the benefits of programmable logic.
[8:28]
For example, FPGA fabric loves functions that are low-latency, highly parallel, extremely high-speed, or highly custom.
[8:37]
4. Avoid custom driver creation: Using hard peripherals to interface to the APU or RPU avoids creating custom drivers, which are often needed for PL-based functions.
Recommended Workflow
[8:51]
So, when we start this off, this is the flow that I recommend:
[8:54]
1. Start with your system requirements.
2. Review and understand what PS hard peripherals are available.
3. Match your requirements to those peripherals and the MIO.
4. Verify your MIO assignment to ensure you haven’t done something illegal by accident.
[9:13]
Let’s now focus on the third step and, more specifically, the mapping of functions or hard peripherals to the MIO.
The MIO Table: AMD’s Greatest Tool
[9:24]
So here it is. In my opinion, this is the greatest table that AMD has ever published, aptly named the MIO Table.
[9:31]
At a glance, this table tells you which hard peripheral can be mapped to an MIO pin or a group of MIO pins.
[9:38]
Again, this is what I mean by MIOs are not as flexible as PL GPIO.
[9:43]
Only certain MIO pins or MIO pin groups can be connected to specific internal hard peripherals.
[9:50]
It certainly does have good flexibility, but not the extreme flexibility that you’re used to with an FPGA.
[9:57]
Now that you’re all craning to try to see this table, let’s zoom in so you can sit back.
Understanding the MIO Table
[10:06]
On the vertical axis, AMD lists all the hard peripherals that are supported by the MIO.
[10:13]
This zoom-in obviously only shows a subset of the functions that are available.
[10:20]
Now, across the top of the table are what I call the MIO identifiers.
[10:24]
When someone refers to MIO, one must further specify the exact MIO number, out of the 78 available, that will be allocated to a function on the vertical axis.
[10:34]
For example, we would refer to MIO 6 or MIO 8 or MIO 67 to more precisely describe what we’re talking about.
[10:43]
For now, ignore the weird out-of-order ordinals within the table.

Mapping MIO Functions to Hardware
[10:49]
The next step is to drill down to the hardware level to discover how to map MIO 0 through MIO 12 to the actual physical QSPI device on the board.
[11:02]
Let’s take a deeper dive at implementing this MIO-based QSPI interface.
[11:10]
Before we drill down, let’s acknowledge that, from the table, we see that QSPI peripheral interface can only be assigned to MIO 0 through 12.
[11:20]
Now, the weird out-of-order ordinals used to have a mapping function, but AMD has updated the next-level tables, so these ordinals are generally no longer required.
[11:30]
I suspect they were just left there for historic reasons.
[11:35]
So now we know that QSPI interface maps to MIO 0 to MIO 12.
[11:41]
But what MIO is what function?
Implementing QSPI with MIO
[11:44]
To discover this, we have to go into the dedicated QSPI Controller chapter of the previously mentioned Technical Reference Manual (TRM).
[11:52]
When we go there, we find this table.
[11:55]
From this table, we see that MIO 0 through MIO 12 are needed for a dual QSPI implementation, and only MIO 0 through MIO 6 are needed for a single QSPI design.
[12:08]
For this discussion, let’s assume that we’re implementing a dual QSPI solution.
[12:14]
Honestly, this is now pretty self-explanatory, but to be 100% clear:
• [12:16] Connect chip select for the lower QSPI device to MIO 5.
• [12:20] Connect the 0 clock to MIO 0, and so on.
[12:30]
Then connect chip select for the upper QSPI device to MIO 7, etc.
[12:36]
It should be obvious, but for completeness:
[12:38]
The MIO number, like MIO 5, is not a physical pin or ball number on the chip.
[12:44]
It is an MIO number that maps to an actual pin or ball that depends on the actual device and physical chip package selected.
[12:51]
This is beyond the scope of the presentation, but it is essentially the same as looking in any datasheet and matching the pin name to the pinball number.
MIO Example: Gigabit Ethernet and USB
[13:02]
With the QSPI example out of the way, let’s look at a Gigabit Ethernet and USB MIO assignment example.
Implementing Gigabit Ethernet (GEM)
[13:12]
Here we return to our trusty MIO table.
[13:16]
In this next example, we’re specifically interested in implementing one of the four Gigabit Ethernet MACs, or GEMs as they’re often referred to.
[13:27]
Let’s focus our attention on GEM 1.
[13:33]
We can tell from the table that GEM 1 can only be assigned to MIO 38 through MIO 49.
[13:42]
So, similarly to the QSPI example, we then refer to the Gigabit Ethernet Controller chapter within that same Technical Reference Manual, and we come across this table.
[13:55]
This defines the MIO function mapping of MIO 38 through MIO 49 to implement GEM 1.
Signal Mapping for GEM
[14:03]
Here we see the typical signals associated with an Ethernet RGMII interface.
[14:09]
We’re still focused on GEM 1 and see the transmit clock is assigned to MIO 38.
[14:15]
Remember, this isn’t pin 38 on the physical package—it is MIO 38, which you then map to a specific ball or pin on the package via the datasheet.
[14:26]
Moving on, we see TX data 0 to 3 is assigned to MIO 39 to 42.
[14:33]
You get the idea.
[14:34]
Don’t forget: With GEMs, you also have to connect the MDIO, which is a management interface to the PHY.
[14:41]
MDIO is comprised of a data and clock link.
[14:44]
Following this table, we can see that if we’re using GEM 1, we can assign MD clock and MD data to either MIO 50 and 51 or MIO 76 and 77.
[14:54]
I would not mix them—that is, I would not assign MD clock to 50 and MD data to 77.
Implementing USB
[15:08]
In this example, we’ll be focused on the USB 0 controller, which will be provisioned on MIO 52 through MIO 63.
[15:18]
Once again, you rely on the Technical Reference Manual by flipping to the USB Controller chapter.
[15:24]
Once within that chapter, we see this table that highlights the different USB controller support.
[15:30]
In this example, we’re going to plan for a USB 3.0 host implementation.
[15:37]
Our approach here is to implement the high-speed, full-speed, and low-speed USB capabilities on the MIO.
[15:46]
And then, necessarily, we have to interface the SuperSpeed capabilities to the Gigabit Transceivers, specifically one of the four PS GTRs.
[16:02]
Here is the mapping table.
[16:04]
Don’t be confused by the ULPI pin column. Since you know that this interface is going to span MIO 52 through MIO 63, you simply follow the second column, same as we’ve done before.
Handling USB Power Faults
[16:19]
But what about monitoring the very common power fault signal related to the 5V bus provision on the USB host interface?
[16:30]
Well, that’s fairly simple—it’s just handled as a GPIO type on the MIO.
Quick Overview of PS GTRs
[16:47]
Since we just spoke about the PS Gigabit Transceivers (GTRs), let’s take a quick peek at how they are assigned.
[16:50]
Here’s the block diagram for the structure of how the PS GTRs on the top right connect to the various high-speed hard controllers within the PS.
[16:59]
Like the MIO, the GTRs are connected through a multiplexing system, which affects the overall assignment flexibility.
[17:08]
Going to the PS GTR chapter within the Technical Reference Manual, we identify this table as critical to our understanding of how to assign the four PS GTRs.
Terminology for PS GTRs
[17:19]
The terminology can cause some confusion, but the four PS GTRs are identified here with the terminology PHY Lane 0 through PHY Lane 3 because they’re contained within a single bank.
[17:31]
But thinking of them as PS GTR0 through PS GTR3 makes it easier.
USB SuperSpeed Example with PS GTRs
[17:38]
Just a second ago, we were discussing USB 3.0 SuperSpeed for the USB 0 controller.
[17:45]
Here, we can tell that we are able to assign the SuperSpeed TX and RX pairs to one of the PS GTR0, GTR1, or GTR2.
[17:54]
It’s important to note that if we were provisioning the other USB controller, named USB 1, our only choice would be to use PS GTR3.
[18:04]
So, that lack of flexibility on USB 1 may cause us to favor using USB 0.
[18:10]
It’s really as simple as that.
Other Supported PS GTR Interfaces
[18:12]
Here are some thoughts on the other supported GTR interfaces:
[18:18]
1. PCIe Version 2.1, root port and endpoint, are supported, as well as x1, x2, or x4 lane widths as per the table.
[18:26]
2. A x4 configuration would leverage all four PS GTRs.
[18:33]
3. All implementations must be matched as per ordinal. For example, PCIe x1 must use PS GTR0, aka PHY Lane 0.
[18:41]
4. Support is limited to PCIe Gen 2 because of the internal controller’s capabilities and the fact that the GTRs only support a maximum of 6 Gbps.
[18:55]
This means that Gen 3, at 8 Gbps, is beyond the reach of the PS GTRs.
[19:02]
5. Previously, we spoke about connecting the Gigabit Ethernet MACs using an RGMII interface via MIO, but you can avoid RGMII.
[19:10]
Instead, use SGMII or 1000 Base-SX or LX by leveraging the PS GTRs.
Common Mistakes with PS GTRs
[19:20]
Perhaps the most common mistake with PS GTRs I’ve seen is when someone tries to use the DisplayPort source interface.
[19:27]
Note the mismatch of ordinals here. For example, DP Lane 1 maps to PHY Lane 0, and DP Lane 0 maps to PHY Lane 1.
[19:36]
Be very cautious with your mapping, especially on this DisplayPort interface.
Clocking Considerations for PS GTRs
[19:43]
And really quick, before we move on to talking about how to power the MIO banks, it’s always important to think about clocking, as these PS GTR interfaces need reference clocks provided as per the AMD table I’m sharing here.
Powering MIO Banks
[20:00]
Let’s now talk about powering MIO.
[20:03]
The MIO pins are organized into three banks: Bank 500, Bank 501, and Bank 502.
[20:09]
Each bank has a dedicated I/O power rail, just like how FPGA banks have VCCO or VCC I/O.
Voltage Rail Assignments
[20:17]
Here’s how to interpret the summary table:
[20:20]
1. MIO pins 0 through 25 are contained within Bank 500 and are powered by the VCC_PS_IO0 voltage rail.
[20:30]
2. MIO pins 26 through 51 are contained within Bank 501 and are powered by the VCC_PS_IO1 voltage rail.
[20:38]
3. Lastly, MIO pins 52 through 77 are contained within Bank 502 and are powered by the VCC_PS_IO2 voltage rail.
Interface Voltage Considerations
[20:49]
The user powers the VCC_PS_IO rails based on the I/O standard they want to support.
[20:55]
It is critical to understand that all MIOs within the bank must use the same I/O standard.
[21:01]
You cannot assign I/O standards pin by pin.
Example of Bank Voltage Assignments
[21:06]
For example, if I power Bank 501 with 1.8 volts, then MIO 26 through MIO 51 must all interface with 1.8-volt compatible devices, as it can only drive at LVCMOS 1.8 levels simultaneously.
[21:23]
I could power Bank 502 with 3.3 volts and use MIO 52 through MIO 77 with 3.3-volt compatible devices.
[21:33]
So as you see, your MIO assignment not only needs to consider function mapping as per the MIO table but must also consider the interface voltage requirements of the external chips you are interfacing to.
Real-World Example: Zynq UltraScale+ Implementation
[21:48]
Putting all of these details together, here’s a schematic snippet from a real-world example of one of our Zynq UltraScale+ implementations.
[22:01]
In this design, you can see some of the most common interfaces assigned to MIO pins.
[22:06]
You can also see, in the top right, the PS GTR assignment in support of USB SuperSpeed.
[22:12]
Lastly, I’ve color-coded the different MIO banks and their associated VCC_PS_IO pins to show you that we are cognizant of the voltage requirements that our different MIO pins were interfacing on.
Voltage Consistency Across Banks
[22:28]
In this design, all MIO banks interface using 3.3 volts.
[22:32]
We have other designs that utilize different bank voltages.
[22:35]
It really depends on the peripherals you’re supporting.
[22:39]
Of course, it’s easier to assign MIO if all three MIO banks utilize the same voltage.
[22:45]
However, often you cannot get away with that.
Brief Overview of EMIO
[22:49]
Before we complete this section of the presentation with some key takeaways, let’s touch very briefly on EMIOs.
[23:00]
The concept of EMIOs, or Extended MIOs, is leveraged when you have run out of physical MIO pins but still want to access a hard peripheral within the PS.
[23:11]
In this case, use an internal connection to connect across the PS-PL boundary to utilize a PL (aka FPGA) pin for connectivity.
[23:22]
This is a powerful capability, but please understand and appreciate the limitations, restrictions, and, in some cases, performance impacts associated with utilizing EMIOs.
Key Takeaways from MIO Design
[23:33]
In the interest of time, I’ll let you digest the contents of this important table on your own.
[23:39]
Now, let’s complete this section with a discussion of the most important items we’ve covered so far.
Summary of Key Points
[23:46]
As we finish up this section, this slide contains a summary of the key elements I hope you took away from this discussion:
1. [23:50] MIO is not nearly as flexible as PL or FPGA GPIO.
2. [23:58] Don’t assume anything—read and understand the documentation.
3. [24:02] MIO control signal mapping can be tricky. Make sure you know what you’re doing.
4. [24:09] As with FPGAs, ensure you have a solid clocking strategy.
5. [24:24] Pay attention to bank voltage when using MIO.
6. [24:30] (We didn’t talk about this, but…) Different PS DDR memory widths are supported by different package types—always be aware of that.
7. [24:39] The Zynq UltraScale+ TRM is the most important document for understanding how to use MIOs.
8. [24:47] A small terminology note: PS I/O and MIO terms are sometimes used interchangeably, but technically, MIO is a subset of a much larger group of PS I/O pins.
[24:58]
This completes this section.
MIO Validation and Tools
[25:01]
Next up: Just like you use tools to verify that your FPGA pinout is valid before committing to hardware, I highly recommend you use the AMD tools to verify that your MIO assignment is correct before committing to hardware.
[25:16]
Jeremy Brooks, one of our Senior Software Designers, will now discuss the tools portion of this note.
[25:22]
Jeremy is a software guy, but FPGA people are equally capable of assessing the planned MIO assignments.
[25:29]
Jeremy, please take it away.
Overview of Tools for MIO Configuration
[25:33]
Thank you, Scott.
[25:33]
My name is Jeremy Brooks, and I am a Senior Embedded Firmware Designer at Fidus Systems.
[25:38]
I’m going to be going over the tools we can use to configure, verify, and implement the MIO on the Zynq UltraScale+ platform.
[25:47]
Let’s start off by looking at how we can configure the MIO using the I/O Configuration Tool located within the Vivado IDE.
Configuring MIO in Vivado
[25:56]
For the purpose of this demonstration, we will be using the ZCU102 reference design as it already has a base MIO configuration.
[26:06]
In order to access the I/O Configuration Tool, what we want to do is open up the block design and then open up the Zynq UltraScale+ block.
[26:19]
Once inside the Zynq UltraScale+ block, we see the I/O Configuration Tool on the left.
Exploring MIO Banks and Voltage Levels
[26:28]
Here, we see that we have the four MIO banks, and we can also set the voltage level for each bank, as Scott previously mentioned.
[26:38]
Down here, we see the hard peripherals and how we configure them.
[26:43]
For instance, for the low-speed peripherals, we can look at memory interfaces.
[26:51]
And here we find the QSPI peripheral.
Configuring QSPI Pins
[26:51]
If we open this up, we see that the QSPI I/O is using MIO 0 through 12, as Scott previously mentioned and as outlined in the MIO table.
[27:03]
Here, we can configure various pins.
Exploring NAND Flash Peripherals
[27:13]
Now, we can look at the NAND Flash hard peripheral.
[27:16]
You see here that it is not enabled.
[27:20]
If we enable the NAND Flash hard peripheral, you’ll see that it comes up in red.
[27:26]
This means that the MIOs that are dedicated to the NAND Flash are being used by another hard peripheral.
[27:33]
In order to use the NAND Flash in this design, we would have to find the peripheral that’s using these pins and disable that peripheral.
[27:41]
For now, we’ll leave it disabled.
I/O Peripheral Configuration
[27:48]
We can go down here and look at I/O peripherals, and here are the hard peripherals that are available.
I²C and UART Examples
[27:56]
For instance, we have two I²C peripherals that are both enabled, using MIO 22 and 23, and MIO 16 and 17.
[28:08]
We also have two UART peripherals enabled, using MIO 18 and 19, and MIO 20 and 21.
Configuring GPIO Pins
[28:19]
Finally, down here, we can see that we have our GPIO peripherals.
[28:26]
Currently, we have three pins dedicated to GPIOs.
[28:29]
These three pins are not being used by other peripherals.
[28:34]
If we want to have more GPIO pins, we need to disable one of the other peripherals.
[28:40]
For instance, I can disable UART 1, and that will free up MIO pins 20 and 21 to be used as GPIO pins, which are fully configurable.
High-Speed Interface Configuration
[28:54]
In this menu, we can also look at the high-speed interfaces.
[29:01]
Much like the low-speed interfaces, we have our GEM Gigabit Ethernet interfaces.
[29:08]
For example, GEM 3 is enabled using MIOs 64 through 75, as well as MIOs 76 and 77.
________________________________________
Conflict Resolution in MIO Configuration
[29:19]
If you see this red conflict view, it means we have a conflict in our MIOs, and we must change our MIO assignments.
[29:28]
If it is not red, then we are free to proceed with our current MIO configuration.
________________________________________
Verification in Vitis IDE
[29:40]
Once we are happy with our MIO configuration using the I/O Configuration Tools, we can build our Vivado project.
[29:47]
We can then use the XSA generated by the Vivado build to verify our MIO configuration using the Vitis IDE.
________________________________________
Using the Vitis IDE for MIO Verification
[29:55]
Let’s now look at how we can use the Vitis IDE to verify our MIO configuration.
[30:03]
Using the XSA file exported from Vivado, I was able to create an MIO test platform project within the Vitis IDE.
[30:14]
Part of this project will include these files pulled from the XSA, including the PSU_init.html file.
________________________________________
Exploring the Summary Report
[30:25]
If I open up this file, I can see the Zynq UltraScale+ summary report of our configurations.
[30:30]
As part of this report is the MIO configurations.
[30:35]
Here, I can select the MIO configurations and see:
• [30:37] What each MIO pin has been assigned to.
• [30:40] Which hardware peripheral it has been assigned to.
• [30:43] Any GPIO pins that are available, including whether they’re pull-ups, pull-downs, in/out pins, CMOS, etc.
[30:53]
Here, we can verify that our MIO configuration is as expected for the requirements of our project.
________________________________________
Accessing MIO in Software
[31:06]
Once we have generated and verified our MIO configuration for our project, we can now look at how we can control the MIO hard peripherals in software.
[31:14]
We will start off by looking at how we can use the MIO pins in a bare-metal Vitis project, including how to access the hard peripherals in software.
[31:23]
We will then look at how we can access the MIO pins in a PetaLinux/Linux project using device trees and standard AMD drivers for each hard peripheral.
________________________________________
Using Bare-Metal Software for MIO
[31:33]
Let’s now look at how a bare-metal software project created within the Vitis IDE can access the MIO.
[31:40]
We will once again use the ZCU102 sample project we previously built in Vivado IDE using the default MIO configurations.
________________________________________
Creating a Platform Project
[31:50]
Here, we have the ZCU102 platform project in Vitis, which was created using the hardware XSA exported from Vivado.
[31:57]
The platform project exposes the hardware to software by providing prebuilt drivers and libraries for interfacing with hardware, including the hardware interface configured in the MIO we can now use.
________________________________________
Developing an Application Project
[32:12]
We can now create an application project that will link into the platform project and provide software with the necessary drivers to control the MIO hard interfaces.
[32:23]
Here, we have a simple “Hello World” project that will write “Hello World” to the UART.
[32:28]
This application will use the prebuilt UART driver to accomplish this task.
________________________________________
Platform Code Details
[32:38]
If we look at the platform.c file, we can see there are macros that configure the hardware based on the prebuilt libraries and drivers.
________________________________________
AMD GitHub Resources
[32:56]
Going to the AMD GitHub repository, we can look at all the libraries and drivers provided for the supported AMD hardware, including the MIO hard interfaces.
[33:12]
For instance, here is the UART PS, which is the UART driver we used in our software application.
[33:22]
Here, they provide:
• Documentation.
• Source for the drivers.
• Examples of how the drivers are used.
________________________________________
Using PetaLinux for MIO Access
[33:31]
Let’s now look at how we can create a Linux/PetaLinux project to access our MIO configurations via software applications.
[33:43]
In this example, we will once again use the ZCU102 default project we previously created in the Vivado IDE.
________________________________________
PetaLinux Project Setup
[33:56]
We use the XSA previously exported from the Vivado project to create our PetaLinux project.
[34:03]
This will import all the libraries and drivers, allowing our software application to use the MIO interfaces.
________________________________________
Device Tree Generation
[34:13]
This is done when PetaLinux automatically creates the device trees.
[34:19]
Each MIO hard interface will have an entry in the device tree.
[34:25]
These device trees associate the basic drivers with each device, allowing software to access the device through the default drivers.
________________________________________
GPIO Access in PetaLinux
[34:38]
In the case of GPIOs, we can use the sysfs interface to access the GPIO.
________________________________________
Conclusion of the Presentation
[34:52]
This concludes our presentation on implementing and optimizing MIO on AMD Zynq UltraScale+ MPSoC and RFSoC platforms.
[35:00]
We hope this webinar provides you with a clearer understanding of how MIO can be used to meet your project requirements.
[35:06]
At this point, I would like to hand back the presentation to Alecia.
________________________________________
35:14 – Closing the Webinar and Q&A Session
Alecia O’Brien:
Welcome everyone to today’s webinar.
Alecia O’Brien:
OK, hello everybody, and thank you for being here. I’m just going to ask Jeremy and Scott to jump onto their camera feed, and we’ll start with the Q&A session.
Alecia O’Brien:
Just a quick reminder to everyone here—if you have any questions you’d like to pose to Scott or Jeremy, please make sure to submit them using the Q&A button at the bottom of your screen.
________________________________________
Alecia O’Brien:
First question here—either of you can answer, if you don’t mind. The question is:
“You mentioned that MIOs are less flexible than PL IO in terms of mapping. Can you elaborate on how one should prioritize or balance the use of hard peripherals versus programmable logic for optimal performance?”
Scott Turnbull:
Yeah, sure, Alecia, I’ll take that one.
So really, I go by my guiding principle, which is to use the PS MIO when you can. If it doesn’t meet your requirements for speed, flexibility, or voltage levels, then I would go to the PL GPIO.
But generally speaking, I always prefer using the PS MIO first, and then I leverage PL GPIO to round out what I’m doing.
Alecia O’Brien:
Excellent. Thank you.

Next question—Given the complexity of the technical reference manual (TRM) you mentioned and other resources, what sections or key tables would you recommend focusing on if I’m a first-time user of Zynq UltraScale+?
Scott Turnbull:
I’ll take that one too.
The TRM is actually really well-organized. Yes, it’s 1,217 pages, but it’s structured by hardware peripheral controllers. For example, there’s a section for the GEM Ethernet controller, a section for the USB controller, and so on.
So, my advice is to start by reading the first few chapters for general context. After that, focus on the chapters specific to the peripherals you’re using. For most first-time users, you’ll probably only need to go through about 200 pages, not the whole manual.
Over time, as you work on more designs, you’ll naturally cover more of the TRM. Don’t let the size intimidate you—it’s very well written, and the key tables in it are essential for mapping and configuration.
Alecia O’Brien:
Thank you for that.
Next question—As projects scale and you require additional peripherals, how can designers plan their initial MIO assignments to allow for future expansion or changes?
Scott Turnbull:
I can take that one as well.
If you load up all your MIO pins early on, you might limit your options for future expansion. Let’s use I²C as an example. You’ve got two I²C controllers: I²C0 and I²C1 within the PS.
What I would do is load up I²C0 as much as possible first. For instance, if I have four devices on my I²C bus, I’d connect them all to I²C0 as long as it meets my requirements. This way, I²C1 remains available for future use.
I wouldn’t split the devices between I²C0 and I²C1 unless absolutely necessary. Keeping one controller free gives you more flexibility for future updates or expansions. Additionally, your software developers will thank you—it’s simpler to work with one controller rather than juggling multiple.
Alecia O’Brien:
Great point. Jeremy, do you have anything to add?
Jeremy Brooks:
No, I think Scott handled that quite well. Thank you.
________________________________________
Alecia O’Brien:
OK, next question—Could you share some examples of projects where optimizing MIO assignments led to significant design or performance improvements?
Jeremy Brooks:
I can handle that one.
I’ve worked on several projects where optimizing the MIO configuration was key to meeting system requirements. One example was a design where we needed to enable a QSPI harness configured through I²C. We couldn’t use the standard I²C bus, so we mapped the signals through MIO to achieve the required flexibility and performance.
Another example involved a board where both QSPI and NAND Flash were needed simultaneously. We had to carefully adjust the MIO assignments, disabling some lower-priority peripherals to make room for these critical interfaces.
Ultimately, the flexibility of MIO mapping allows us to adapt to project needs while ensuring performance and reliability.
Alecia O’Brien:
Thank you, Jeremy. That’s a great example.
________________________________________
Alecia O’Brien:
It looks like we don’t have any more questions at this time. So, we’ll wrap things up here.
Thank you, Scott and Jeremy, for your time and expertise today. I hope everyone found this session valuable.
We’ll be sharing the recording on our website shortly. If you have additional questions or would like to discuss starting your project with Zynq UltraScale+—or even migrating from Zynq to Versal—visit our website at fidus.com and fill out the contact form. One of our experts will follow up with you promptly.
Thanks again, everyone, and have a great day!