Creating the Platform Hardware Component

The Hardware Component of a Platform captures the logical and physical interfaces to the hardware functions accelerated through the SDx™ environment. The processor, memory, and all external board interfaces are configured using a combination of Vivado® IP, user custom IP, and RTL. This provides a logic "wrapper" for the hardware functions to be executed properly on the platform. Many configuration and customization options exist depending on the types of hardware functions being accelerated.

The hardware platform creation process consists of building a Vivado® Design Suite design, configuring platform and interface properties for clocks, interrupts, and bus interfaces, and then writing the device support archive (DSA) file for use in an SDSoC platform. The logic design can be captured using IP integrator and can include RTL sources. A top-level wrapper is used to instantiate the IP integrator design as well as any top-level RTL modules. RTL modules can also be added directly to the IP integrator block design.

The write_dsa command archives the Vivado platform project data and associated files into a DSA file to define the hardware component of the platform. This chapter assumes you are familiar with the general features and processes of the Vivado Design Suite, and that you are able to create a Vivado project for the hardware in your platform. It describes the general requirements for the hardware platform, and the Vivado project.

Hardware Requirements

This section describes requirements on the hardware design component of an SDSoC™ platform. In general, nearly any design targeting the Zynq® UltraScale+™ MPSoC or UltraScale+™ device using the IP integrator within the Vivado Design Suite can be the basis for an SDSoC platform.

The process of capturing the SDSoC hardware platform is conceptually straightforward:

Build and verify the hardware system using the Vivado Design Suite and IP integrator feature.
Configure platform and interface properties.
Write the DSA file.

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.

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.

Begin with a Vivado Project

An SDSoC platform project begins with a Vivado Design Suite project file (<platform>.xpr) as the starting point to build the platform device support archive (DSA) file.

The project must include an IP integrator block diagram and can also contain any number of source files. Although nearly any project targeting a Zynq®-7000, Zynq UltraScale+ MPSoC, or MicroBlaze™ processsor can be the basis for an SDSoC project, there are a few restrictions as described in Hardware Requirements.

IMPORTANT: If you are moving the project file from one location to another, you must place the complete Vivado Design Suite project in the same directory as the project xpr file. You cannot simply copy the files in a Vivado tools project from one location to another. The Vivado Design Suite manages internal project states and file relationships in a way that is not preserved through a simple file copy. To properly copy the Vivado Design Suite project use the File > Archive Project command from the Xilinx IDE to create a zip archive. Copy and unzip this archive file into the new location. If you encounter IP Locked errors when the SDx IDE invokes the Vivado tools, it is a result of failing to properly copy the Vivado project, or failing to upgrade the project, IP. and output products for the latest version of the tool.

Design Flow for Generating the DSA

To create the Vivado Design Suite project for use in an SDSoC platform:

Launch the Vivado Design Suite IDE.
Use the Quick Start > Create Project link on the Vivado Design Suite home screen or select File > Project > New on the Vivado Design Suite menu bar to launch the New Project wizard. Use the default project name, project_1.
TIP: You can also edit an existing project as a starting point for creating a new SDSoC hardware platform.
Choose the RTL Project type and advance to the Default Part dialog to select the Xilinx device or a supported board to use for the SDSoC platform. For this example, use the ZCU102 board. For more information on creating projects and selecting parts or boards, refer to the Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994).
After the project opens in the Vivado Design Suite IDE, click on the Create Block Design command underneath IP Integrator in the Flow Navigator window. Use the default settings. The block design will be named design_1.
On the IP integrator canvas, instantiate the embedded processor IP using the Add IP (+) icon. Search for Zynq and select the Zynq UltraScale+ MPSoC IP for this example. Run Block Automation and use the Apply Board Preset option. Additional IP from the IP catalog or custom IP can be added as needed to complete the design. See the completed IP integrator design in the figure below. IP blocks and connections have been added to meet the hardware requirements stated earlier.
For more information on creating a block design using IP integrator, refer to the Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994).

For more information on creating an embedded processor block design, refer to Vivado Design Suite User Guide: Embedded Processor Hardware Design (UG898).
1. Clocking Wizard
  1. Customize Output Clocks to generate 3 PL clocks
    1. clk_out1 at 100 MHz, clk_out2 at 200 MHz, and clk_out3 at 300 MHz
  2. Reset Type = Active Low
