In this project I will show how to create a Vivado project for the Zynq Ultrascale+ MPSoC using the the MYD-CZU3EG FPGA development board that will be the base for further software development and Linux development. The focus of this project is the configuration of the PS block, selecting the connections and configuration for all peripherals presents in the selected board.

The Board

MYIR recently released the v3 of their popular series of modules and development boards around the Zynq Ultrascale+ MPSoC. The SOM modules are compact PCBs with 2 Samtec high density 160-pin connectors for I/O. They can assemble the XCZU3EG, XCZU4EV or XCZU5EV FPGA in SFVC784 package.

The developer will rather go for a development board where the SOM is mounted on a carrier board offering a number of common interfaces like USB, FMC, SFP, PMOD, LCD, SDcard, SATA, HDMI, DisplayPort, Ethernet, etc. The carrier board (MYD) is compatible with all SOM modules (MYC).

MYD-CZU3EG (fan detached)

Not shown in the picture above, but the development board is equipped with a fan over the FPGA that is necessary when running heavy loads.

MYIR is an Elite AMD Embedded Partner and a manufacturer of CPU and FPGA boards for over a decade. I have been using their FPGA boards for years with an excellent result.

Software used in this project

Vivado 2024.2 running on Ubuntu 2024.4 will be used in this case, although adapting it for other release or on Windows shouldn’t be difficult. Usually AMD FPGA developers use various tools like Vivado, Vitis (for software development), Vitis HLS, Petalinux, etc. In this case, only Vivado will be needed.

Any Linux development (for example with Petalinux) requires a Linux host machine. While it is possible to have all other tools in a Windows machine, eventually it becomes convenient to have all the tools in a Linux machine. If you don’t have a dedicated Linux PC, a Virtual machine (like VitualBox) will do the job. I use VirtualBox 7.1.6 for development on Linux.

I assume that you have Vivado installed. If not, you can download it from the AMD site.

Starting a Vivado project for the MYD-CZU3EG

Start Vivado either by double clicking on the desktop icon or via the terminal, then click on Create Project:

On the screen that opens, click Next then enter the project name and location. It’s convenient to leave the Create project subdirectory ticked.

Click Next and leave the RTL project option ticked:

Click Next. For the next two windows (Add sources and Add constraints) also click Next. On the Default part screen, start typing **xczu3eg **and browse until you find the exact part xczu3eg-sfvc784-1-i

The explanation of the part number is:

XCZU is the Zynq Ultrascale+ MPSoC3EG is the modelSFVC784 is the chip package1 is the speed grade (1 to 3, 3 being the fastest)I is the temperature range (industrial)

Click Next. Review the Project Summary and click Finish.

Vivado creates an empty project. On the Flow Navigator pane (left), click on Create Block Design.

In the dialog that appears, you could leave the default name (design_1) but I chose bd (for block diagram)

Note that on the Flow Navigator panel the IP integrator headline is highlighted. We have now a diagram where we can drop IP blocks that we could connect graphically, although in this case it will be just one.

Click on the + symbol either on the center of the diagram or the bar above

Browse for Zynq Ultrascale+ MPSoC. It helps typing something like mpso to help find it

Double click on the selection and it will appear on the diagram

However, the PS IP has many things to configure and this has to be done for every board as it depends on the external connections. Thankfully, PS configurations can be saved and reused in future projects.

By double clicking on the PS IP, the configuration GUI opens:

I/O configuration

Click on the I/O configuration. The first thing to assign is the MIO banks voltages. The PS has a number of IO called MI (Multiplexed I/O) spread over 4 banks. In this case, the MYD-CZU3EG board has all banks at 1V8.

On the Low Speed, Memory interfaces, the board has a dual parallel QSPI memory in x4 data mode and connected to MIO0..12

There is no NAND memory but there are two SD peripherals. SD0 is an 8-bit eMMC, connected to MIO13..22 with Reset on MIO23:

SD1 is an SD 2.0 peripheral in 4-bit mode, connected to MIO46..51. CD (Card Detect) is on MIO45 and WP (Write Protect) on MIO44

CAN 0 is connected to EMIO, as well as I2C 0. The other I2C peripheral is on MIO24..25 as it is used to set some on-board oscillators.

The following peripherals (PJTAG, PMU, CSU and SPI) are not used in this base application an are left unticked

Next, the essential Uart0 is connected to MIO34..35. Uart 1 is unused.

For the GPIO, all EMIO (95) as well as all GPIO MIO can be enabled. MIO assigned to peripherals take preference, so only those unassigned can be used as GPIO MIO.

Peripherals on the Processing Unit section can be left unselected for this base application.

On the High Speed interfaces, GEM 3 (Gigabit Ethernet Module) is connected to MIO 64..75 and the MDIO 3 to MIO 76..77

On the USB section, USB 0 is connected to MIO52..63, and USB 3.0 option selected using GTLane 2. USB Reset is Boot Pin.

PCIe is configured using GTLane 0 and Endpoint Reset on MIO31.

Display Port is assigned GTLane 3, and MIO 27..30 for DPAUX signals.

On the SATA interfaces, SATA Lane 1 is assigned the remaining GTLane1

Finally, Reference Clocks can be left unassigned.

Clock Configuration

The input frequency is 33.3333333 MHz, and the reference frequencies for High Speed peripherals are as below:

On the Output Clocks tab, they all should be automatically set. Do a quick check that the Actual Frequency column matches the Requested Frequency.

DDR configuration

The DDR configuration must agree with the DDR chip installed. The MYD-CZU3EG has 4x DDR4-2400 1 GB x16 memory chips and are configured as below.

The Other Options at the bottom can be left as their default:

PS-PL configuration

In this section, because we are building a base for software development, it can be left with all peripherals unselected.

Finally click OK. A check is done and you should have no errors. The appearance of the PS IP block changes according to the settings applied:

Double click again on the PS block and this time select Presets and Save configuration.

Choose a name for the configuration and a file name to save it. The extension is tcl. This configuration will now be available to be applied to new projects.

Build the RTL project

Save the block diagram with CTRL+S or File > Save Block Design. On the Sources tab next to the Block Diagram, right click on the block diagram (bd) and select Create HDL wrapper.

This is because Vivado needs an HDL file (VHDL or Verilog) at the top of the hierarchy. Leave the selected option on for Vivado to manage it.

Note how the bd_wrapper file appears and the block diagram bd is now hierarchically below.

Close the Block Design section to return to the initial Project Manager. Now you can either click Run Synthesis, then Run Implementation and finally Generate Bitstream or just the las one as it will do the others automatically.

It should take a couple of minutes and produce something similar to the screen below. Warnings are fine (Critical warnings, however, are not!).

Export hardware

After a succesful build and generation of the bitstream, the last step with Vivado is to export the hardware as XSA (Xilinx Support Archive) that will be used with Vitis or Petalinux to develop software.

To do this, click on File > Export > Export Hardware:

Click Next on the first dialog and select Include Bitstream on the next one. On the next window, select a file name and location. The Vivado project folder is already appropriate.

Click Next and Finish.

Check by browsing on the project folder that the XSA has been created:

As well as the configuration:

The PS configuration is a readable (and editable) text file, try opening it:

What next?

Although for different projects you may need different configurations, creating and using a base configuration is a good thing to do. You will be trying something simple, so there will be less things that could go wrong, and those going wrong will likely be identified quicker.

In future projects, I will use the generated XSA for baremetal and Linux software creation.