TBC

It is assumed that the user has completed successfully the following tutorials:

• Build firmware guide

It is assumed that the user is familiar with the following documentation

• UG1146
• UG1236
• Creating the Platform Hardware Component
• Creating the Platform Hardware Component

TBC

• Vivado 17.4/18.3
• Petalinux 17.4/18.3
• SDx/SDK 17.4/18.3
• Ubuntu 16.04/18.04
• Place the Sundance Board Files in the following paths:

2017.4:

Xilinx/Vivado/2017.4/data/boards/board_files/
Xilinx/SDK/2017.4/data/boards/board_files/
Petalinux/tools/hsm/data/boards/board_files/

2018.3:

Xilinx/Vivado/2018.3/data/boards/board_files/
Xilinx/SDK/2018.3/data/boards/board_files/
Petalinux/tools/xsct/SDK/2018.3/data/boards/board_files/

• Steps

1. Create a folder and extract inside the corresponding repository "ZXXXX". TBC

$

2. Open Vivado, and go to "Tools -> Run tcl Script..." Browse "FM191_ZXXXX.tcl". This creates the project, it generates the bitstream and exports the .hdf file too. They can be found at:

• <project_path>/FM191_ZXXXX/FM191_ZXXXX.runs/impl_1/*.bit
• <project_path>/FM191_ZXXXX/FM191_ZXXXX.sdk/*.hdf NOTE: There are several rules that the platform hardware design must observe.

TIP: If the Xilinx design project contains more than one block diagram, one block diagram must have the same name as the hardware platform, and that block diagram is used by the SDx platform project.

The Hardware Component of a Platform captures the logical and physical interfaces to the hardware functions accelerated through the SDx™ environment. A DSA file or the hardware component of the SDSoC platform is the hardware hand-off file given from Xilinx Vivado tool to the Xilinx SDx tool to create an SDSoC platform to create either a Standalone (bare-metal) or Linux application on the MPSoC hardware.

• Every IP used in the platform design that is not part of the standard Vivado IP catalog must be local to the Vivado Design Suite project. References to external IP repository paths are not supported by the write_dsa command.
• Every hardware platform design must contain a Processing System IP block from the Xilinx IP catalog.
• Every hardware port interface to the SDSoC platform must be an AXI, AXI4-Stream, clock, reset, or interrupt type interface only. Custom bus types or hardware interfaces must remain internal to the hardware platform.
• Every platform must declare at least one general purpose AXI master port from the Processing System IP or an interconnect IP connected to such an AXI master port, that will be used by the SDSoC compilers for software control of datamover and accelerator IP.
• Every platform must declare at least one AXI slave port that will be used by the SDSoC compilers to access DDR from datamover and accelerator IP.
• To share an AXI port between the SDSoC environment and platform logic, for example S_AXI_ACP, you must export an unused AXI master or slave of an AXI Interconnect IP block connected to the corresponding AXI port, and the platform must use the ports with least significant indices.
• Every platform AXI interface will be connected to a single data motion clock by the SDSoC environment.

TIP: Accelerator functions generated by the SDSoC compilers might run on a different clock that is provided by the platform.

• Every exported platform clock must have an accompanying Processor System Reset IP block from the Vivado IP catalog.
• Platform interrupt inputs must be exported by a Concat (xlconcat) IP connected to the Processing System 7 IP IRQ_F2P port. IP blocks within a platform can use some of the sixteen available fabric interrupts, but must use the least significant bits of the IRQ_F2P port without gaps.

Following are the TCL commands to create the DSA file if one wants to use the Vivado GUI to create the DSA file please refer Creating the Platform Hardware Component

Open vivado and run the following commands in the Tcl console (adjust the path so it relflects where your design_1.bd is located)

• open_bd_design C:/Data/project1/project1.src/sources_1/bd/design_1/design_1.bd

• The Platform Identification property (PFM_NAME) must be set in the hardware design to define the Vendor, Library, Name, and Version (VLNV) of the platform.

set_property PFM_NAME {sundance:lib:zu4cg:1.0} [get_files design.bd]

Where:
the string is defined in the standard VLNV format, for example: 'sundance:lib:zu4cg:1.0' and design.bd specifies the file name of the block design.

TIP: PFM_NAME can also be specified in a simple form with just the Name from the VLNV form. The Vendor, Library, and Version fields will be populated with default values: vendor, lib, and 1.0.\

Example: set_property PFM_NAME zcu102 [get_files zcu102.bd]\

This results in the PFM_NAME: vendor:library:zcu102:1.0.

The Platform Interfaces are defined using the four PFM properties described below. They can be defined manually in the Tcl Console, or by a Tcl script for the design.

The Platform Interfaces Tcl APIs are:

The Tcl command for setting the PFM.AXI_PORT property is:

set_property PFM.AXI_PORT { <port_name> {parameters}
{parameters} ...} [get_bd_cells <cell_name>]

The target board design TCL script for AXI Interfaces is as follows

set_property PFM.AXI_PORT {M_AXI_HPM0_FPD {memport "M_AXI_GP" sptag "" memory ""} M_AXI_HPM0_LPD {memport "M_AXI_GP" sptag "" memory ""} S_AXI_HP0_FPD {memport "S_AXI_HP" sptag "" memory ""}} [get_bd_cells /zynq_ultra_ps_e_0]

set_property PFM.AXI_PORT {M_AXI_HPM0_FPD {memport "M_AXI_GP" sptag "" memory ""} M_AXI_HPM0_LPD {memport "M_AXI_GP" sptag "" memory ""} S_AXI_HP0_FPD {memport "S_AXI_HP" sptag "" memory ""}} [get_bd_cells /zynq_ultra_ps_e_0]

set_property PFM.AXI_PORT {M_AXI_HPM0_FPD {memport "M_AXI_GP" sptag "" memory ""} M_AXI_HPM0_LPD {memport "M_AXI_GP" sptag "" memory ""} S_AXI_HP0_FPD {memport "S_AXI_HP" sptag "" memory ""}} [get_bd_cells /zynq_ultra_ps_e_0]

Argument Description Port_name: AXI port name.

Parameters memport type: Corresponding memory interface port type. Valid type values include: M_AXI_GP: A general-purpose AXI master port S_AXI_HP: A high-performance AXI slave port S_AXI_ACP: An accelerator coherent slave port S_AXI_HPC: A high-performance accelerator coherent slave port MIG: An AXI slave connected to a MIG memory controller. The default is MIG. sptag ID: (Optional)

A user-defined ID should start with an alphabetic character. The ID is case-sensitive. The system port tag (sptag) is a symbolic identifier that represents a class of platform port connections (e.g. S_AXI_HP, S_AXI_ACP, M_AXI_GP). Multiple block design platform ports can share the same stage.

NOTE: Keeping in mind we can only use the AXI slave and master ports which are unused in the design.

Declaring Clocks

One can export any clock source with the platform, but for each clock, one must also export synchronized reset signals using a Processor System Reset IP block in the platform. The PFM.CLOCK property can be set on a BD cell, external port, or external interface.

The Tcl command for setting the PFM.CLOCK property is as follows :

set_property PFM.CLOCK { <port_name> {parameters}
{parameters} ...} [get_bd_cells <cell_name>]

The TCL script for the target board Clock Interfaces is as follows (the below script is for zu4cg board. Modifications to the clock is needed if the board being designed on is different)

set_property PFM.CLOCK {pl_clk0 {id "2" is_default "true" proc_sys_reset "/rst_ps8_0_100M"} pl_clk1 {id "3" > is_default "false" proc_sys_reset "/proc_sys_reset_0"}} [get_bd_cells /zynq_ultra_ps_e_0]

Argument Description

Port_name: Clock port name.
Parameters:

    id <value>: Clock ID is a user-defined value that must be a unique non-negative integer.

    is_default <value>: Specify "true" if this is the default clock, "false" otherwise. The default is "false."

    proc_sys_reset <value>: This name/value pair specifies the corresponding proc_sys_reset block instance for synchronized reset signals connected to the clock port.

IMPORTANT: Every platform must declare one default clock with the is_default parameter set to "true" for the SDSoC environment to use when no explicit clock has been specified.

NOTE: Other tcl commands to set up the details of the dsa file

set_property dsa.vendor {sundance} [current_project]

set_property dsa.board_id {lib} [current_project]

set_property dsa.version {1.0} [current_project]

set_property dsa.name {design_1.dsa} [current_project]

Important the DSA file name should be the same as your board design name.

Re-generate the bit file for the design and export the hdf file and bit file. Run the following command to generate the dsa file

$ write_dsa -include_bit -force design_1.dsa

Remember the dsa file will be generated in the directory where you are running vivado from if you want to generate the DSA file in a separate directory please provide the full path name before the 'design_1.dsa' name e.g.

$ write_dsa -include_bit -force $HOME/zu4cg/design_1.dsa

Now validate the DSA file by running following command

$ validate_dsa design_1.dsa -verbose

If no errors your DSA file is generated for the Vivado SDx and can be used to create a software platform.

Return Home