2. Processor System Reset
  1. Add 3 instances to provide a reset for each of the 3 PL clocks
  2. Associate clk_out1 with proc_sys_reset_0, clk_out2 with proc_sys_reset_1, clk_out3 with proc_sys_reset_2
  3. Connect all dcm_locked inputs to the clk_wiz_0 locked output
  4. Connect all ext_reset_in inputs to pl_resetn0 output of the processor block
3. Concat
  1. Customize to set Number of Ports = 1
4. Edit zynq_ultra_ps_i_0 PCW settings
  1. PS-PL Configuration > PS-PL Interfaces > Master Interface
    1. Uncheck AXI_HPM0_FPD
    2. Uncheck AXI_HPM1_FPD
Declare platform interfaces for use by the sds++ system compiler by setting the PFM properties on the interface ports by using either the Platform Interfaces tab or TCL commands.
Validate the block design to ensure everything is correct, and save the design.
Optionally enable IP caching to reduce synthesis and compilation times.
Generate Output Products of the IP in the block design.
Use the Create HDL Wrapper command to create the top-level RTL design.
Export Hardware to SDK for additional software development. Note, the SDx IDE can also be used to generate software for standalone and Linux targets. Refer to Creating the Platform Software Component for more information on defining the software components.
If you are using programmable logic device I/O pins, assign I/O port constraints.
Optionally, simulate and implement the design to validate functionality and performance
Archive the project for use as a backup.
Write and validate the DSA using write_dsa and validate_dsa at the Vivado Design Suite Tcl console.

TIP: The Vivado IDE creates a journal file (.jou) that contains TCL commands that have been executed during the preceding steps. This file can be used to to create a script to automate hardware platform creation.

Logic Design Using the IP Integrator

The Vivado Design Suite IP integrator offers interactive graphical design entry and configuration capabilities that are designed to streamline the design capture process. Various automatic designer assistance and configuration features are built into the environment. A large assortment of AXI4 compliant IP is available for most system design needs.

The logic design can be captured using IP integrator or with RTL sources. A top-level wrapper is used to instantiate the IP integrator design as well as any top-level RTL modules. RTL modules can also be added directly to the IP integrator block design (BD).

Capture your hardware platform logic design containing either a Zynq® SoC, Zynq UltraScale+ MPSoC, or MicroBlaze processor.

Using the instructions from the Design Flow for Generating the DSA section, a custom platform based on the ZCU102 board part is illustrated below. Use the description in the figure titles and settings shown in each figure as a guide in creating a hardware design with 3 PL clocks, the required platform IP and platform properties.

After applying the ZCU102 board presets, the processor block is further customized by using the Processor Configuration Wizard (PCW). Double-clicking on the zynq_ultra_ps_e_0 invokes the customization wizard. Ensure a path for PL to PS interrupts exists. The PCW figure below shows the IRQ0[0-7] input to the processor is enabled. The AXI HPM0 FPD and AXI HPM1 FPD master PS-PL interfaces have been unchecked so they are available for acclerator attachment.

After applying the PCW settings, Add and customize the Clocking Wizard and Processor Sysetem Reset IP blocks.

After the block design is complete, you can apply platform properties to different interfaces to be used by the hardware function(s) within the SDx environment.

For more information on creating block designs using IP integrator and applying platform properties to available interfaces in the block design, refer to Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994).

Declaring Platform (PFM) Interfaces and Properties

After you complete the IP integrator hardware block design in the Vivado Design Suite, you must declare and add platform (PFM) properties on IP blocks for clocking (Clocking Wizard), interrupts (Concat), resets (Processor System Reset), and the processor (Zynq UltraScale+ MPSoC) AXI interfaces. These declared interfaces will then be available for hardware function(s) within the SDx environment. The simplest and easiest way to declare these interfaces and their properties is through the Platform Interfaces tab of the block design. Enable the Platform Interfaces tab, by selecting Window > Platform Interfaces from the Vivado menu bar and clicking on the Enable platform interfaces link. These properties are set once and stored in the project. A description of the underlying Tcl commands executed to set the PFM properties are also shown for reference.

This opens up the Platform Interfaces tab.

Clicking on the Enable platform interfaces link automatically populates the PFM_NAME property and lists all the interfaces that can be enabled for use by hardware accelerators within the SDx environment.

Selecting the Platform in the Platform Interfaces window shows the settings for the platform Name, Vendor, Board, and Version in the Platform Properties window. These platform properties are user editable by selecting the text box associated with each property.

