Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ES/Getting_Started: Update README #451

Merged
merged 1 commit into from
Jul 22, 2024
Merged

ES/Getting_Started: Update README #451

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Embedded_Software/Getting_Started/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ From the Welcome Screen, users can select the Create Platform Component under Em

Before we proceed, let’s discuss what we actually need to both boot and deploy our user application on the development board.

For example, let’s take the Zynq UltraScale. This device consists of a Processor Subsystem Unit (PSU) and Programmable Logic (PL). When users exported the hardware in Vivado, this created an XSA file. This XSA file is a container file that contains (amongst other files) the PSU config files; `psu_init.c` and `.h` files that are generated when you generate the Output Products in Vivado. These files are used by the First Stage BootLoader (FSBL) to config the PSU. There may also a bitstream (if included when exporting the hardware), this is used to config the PL. There is also the metadata about our block design, IP enabled in the PSU, IP in the PL and how each of these IP are configured called cell properties. This metadata can be extracted by the Vitis Unified tool to tailor a software system that is based on the hardware created in Vivado. In summary, to boot (either in JTAG, SD card or otherwise) we need to program the PSU. The PSU is programmed via the FSBL. If the PL needs to be programmed (optional), this is done via the bitstream. In the Vitis Unified tool, users can create these files by using the Create Platform Component.
For example, let’s take the Zynq UltraScale. This device consists of a Processor Subsystem Unit (PSU) and Programmable Logic (PL). When users exported the hardware in Vivado, this created an XSA file. This XSA file is a container file that contains (amongst other files) the PSU config files; `psu_init.c` and `.h` files that are generated when you generate the Output Products in Vivado. These files are used by the First Stage BootLoader (FSBL) to config the PSU. There may also be a bitstream (if included when exporting the hardware), this is used to config the PL. There is also the metadata about our block design, IP enabled in the PSU, IP in the PL and how each of these IP are configured called cell properties. This metadata can be extracted by the Vitis Unified tool to tailor a software system that is based on the hardware created in Vivado. In summary, to boot (either in JTAG, SD card or otherwise) we need to program the PSU. The PSU is programmed via the FSBL. If the PL needs to be programmed (optional), this is done via the bitstream. In the Vitis Unified tool, users can create these files by using the Create Platform Component.

For Versal, the Platform Loader Manager (PLM) is created in Vivado and is packaged into a Programmable Definition Image (PDI) in Vivado and this PDI is added to the XSA file. So, users do not need to build boot artifacts in the Vitis IDE

Expand Down