Uploaded
↧
bd_net.png
↧
device_info.png
Uploaded
↧
↧
HSI debugging and optimization techniques
In this tutorial we shall discuss how, and where the HSI utility is used to extract the HW information from the HDF. We shall discuss how to debug potential issues arising in the HSI. Finally, we will discuss how users can utilize the HSI in order to
automate application development.
What is the HSI:
In order to build a targeted platform for a device, whether it be baremetal or Kernel, then the tools need to be aware of the hardware system. The Xilinx tools such as SDK, and Petalinux use a set of TCL based utilities called
Hardware Software Interface (HSI) to obtain this information. In this tutorial, we shall explore these HSI API, and how these are used to build the BSP, and devicetree in Linux.
The hardware that we will use in this demo is shown below. This was created in Vivado IP Integrator 2018.1. The Block Design (BD) is seen below
{block_design.png}
For more information on the Embedded flow within Vivado, see the guide here
The Hardware Definition File (HDF):
The HDF (Hardware Definiton File) is a container file that contains all the information needed to build a platform for my target device. One of the files here is the Hardware Handoff File (HWH) .This HWH file is created when the output products is ran on a Block Design (BD). Only the information in the Block Design (BD) will be contained in the HWH. The HWH file is used by the software tools to abstract all the information needed to build a targeted application to my device; such as the CPU (or CPUs), Buses, IP and the ports and pins used in the system such as interrupts. Since I am targeting a Zynq Ultrascale here, the HDF will also contain the psu_init.c/h, and tcl files. The psu_init.c/h files are used in the FSBL to configure the Processing Subsystem with the configuration I set in the IP configuration wizard in Vivado. The psu_init.tcl is used by the debugger to perform the same task. There is also psu_init_gpl.c/h if users want to config the PSU in uboot. If users have an address mapped BRAM system in the PL, or the FPGA for non SoC devices, then there would be an MMI file that would be used in Updatemem to populate the BRAM with my ELF created in SDK.
Xilinx Software Commandline Tool (XSCT):
We shall be using the Xilinx Software Commandline Tool (XSCT) to explore the HDF file. The XSCT is delivered with SDK, and is an ‘umbrella’ tool that covers; HSI, XSDK, Bootgen, and the debugger. Which means that everything we can achieve in the SDK tool, can be achieved on the command line too. This is very useful for users that wish to automate the process. In this tutorial we will be using the HSI API to open and explore the HWH information in the HDF. The HSI is a TCL based utility that is used over a broad section of the Xilinx tools. For example, it is used to create the Standalone BSP in SDK.
Below we can see a screenshot of the SDK install. Here, the standalone.tcl file is used to create the BSP. The entry point being the generate proc in this TCL file:
{standalone.png}
The HSI is also used in all the drivers, and libraries delivered in the SDK tool too. For example, the LwIP library delivered in the SDK is the open source LwIP library that has a port (wrapper), that will be tailored to work on your target device. The LwIP uses the HSI API to abstract this hardware information; such as the Ethernet IP, timer, and interrupt connections in the system to populate the port information. The HSI API is also used in the devicetree generator in Petalinux to populate the devidetree for the linux kernel.
So, as we can see the HIS API is used in a lot of places in the Xilinx tools, so it is importand that users be aware of how this is works, and how to fix or patch any issues that might arise here.
Extracting HW info using HSI from the XSCT command line:
To see a list of all the HSI API, users can use the help:
help -category hsi
So, let’s launch the XSCT and explore the HDF.
hsi::open_hw_design design_1_wrapper.hdf
Note: I am using the his:: prefix as I am calling the his command from the XSCT. This is not needed if I call this natively from his.
We can look at all the IP in the HWH:
hsi::get_cells *
Note: Here, I am using the * wildcard.
If I want to return the properties of a certain IP. I can use the command below:
common::report_property [hsi::get_cells axi_timer_0]
Note: Here, the common:: prefix is used, as the report_property command is not specific to HIS. This would be the same for get_property, list_property and set_property. This will return the following:
{properties.png}
We can use the information here to filter our search. For example, if I just want to return the processors in the HWH:
hsi::get_cells * -filter {IP_TYPE==PROCESSOR}
The same approach can be used to find pins in the HWH:
hsi::get_pins *
If I want to return all the pins on a certain IP. I can use the -of_objects switch:
hsi::get_pins -of_objects [hsi::get_cells axi_timer_0]
Again, we can filter here so that only interrupt pins are returned on the axi_timer_0 IP:
hsi::get_pins -of_objects [hsi::get_cells axi_timer_0] -filter {TYPE==INTERRUPT}
Users can also get all the slaves of a processor from the HWH:
hsi::get_mem_ranges -of_objects [lindex [hsi::get_cells * -filter {IP_TYPE==PROCESSOR}] 0]
Internal HSI utilities:
There are also some HSI utilities that is used by the SDK that use these API on the back-end that users would need to be aware of if attempting to debug HSI issues. The user can source these tcl scripts, and utilize them in their own scripts. These HSI utils can be found in the SDK install:
{hsi_utils.png}
For example, a useful utility here is ::hsi::utils::get_sink_pins. This can be used to find all the pins connected to another pin. For example, if users want to see where the interrupt port on s particular IP is connected to:
{bd_net.png}
Using these utilities is particularly useful when attempting to isolate issues relating to the BSP generation in SDK. For example, let’s imagine that there is an issue in the BSP containing the LwIP library. Here, we can source the utilities from the SDK install, and source the
LwIP TCL, and execute the procs within this LwIP TCL in order to narrow down on the root cause of the BSP generation failure. For example, here I have run the get_emac_periphs proc within the lwip tcl:
source <path to SDK install>/scripts/hsm/xillib_hw.tcl
source <path to SDK install>/data/embeddedsw/ThirdParty/sw_services/lwip202_v1_1/data/lwip202.tcl
get_emac_periphs [hsi::get_cells psu_cortexa53_0]
Using the HSI to create software applications:
There are HSI API that users can use to create software applications. Users can use the templates such as zynqmp_fsbl, hello_world ect similar to how this can be acheived in the SDK GUI to create applications on the commandline.
For example, to create a ZynqMP FSBL the command is:
hsi::generate_app -app zynqmp_fsbl -proc cortexa53_0 -dir zynqmp_fsbl -os standalone -compile
Use the command below to get a list of all the supported templates:
hsi::generate_app -lapp
Utilizing the HSI to automate boot image creation:
The HSI can also be used to automate the application creation based upon the hardware. Taking the Hardware design above, we can use the HSI to do the following information in order to automate the boot image creation.
Determine the device family
Determine the target platform (ie if xilinx development board)
Determine the configuration of the PSU to determine the bootmode
Determine the serial port
Create the FSBL targeting the SoC processor
Create the PMUFW if the Zynq Ultrascale device is detected
Create the BIF file specific to target device.
Using the hardware design above, here we can extract the hardware device information:
{device_info.png}
For example, users can create a proc to extract the family information:
proc get_device_family {} {
return [common::get_property FAMILY [hsi::current_hw_design]]
}
Users can extract the processor info:
proc get_processor {} {
set processor [hsi::get_cells * -filter {IP_TYPE==PROCESSOR}]
if {[llength $processor] != 0} {
return $processor
}
return 0
}
We can see if a serial port is used. Here, I just return the first one found. If users want to use this, then some modification may need to be taken here:
proc get_serial {} {
set uart [hsi::get_cells *uart*]
if {[llength $uart] != 0} {
return 1
}
return 0
}
We can determine if the SD controller is enabled.
proc get_sd {} {
set psu_sd [hsi::get_cells * -filter {IP_NAME==psu_sd}]
if {$psu_sd != ""} {
return 1
}
return 0
}
We can also check if the target device is on a development board. This would be needed for example if we are using a ZCU102, to reset the PHY on board via the FSBL:
proc is_development_board {} {
set board [common::get_property BOARD [hsi::current_hw_design]]
if {$board != ""} {
return [lindex [split $board ":"] 1]
}
return 0
}
We can check if there is any IP in the Programmable Logic (PL);
proc get_pl_ip {} {
set pl_ip [hsi::get_cells * -filter {IS_PL==1}]
if {$pl_ip != ""} {
return 1
}
return 0
}
We can use this device information to dynamically create the BIF image needed to create the boot image:
We can also check if there should be a bit file or not based on the fact if there is any IP in the PL.
proc create_bif {apps} {
foreach app $apps {
if {$app == "zynqmp_fsbl"} {
set fsbl "${app}/executable.elf"
} elseif {$app == "pmu_fw"} {
set pmufw "${app}/executable.elf"
}
}
set bit [glob -nocomplain -directory [pwd] *.bit]
if {$bit == "" && [get_pl_ip] == 1} {
puts "Warning, there is IP detected in the PL. However, there is no bitstream detected"
}
set fileId [open bootgen.bif "w"]
puts $fileId "the_ROM_image:"
puts $fileId "{"
if {[get_device_family] == "zynquplus"} {
puts $fileId "\[fsbl_config\] a53_x64"
}
puts $fileId "\[bootloader\] $fsbl"
if {[get_device_family] == "zynquplus"} {
puts $fileId "\[pmufw_image\] $pmufw"
}
if {$bit != ""} {
puts $fileId "\[destination_device=pl\] $bit"
}
puts $fileId "}"
close $fileId
puts "BIF file created successfully"
}
Finally, we can create a proc that will use all this information to create a boot image:
proc create_boot {hdf} {
set apps ""
open_hwh design_1_wrapper.hdf
if {[get_device_family] == "zynquplus"} {
if {[get_serial] == 1 && [get_sd] == 1} {
hsi::generate_app -app zynqmp_pmufw -proc [lindex [get_processor] 6] -dir pmu_fw -compile
lappend apps "pmu_fw"
if {[regexp {zcu102} [is_development_board]] == 1} {
set fsbl_design [hsi::create_sw_design fsbl_1 -proc [lindex [get_processor] 0] -app zynqmp_fsbl]
common::set_property APP_COMPILER "aarch64-none-elf-gcc" $fsbl_design
common::set_property -name APP_COMPILER_FLAGS -value "-DRSA_SUPPORT -DFSBL_DEBUG_INFO -DXPS_BOARD_ZCU102" -objects $fsbl_design
hsi::generate_app -dir zynqmp_fsbl -compile
lappend apps "zynqmp_fsbl"
} else {
hsi::generate_app -app zynqmp_fsbl -proc [lindex [get_processor] 0] -dir zynqmp_fsbl -compile
lappend apps "zynqmp_fsbl"
}
}
create_bif $apps
if {[file exists bootgen.bif] == 1} {
exec bootgen -arch zynqmp -image bootgen.bif -o i BOOT.BIN -w on
} else {
puts "BIF file not created!"
}
}
close_hwh
}
Related Links
Generating Hardware Platforms from HSI
Vivado Embedded Guide
automate application development.
What is the HSI:
In order to build a targeted platform for a device, whether it be baremetal or Kernel, then the tools need to be aware of the hardware system. The Xilinx tools such as SDK, and Petalinux use a set of TCL based utilities called
Hardware Software Interface (HSI) to obtain this information. In this tutorial, we shall explore these HSI API, and how these are used to build the BSP, and devicetree in Linux.
The hardware that we will use in this demo is shown below. This was created in Vivado IP Integrator 2018.1. The Block Design (BD) is seen below
{block_design.png}
For more information on the Embedded flow within Vivado, see the guide here
The Hardware Definition File (HDF):
The HDF (Hardware Definiton File) is a container file that contains all the information needed to build a platform for my target device. One of the files here is the Hardware Handoff File (HWH) .This HWH file is created when the output products is ran on a Block Design (BD). Only the information in the Block Design (BD) will be contained in the HWH. The HWH file is used by the software tools to abstract all the information needed to build a targeted application to my device; such as the CPU (or CPUs), Buses, IP and the ports and pins used in the system such as interrupts. Since I am targeting a Zynq Ultrascale here, the HDF will also contain the psu_init.c/h, and tcl files. The psu_init.c/h files are used in the FSBL to configure the Processing Subsystem with the configuration I set in the IP configuration wizard in Vivado. The psu_init.tcl is used by the debugger to perform the same task. There is also psu_init_gpl.c/h if users want to config the PSU in uboot. If users have an address mapped BRAM system in the PL, or the FPGA for non SoC devices, then there would be an MMI file that would be used in Updatemem to populate the BRAM with my ELF created in SDK.
Xilinx Software Commandline Tool (XSCT):
We shall be using the Xilinx Software Commandline Tool (XSCT) to explore the HDF file. The XSCT is delivered with SDK, and is an ‘umbrella’ tool that covers; HSI, XSDK, Bootgen, and the debugger. Which means that everything we can achieve in the SDK tool, can be achieved on the command line too. This is very useful for users that wish to automate the process. In this tutorial we will be using the HSI API to open and explore the HWH information in the HDF. The HSI is a TCL based utility that is used over a broad section of the Xilinx tools. For example, it is used to create the Standalone BSP in SDK.
Below we can see a screenshot of the SDK install. Here, the standalone.tcl file is used to create the BSP. The entry point being the generate proc in this TCL file:
{standalone.png}
The HSI is also used in all the drivers, and libraries delivered in the SDK tool too. For example, the LwIP library delivered in the SDK is the open source LwIP library that has a port (wrapper), that will be tailored to work on your target device. The LwIP uses the HSI API to abstract this hardware information; such as the Ethernet IP, timer, and interrupt connections in the system to populate the port information. The HSI API is also used in the devicetree generator in Petalinux to populate the devidetree for the linux kernel.
So, as we can see the HIS API is used in a lot of places in the Xilinx tools, so it is importand that users be aware of how this is works, and how to fix or patch any issues that might arise here.
Extracting HW info using HSI from the XSCT command line:
To see a list of all the HSI API, users can use the help:
help -category hsi
So, let’s launch the XSCT and explore the HDF.
hsi::open_hw_design design_1_wrapper.hdf
Note: I am using the his:: prefix as I am calling the his command from the XSCT. This is not needed if I call this natively from his.
We can look at all the IP in the HWH:
hsi::get_cells *
Note: Here, I am using the * wildcard.
If I want to return the properties of a certain IP. I can use the command below:
common::report_property [hsi::get_cells axi_timer_0]
Note: Here, the common:: prefix is used, as the report_property command is not specific to HIS. This would be the same for get_property, list_property and set_property. This will return the following:
{properties.png}
We can use the information here to filter our search. For example, if I just want to return the processors in the HWH:
hsi::get_cells * -filter {IP_TYPE==PROCESSOR}
The same approach can be used to find pins in the HWH:
hsi::get_pins *
If I want to return all the pins on a certain IP. I can use the -of_objects switch:
hsi::get_pins -of_objects [hsi::get_cells axi_timer_0]
Again, we can filter here so that only interrupt pins are returned on the axi_timer_0 IP:
hsi::get_pins -of_objects [hsi::get_cells axi_timer_0] -filter {TYPE==INTERRUPT}
Users can also get all the slaves of a processor from the HWH:
hsi::get_mem_ranges -of_objects [lindex [hsi::get_cells * -filter {IP_TYPE==PROCESSOR}] 0]
Internal HSI utilities:
There are also some HSI utilities that is used by the SDK that use these API on the back-end that users would need to be aware of if attempting to debug HSI issues. The user can source these tcl scripts, and utilize them in their own scripts. These HSI utils can be found in the SDK install:
{hsi_utils.png}
For example, a useful utility here is ::hsi::utils::get_sink_pins. This can be used to find all the pins connected to another pin. For example, if users want to see where the interrupt port on s particular IP is connected to:
{bd_net.png}
Using these utilities is particularly useful when attempting to isolate issues relating to the BSP generation in SDK. For example, let’s imagine that there is an issue in the BSP containing the LwIP library. Here, we can source the utilities from the SDK install, and source the
LwIP TCL, and execute the procs within this LwIP TCL in order to narrow down on the root cause of the BSP generation failure. For example, here I have run the get_emac_periphs proc within the lwip tcl:
source <path to SDK install>/scripts/hsm/xillib_hw.tcl
source <path to SDK install>/data/embeddedsw/ThirdParty/sw_services/lwip202_v1_1/data/lwip202.tcl
get_emac_periphs [hsi::get_cells psu_cortexa53_0]
Using the HSI to create software applications:
There are HSI API that users can use to create software applications. Users can use the templates such as zynqmp_fsbl, hello_world ect similar to how this can be acheived in the SDK GUI to create applications on the commandline.
For example, to create a ZynqMP FSBL the command is:
hsi::generate_app -app zynqmp_fsbl -proc cortexa53_0 -dir zynqmp_fsbl -os standalone -compile
Use the command below to get a list of all the supported templates:
hsi::generate_app -lapp
Utilizing the HSI to automate boot image creation:
The HSI can also be used to automate the application creation based upon the hardware. Taking the Hardware design above, we can use the HSI to do the following information in order to automate the boot image creation.
Determine the device family
Determine the target platform (ie if xilinx development board)
Determine the configuration of the PSU to determine the bootmode
Determine the serial port
Create the FSBL targeting the SoC processor
Create the PMUFW if the Zynq Ultrascale device is detected
Create the BIF file specific to target device.
Using the hardware design above, here we can extract the hardware device information:
{device_info.png}
For example, users can create a proc to extract the family information:
proc get_device_family {} {
return [common::get_property FAMILY [hsi::current_hw_design]]
}
Users can extract the processor info:
proc get_processor {} {
set processor [hsi::get_cells * -filter {IP_TYPE==PROCESSOR}]
if {[llength $processor] != 0} {
return $processor
}
return 0
}
We can see if a serial port is used. Here, I just return the first one found. If users want to use this, then some modification may need to be taken here:
proc get_serial {} {
set uart [hsi::get_cells *uart*]
if {[llength $uart] != 0} {
return 1
}
return 0
}
We can determine if the SD controller is enabled.
proc get_sd {} {
set psu_sd [hsi::get_cells * -filter {IP_NAME==psu_sd}]
if {$psu_sd != ""} {
return 1
}
return 0
}
We can also check if the target device is on a development board. This would be needed for example if we are using a ZCU102, to reset the PHY on board via the FSBL:
proc is_development_board {} {
set board [common::get_property BOARD [hsi::current_hw_design]]
if {$board != ""} {
return [lindex [split $board ":"] 1]
}
return 0
}
We can check if there is any IP in the Programmable Logic (PL);
proc get_pl_ip {} {
set pl_ip [hsi::get_cells * -filter {IS_PL==1}]
if {$pl_ip != ""} {
return 1
}
return 0
}
We can use this device information to dynamically create the BIF image needed to create the boot image:
We can also check if there should be a bit file or not based on the fact if there is any IP in the PL.
proc create_bif {apps} {
foreach app $apps {
if {$app == "zynqmp_fsbl"} {
set fsbl "${app}/executable.elf"
} elseif {$app == "pmu_fw"} {
set pmufw "${app}/executable.elf"
}
}
set bit [glob -nocomplain -directory [pwd] *.bit]
if {$bit == "" && [get_pl_ip] == 1} {
puts "Warning, there is IP detected in the PL. However, there is no bitstream detected"
}
set fileId [open bootgen.bif "w"]
puts $fileId "the_ROM_image:"
puts $fileId "{"
if {[get_device_family] == "zynquplus"} {
puts $fileId "\[fsbl_config\] a53_x64"
}
puts $fileId "\[bootloader\] $fsbl"
if {[get_device_family] == "zynquplus"} {
puts $fileId "\[pmufw_image\] $pmufw"
}
if {$bit != ""} {
puts $fileId "\[destination_device=pl\] $bit"
}
puts $fileId "}"
close $fileId
puts "BIF file created successfully"
}
Finally, we can create a proc that will use all this information to create a boot image:
proc create_boot {hdf} {
set apps ""
open_hwh design_1_wrapper.hdf
if {[get_device_family] == "zynquplus"} {
if {[get_serial] == 1 && [get_sd] == 1} {
hsi::generate_app -app zynqmp_pmufw -proc [lindex [get_processor] 6] -dir pmu_fw -compile
lappend apps "pmu_fw"
if {[regexp {zcu102} [is_development_board]] == 1} {
set fsbl_design [hsi::create_sw_design fsbl_1 -proc [lindex [get_processor] 0] -app zynqmp_fsbl]
common::set_property APP_COMPILER "aarch64-none-elf-gcc" $fsbl_design
common::set_property -name APP_COMPILER_FLAGS -value "-DRSA_SUPPORT -DFSBL_DEBUG_INFO -DXPS_BOARD_ZCU102" -objects $fsbl_design
hsi::generate_app -dir zynqmp_fsbl -compile
lappend apps "zynqmp_fsbl"
} else {
hsi::generate_app -app zynqmp_fsbl -proc [lindex [get_processor] 0] -dir zynqmp_fsbl -compile
lappend apps "zynqmp_fsbl"
}
}
create_bif $apps
if {[file exists bootgen.bif] == 1} {
exec bootgen -arch zynqmp -image bootgen.bif -o i BOOT.BIN -w on
} else {
puts "BIF file not created!"
}
}
close_hwh
}
Related Links
Generating Hardware Platforms from HSI
Vivado Embedded Guide
↧
hsi_script.zip
Uploaded
↧
HSI debugging and optimization techniques
...
order toautomate application development.
What is the HSI:
...
utilities calledHardware
Hardware Software Interface
...
in Linux.The hardware that we will use in this demo is shown below. This was created in Vivado IP Integrator 2018.1. The Block Design (BD) is seen below
{block_design.png}
...
To see a list of all the HSI API, users can use the help:help -category hsi
...
explore the hsi::open_hw_design design_1_wrapper.hdf
Note: I am using the his:: prefix as I am calling the his command from the XSCT. This is not needed if I call this natively from his.
We can look at all the IP in the HWH:
hsi::get_cells *
...
* wildcard.If I want to return the properties of a certain IP. I can use the command below:
common::report_property [hsi::get_cells axi_timer_0]
...
For example, a useful utility here is ::hsi::utils::get_sink_pins. This can be used to find all the pins connected to another pin. For example, if users want to see where the interrupt port on s particular IP is connected to:{bd_net.png}
...
source theLwIP TCL, and execute the procs within this LwIP TCL in order to narrow down on the root cause of the BSP generation failure. For example, here I have run the get_emac_periphs proc within the lwip tcl:
source <path to SDK install>/scripts/hsm/xillib_hw.tcl
...
get_emac_periphs [hsi::get_cells psu_cortexa53_0]Using the HSI to create software applications:
...
the commandline.For
For example, to
...
FSBL the HSI command is:hsi::generate_app -app zynqmp_fsbl -proc cortexa53_0 -dir zynqmp_fsbl -os standalone -compile
Use the command below to get a list of all the supported templates:
hsi::generate_app -lapp
Users can also change the compiler options. For example, in the FSBL if users are targetting the ZCU102 development board, then the XPS_BOARD_ZCU102 symbol should be passed to the compiler as there is some board specicif configuration
in the fsbl for the zcu102/6 boards. This would look like:
set fsbl_design [hsi::create_sw_design fsbl_1 -proc [lindex [get_processor] 0] -app zynqmp_fsbl]
common::set_property APP_COMPILER "aarch64-none-elf-gcc" $fsbl_design
common::set_property -name APP_COMPILER_FLAGS -value "-DRSA_SUPPORT -DFSBL_DEBUG_INFO -DXPS_BOARD_ZCU102" -objects $fsbl_design
hsi::generate_app -dir zynqmp_fsbl -compile
Note: Users can also use the SDK batch mode commands. The difference being that the SDK batch mode commands will create an eclipse workspace. Using the SDK batch mode commands would be more useful than HSI generate apps if the user plans to debug the applications in the SDK GUI.
Utilizing the HSI to automate boot image creation:
The HSI can also be used to automate the application creation based upon the hardware. Taking the Hardware design above, we can use the HSI to do the following information in order to automate the boot image creation.
...
return 0}
...
is enabled.proc get_sd {} {
set psu_sd [hsi::get_cells * -filter {IP_NAME==psu_sd}]
...
close_hwh}
The script that I used here can be downloaded from here:
{hsi_script.zip}
Related Links
Generating Hardware Platforms from HSI
↧
↧
HSI debugging and optimization techniques
In this tutorialarticle we shall discuss how,the hardware hand-off (HWH) between Vivado, and where the HSI utility is used to extract the HW information from the HDF.SDK, or Petalinux. We shall discuss how this is achieved, and from this understanding allow users to debug potential issues arisingthat may arise in the HSI.this hand-off. Finally, weusers canto utilize the HSIthese hand-off features in order to
automatedevelopment.of targeted applications for users hardware devices or platforms using HSI.
What is the HSI:
In order to build a targeted platform for a device, whether it be baremetal or Kernel, then the tools need to be aware of the hardware system. The Xilinx tools such as SDK, and Petalinux use a set of TCL based utilities called
Using the HSI to create software applications:
For example, to create a ZynqMP FSBL the HSI command is:
hsi::generate_app -app zynqmp_fsbl -proc cortexa53_0 -dir zynqmp_fsbl -os standalone -compile
Use the command below to get a list of all the supported templates:
hsi::generate_app -lapp
in the fsbl for the zcu102/6 boards. This would look like:
set fsbl_design [hsi::create_sw_design fsbl_1 -proc [lindex [get_processor] 0] -app zynqmp_fsbl]
...
discuss how automate
What is the HSI:
In order to build a targeted platform for a device, whether it be baremetal or Kernel, then the tools need to be aware of the hardware system. The Xilinx tools such as SDK, and Petalinux use a set of TCL based utilities called
...
get_emac_periphs [hsi::get_cells psu_cortexa53_0]Using the HSI to create software applications:
...
the commandline.For example, to create a ZynqMP FSBL the HSI command is:
hsi::generate_app -app zynqmp_fsbl -proc cortexa53_0 -dir zynqmp_fsbl -os standalone -compile
Use the command below to get a list of all the supported templates:
hsi::generate_app -lapp
...
specicif configurationin the fsbl for the zcu102/6 boards. This would look like:
set fsbl_design [hsi::create_sw_design fsbl_1 -proc [lindex [get_processor] 0] -app zynqmp_fsbl]
↧
HSI debugging and optimization techniques
...
using HSI.What is the HSI:
In order to build a targeted platform for a device, whether it be baremetal or Kernel, then the tools need to be aware of the hardware system. The Xilinx tools such as SDK, and Petalinux use a set of TCL based utilities called
↧
HSI debugging and optimization techniques
...
For more information on the Embedded flow within Vivado, see the guide hereThe Hardware Definition File (HDF):
...
platform for Xilinx Software Commandline Tool (XSCT):
We shall be using the Xilinx Software Commandline Tool (XSCT) to explore the HDF file. The XSCT is delivered with SDK, and is an ‘umbrella’ tool that covers; HSI, XSDK, Bootgen, and the debugger. Which means that everything we can achieve in the SDK tool, can be achieved on the command line too. This is very useful for users that wish to automate the process. In this tutorial we will be using the HSI API to open and explore the HWH information in the HDF. The HSI is a TCL based utility that is used over a broad section of the Xilinx tools. For example, it is used to create the Standalone BSP in SDK.
↧
HSI debugging and optimization techniques
...
For more information on the Embedded flow within Vivado, see the guide hereThe Hardware Definition File (HDF):
...
application to Xilinx Software Commandline Tool (XSCT):
We shall be using the Xilinx Software Commandline Tool (XSCT) to explore the HDF file. The XSCT is delivered with SDK, and is an ‘umbrella’ tool that covers; HSI, XSDK, Bootgen, and the debugger. Which means that everything we can achieve in the SDK tool, can be achieved on the command line too. This is very useful for users that wish to automate the process. In this tutorial we will be using the HSI API to open and explore the HWH information in the HDF. The HSI is a TCL based utility that is used over a broad section of the Xilinx tools. For example, it is used to create the Standalone BSP in SDK.
↧
↧
HSI debugging and optimization techniques
...
{standalone.png} The HSI is also used in all the drivers, and libraries delivered in the SDK tool too. For example, the LwIP library delivered in the SDK is the open source LwIP library that has a port (wrapper), that will be tailored to work on your target device. The LwIP uses the HSI API to abstract this hardware information; such as the Ethernet IP, timer, and interrupt connections in the system to populate the port information. The HSI API is also used in the devicetree generator in Petalinux to populate the devidetree for the linux kernel.
...
see the Extracting HW info using HSI from the XSCT command line:
To see a list of all the HSI API, users can use the help:
↧
HSI debugging and optimization techniques
...
{standalone.png} The HSI is also used in all the drivers, and libraries delivered in the SDK tool too. For example, the LwIP library delivered in the SDK is the open source LwIP library that has a port (wrapper), that will be tailored to work on your target device. The LwIP uses the HSI API to abstract this hardware information; such as the Ethernet IP, timer, and interrupt connections in the system to populate the port information. The HSI API is also used in the devicetree generator in Petalinux to populate the devidetree for the linux kernel.
...
it is Extracting HW info using HSI from the XSCT command line:
To see a list of all the HSI API, users can use the help:
↧
HSI debugging and optimization techniques
...
So, let’s launch the XSCT and explore the HDF:hsi::open_hw_design design_1_wrapper.hdf
...
using the We can look at all the IP in the HWH:
hsi::get_cells *
↧
HSI debugging and optimization techniques
...
So, let’s launch the XSCT and explore the HDF:hsi::open_hw_design design_1_wrapper.hdf
...
calling the ...
call this We can look at all the IP in the HWH:
hsi::get_cells *
↧
↧
HSI debugging and optimization techniques
...
If I want to return the properties of a certain IP. I can use the command below:common::report_property [hsi::get_cells axi_timer_0]
...
specific to {properties.png}
We can use the information here to filter our search. For example, if I just want to return the processors in the HWH:
↧
bram.png
Uploaded
↧
cells.png
Uploaded
↧
loc.png
Uploaded
↧
↧
meta1.png
Uploaded
↧
meta2.png
Uploaded
↧
meta3.png
Uploaded
↧