The Platform Interfaces tab should now show all the interfaces available in the block design that can be tagged with platform specific properties. To enable an interface, right-click an interface and select Enable. For the example ZCU102 hardware design, enable the zynq_ultra_ps_e_0, clk_wiz_0, and xlconcat_0 ports as shown below.

The default PL clock setting for the platform is required and can be set by selecting the desired clock in the Platform Interfaces view and selecting the Options tab in the selected clocks Platform Interface Properties dialog. Click on the check-box associated with the is_default property to toggle the setting.

Perform the remaining steps to build the hardware and generate the DSA. The remainder of this chapter adds further details on platform properties and implementing the hardware design.

Validate the IP integrator block design by right-clicking on the IP integrator canvas and selecting Validate Design.
In the Sources tab, right-click on design_1.bd and select Generate Output Products. Use the default Out of context per IP synthesis option and run settings then click Generate.
In the Sources tab, right-click on design_1.bd and select Create HDL Wrapper.
In the Flow Navigator underneath Program and Debug click on Generate Bitstream.
Use the File > Export > Export Hardware command to write the hardware description file for the project. Select Include bitstream when prompted in the Export Hardware dialog box.
In the Tcl Console command box write and validate the DSA:
- write_dsa design_1.dsa
- validate_dsa design_1.dsa

Setting the Platform Name

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 string [get_files design.bd]

Where:

string is defined in the standard VLNV format, for example:
```
xilinx.com:my_lib:platformA:1.0
```
design.bd specifies the file name of the block design.

TIP: PFM_NAME can also be specified in 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 Vivado block design and the DSA will store this property.

IMPORTANT: The write_bd_tcl command does not write the PFM properties to the resulting bd_Tcl script. These properties must be exported manually to be preserved. Xilinx recommends using the Archive Project command to backup the project.

Configuring Platform Interface Properties

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 four Platform Interfaces Tcl APIs are:

set_property PFM.AXI_PORT { <port_name> {parameters} \
<port2> {parameters} ...} [get_bd_cells <cell_name>]
set_property PFM.AXIS_PORT { <port_name> {parameters} \
<port2> {parameters} ...} [get_bd_cells <cell_name>]
set_property PFM.CLOCK { <port_name> {parameters} \
<port2> {parameters} ...} [get_bd_cells <cell_name>]
set_property PFM.IRQ { <port_name> {} <port2> {} ...} \
[get_bd_cells <cell_name>]

The requirements for the PFM Properties are:

The value of the PFM interface properties must be specified as a Tcl dictionary, a list of name/"value" pairs.
IMPORTANT: The "value" must be quoted, and both the name and value are case sensitive.
A bd_cell can have multiple PFM interface definitions. However, for each type of PFM interface, all ports are required to be set in a single set_property Tcl command.
For each PFM interface property, the name specified for the port object must match the name of an external port or interface on a bd_cell. Each external port or interface object may only have one PFM interface definition.
Each different type of PFM interface may have different parameters.
Setting the PFM property with a NULL ("") string will delete previously defined PFM interfaces.

Declaring Clocks

You can export any clock source with the platform, but for each clock you 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:

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

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.

Examples:

set_property PFM.CLOCK {
PL_CLK0 {id "0" is_default "true" proc_sys_reset \
"proc_sys_reset_0"} 
PL_CLK1 {id "1" is_default "false" proc_sys_reset \
"proc_sys_reset_1"} 
PL_CLK2 {id "2" is_default "false" proc_sys_reset \
"proc_sys_reset_2"} 
PL_CLK3 {id "3" is_default "false" proc_sys_reset \
"proc_sys_reset_3"} 
} [get_bd_cells /zynq_ultra_ps_e_0]

To set a CLOCK on an external PORT:

set_property PFM.CLOCK
{ACLK_0 {id "4" is_default "false" proc_sys_reset \
"proc_sys_reset_4"}} [get_bd_ports /ACLK_0]

Declaring AXI Ports

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

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

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 that 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 sptag.
- memory: (Optional) Specify the associated MIG IP instance and address_segment. The memory tag is a unique identifier that combines the Cell name and Base Name columns in the IP integrator Address Editor. This tag will be associated with connections to the Memory Subsystem HIP, where multiple block design platform ports can share the same memory tag.

IMPORTANT: ACE and ACP ports are not supported on Zynq UltraScale+ MPSoC platforms. However, ACP is supported on Zynq-7000 SoC platforms.

Cache-coherent Support for HPC Ports on Zynq UltraScale+ Devices

Platforms that use HPC ports assuming 2018.2 behavior (non-coherent with cache flushing) must label the ports with the type S_AXI_HP, instead of S_AXI_HPC. Both behave as though they are HP ports. However, ports labeled S_AXI_HPC are handled to enable coherence. The platform author should also adjust the BIF file, as shown below, for HPC ports with coherence enabled.

This is the recommended method for Linux boot as it guarantees that the register is written prior to the APU coming out of reset.

The Boot ROM can be used to write the register by using an init value in the boot image. Bootgen allows the init value to be added to the boot image. The following bif file snippet for bootgen illustrates the addition of the file containing an init value.

//arch = zynqmp; split = false; format = BIN
the_ROM_image:
{
   ...
   [init]<path>\regs.init
}

The following line of code illustrates the init value that should be in the regs.init file to cause outer shareable transactions to be broadcast to the CCI.

.set. 0xFF41A040 = 0x3;

For more information, see the Zynq UltraScale+ MPSoC Cache Coherency wiki page.

Example for an AXI Interconnect

set_property PFM.AXI_PORT { \
	M_AXI_GP0 {memport "M_AXI_GP"} \
	M_AXI_GP1 {memport "M_AXI_GP"} \
	S_AXI_ACP {memport "S_AXI_ACP" sptag "ACP" memory \
"processing_system7_0 ACP_DDR_LOWOCM"} \
	S_AXI_HP0 {memport "S_AXI_HP" sptag "HP0" memory \
"processing_system7_0 HP0_DDR_LOWOCM"} \
	S_AXI_HP1 {memport "S_AXI_HP" sptag "HP1" memory \
"processing_system7_0 HP1_DDR_LOWOCM"} \
	S_AXI_HP2 {memport "S_AXI_HP" sptag "HP2" memory \
"processing_system7_0 HP2_DDR_LOWOCM"} \
	S_AXI_HP3 {memport "S_AXI_HP" sptag "HP3" memory \
"processing_system7_0 HP3_DDR_LOWOCM"} \
	} [get_bd_cells /processing_system7_0]

Exporting AXI interconnect master and slave ports involves several requirements.

All ports on the interconnect used within the platform must precede in index order any declared platform interfaces.
There can be no gaps in the port indexing.
The maximum number of master IDs for the S_AXI_ACP port is eight, so on a connected AXI interconnect, available ports to declare must be one of {S00_AXI, S01_AXI, ..., S07_AXI}. Do not declare any ports that are used within the platform itself. Declaring as many as possible will allow sds++ to avoid cascaded axi_interconnects in generated user systems.
The maximum number of master IDs for an S_AXI_HP or MIG port is sixteen, so on an connected AXI interconnect, available ports to declare must be one of {S00_AXI, S01_AXI, ..., S15_AXI}. Do not declare any ports that are used within the platform itself. Declaring as many as possible will allow sds++ to avoid cascaded axi_interconnects in generated user systems.
The maximum number of master ports declared on an interconnect connected to an M_AXI_GP port is sixty-four, so on an connected AXI interconnect, available ports to declare must be one of {M00_AXI, M01_AXI, ..., M63_AXI}. Do not declare any ports that are use within the platform itself. Declaring as many as possible will allow sds++ to avoid cascaded axi_interconnects in generated user systems.

Additional Examples

To define an AXI_port on interconnect:

set parVal []
for {set i 2} {$i < 64} {incr i} {
	lappend parVal M[format %02d $i]_AXI \
{memport "M_AXI_GP"}
}
set_property PFM.AXI_PORT $parVal [get_bd_cells /axi_interconnect_0]

To define an AXI_port on SmartConnect IP:

set parVal []
for {set i 1} {$i < 16} {incr i} {
	lappend parVal S[format %02d $i]_AXI \
{memport "MIG" sptag "Bank0"}
}
set_property PFM.AXI_PORT $parVal [get_bd_cells /smartconnect_0]

To define an AXI_PORT that connects with MIG IP:

set parVal []
for {set i 1} {$i < 16} {incr i} {
	lappend parVal S[format %02d $i]_AXI \
{memport "MIG" sptag "bank0" memory "ddrmem_0 C0_DDR4_ADDRESS_BLOCK"}
}
set_property PFM.AXI_PORT $parVal [get_bd_cells \
/memory_subsystem/interconnect_data/interconnect_aximm_ddrmem0]

Declaring AXI4-Stream Ports

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

set_property PFM.AXIS_PORT { <port_name> {parameters} \
<port_name_2> {parameters} .. } [get_bd_cells <cell_name>]

Argument Description

Port_name: AXI4-Stream port name.
Parameters:
- type value: Streaming interface port type. Valid values for type include:
  - M_AXIS: A general-purpose AXI master port
  - S_AXIS: A high-performance AXI slave port

Examples

set_property PFM.AXIS_PORT {AXIS_P0 {type "S_AXIS"}} \
[get_bd_cells /zynq_ultra_ps_e_0]

Declaring Interrupt Ports

Interrupts must be connected to IP integrator Concat (xlconcat) blocks that are connected to the processing system. For Zynq-7000 family it is the F2P_irq port. For Zynq UltraScale+ MPSoC devices the interrupts are split into two 8-bit ports: pl_ps_irq0[7:1] and pl_ps_irq1[7:1].

IMPORTANT: If any IP within the platform includes interrupts, these must occupy the least significant bits of the Concat block without gaps.

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

set_property PFM.IRQ { <port_name> {} <port2> {} ...} \
[get_bd_cells <cell_name>]

Argument Description

Port_name: IRQ port name
{}: Empty list that serves as a placeholder.

Example

set irqProp [] 
for {set i 0} {$i < 8} {incr i} 
{ lappend irqProp In$i {} } 
set_property PFM.IRQ $irqProp [get_bd_cells /xlconcat_0] 
set_property PFM.IRQ $irqProp [get_bd_cells /xlconcat_1

TIP: The FOR loop results in a PFM.IRQ property as defined by $irqProp that looks like:

In0 {} In1 {} In2 {} In3 {} In4 {} In5 {} In6 {} In7 {}

Example PFM Property Tcl Script

This example script assigns the PFM properties to the block design on the Xilinx supplied ZCU102 platform.

# set_property PFM_NAME "xilinx.com:zcu102:zcu102:1.0" \
[get_files ./zcu102/zcu102.srcs/sources_1/bd/zcu102/zcu102.bd]
# set_property PFM.CLOCK { \
# clk_out1 {id "0" is_default "false" proc_sys_reset \
"proc_sys_reset_0" } \
# clk_out2 {id "1" is_default "true" proc_sys_reset \
"proc_sys_reset_0" } \
# clk_out3 {id "2" is_default "false" proc_sys_reset \
"proc_sys_reset_0" } \
# clk_out4 {id "3" is_default "false" proc_sys_reset \
"proc_sys_reset_0" } \
# clk_out5 {id "4" is_default "false" proc_sys_reset \
"proc_sys_reset_0" } \
# clk_out6 {id "5" is_default "false" proc_sys_reset \
"proc_sys_reset_0" } \
# clk_out7 {id "6" is_default "false" proc_sys_reset \
"proc_sys_reset_0" } \
# } [get_bd_cells /clk_wiz_0]
# set_property PFM.AXI_PORT { \
# M_AXI_HPM0_FPD {memport "M_AXI_GP"} \
# M_AXI_HPM1_FPD {memport "M_AXI_GP"} \
# M_AXI_HPM0_LPD {memport "M_AXI_GP"} \
# S_AXI_HPC0_FPD {memport "S_AXI_HPC" sptag "HPC0"} \
# S_AXI_HPC1_FPD {memport "S_AXI_HPC" sptag "HPC1"} \
# S_AXI_HP0_FPD {memport "S_AXI_HP" sptag "HP0"} \
# S_AXI_HP1_FPD {memport "S_AXI_HP" sptag "HP1"} \
# S_AXI_HP2_FPD {memport "S_AXI_HP" sptag "HP2"} \
# S_AXI_HP3_FPD {memport "S_AXI_HP" sptag "HP3"} \
# } [get_bd_cells /ps_e]
# set intVar []
# for {set i 0} {$i < 8} {incr i} {
# lappend intVar In$i {}
# }
# set_property PFM.IRQ $intVar [get_bd_cells /xlconcat_0]
# set_property PFM.IRQ $intVar [get_bd_cells /xlconcat_1]

Implementing the Hardware Platform Design

The hardware platform design should be implemented and validated to ensure it works as expected in the Xilinx SDSoC flow. The first step in that validation process should be to ensure the hardware platform design itself is performing as expected. This can be done using test kernel logic to populate the dynamic region.

Using the IP Cache

Significant synthesis run-time savings can be achieved by taking advantage of the IP caching capabilities in Vivado synthesis. IP caching stores the synthesis results for each IP configuration and uses the cached results in place of re-synthesizing the IP during output generation, and for additional IP instances that have matching configurations.

In order for the IP to be cached successfully for use in the DSA, the Vivado Settings need to be configured so the Cache location is local to the Vivado project prior to generating the IP integrator block design. This is the default setting, as shown in the following figure.

Setting the IP caching repository involves pointing to the IP cache repository. Use the following Tcl command to set the cache prior to creating the DSA.

set_property dsa.ip_cache_dir [get_property ip_output_repo \
[current_project]] [current_project]

Creating Design Constraints

This section discusses the various types of physical constraints that are needed to support the hardware platform.

Timing Constraints

Timing constraints are specified using the same methods for any Vivado design project. At a minimum, constraints need to be defined for all clocks. Refer to the Vivado Design Suite User Guide: Using Constraints (UG903) for more information.

I/O and Clock Constraints

One of the key considerations in the design of a DSA is to identify the I/O interfaces necessary for the board requirements. The Processing System related I/Os are fixed, but any external interfaces from the programmable logic (PL) need to have I/O constraints assigned to drive the implementation tools. The physical I/O locations will influence performance and must be considered as part of the platform planning process.

Refer to the Vivado Design Suite User Guide: I/O and Clock Planning (UG899) for more information on I/O and clock planning.

Simulating the Design

The Vivado Design Suite has extensive logic simulation capabilities to enable block or system level validation of the design. Available third party FPGA simulation tools are also supported. Refer to the Vivado Design Suite User Guide: Logic Simulation (UG900) for more information.

Implementation and Timing Validation

The design should be synthesized and implemented to ensure desired performance is achieved. It is often required to iterate on floorplanning and implementation strategies to ensure optimal performance.

It is often important to implement, analyze, and iterate on the hardware platform design to ensure that it continues to meet timing during kernel implementation. Using a test kernel, implement the design and then check that the design meets timing by opening the Implemented Design.

The floorplan can be examined and modified if need be to optimize implementation results. Refer to the Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906) for more information.

Generating a Device Support Archive

After completing your hardware platform design, setting the PFM properties, and generating a valid bitstream using the Vivado Design Suite, you are ready to create a Device Support Archive (DSA) file for use with the SDSoC Development Environment. The DSA is a single-file that captures the complete hardware platform design, to be used in creating an SDSoC platform project.

IMPORTANT: After creating the DSA file you should retain the source Vivado Design Suite project files so you can recreate or update the DSA file as needed. You can archive the project using the archive_project Vivado Tcl command.

Once the required properties have been set, you generate a DSA file using the write_dsa command from the Tcl console in the Vivado tool:

write_dsa <filename>.dsa -include_bit

This creates an archive of the hardware platform that contains all the relevant files and data needed by the SDSoC Development Environment. The write_dsa command will also create a bitstream file if one has not yet been created.

The syntax and short help for the write_dsa is shown below::

write_dsa  [-force] [-include_bit] [-include_emulation] [-legacy] [-minimal]
           [-quiet] [-verbose] [<file>]

Returns: 
The name of the dsa file

Usage: 
  Name                  Description
  ---------------------------------
  [-force]              Overwrite existing device support 
                        archive file
  [-include_bit]        Include bit file(s) in the dsa.
  [-include_emulation]  Generate and include hardware 
                        emulation support in the dsa.
  [-legacy]             Write a legacy DSA (based on OCL 
                        Block IP)
  [-minimal]            Add only minimal files in the dsa.
  [-quiet]              Ignore command errors
  [-verbose]            Suspend message limits during 
                        command execution
  [<file>]              Device Support Archive filename 
                        with alphanumeric characters and 
                        .dsa extension.

Validating the DSA

You can use the validate_dsa command to validate a custom DSA file to ensure it contains the proper content and metadata needed to support the hardware platform in the Xilinx SDSoC™ environment. Use the following command to validate a DSA file:

 validate_dsa <dsa file> -verbose