Creating the Platform Hardware Component

The Hardware Component of a Platform captures the logical and physical interfaces to the hardware functions accelerated through theSDx™environment. The processor, memory, and all external board interfaces are configured using a combination ofVivado®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 aVivado® Design Suitedesign, configuring platform and interface properties for clocks, interrupts, and bus interfaces, and then writing the device support archive (DSA) file for use in anSDSoCplatform. 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.

Thewrite_dsacommand 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 theVivado Design Suite, and that you are able to create aVivadoproject for the hardware in your platform. It describes the general requirements for the hardware platform, and theVivadoproject.

Hardware Requirements

This section describes requirements on the hardware design component of anSDSoC™platform. In general, nearly any design targeting theZynq® UltraScale+™ MPSoCorUltraScale+™device using the IP integrator within theVivado Design Suitecan be the basis for anSDSoCplatform.

The process of capturing theSDSoChardware platform is conceptually straightforward:

Build and verify the hardware system using theVivado Design Suiteand 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 Xilinxdesign 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 SDxplatform project.

Every IP used in the platform design that is not part of the standard Vivado IP catalog must be local to theVivado Design Suiteproject. References to external IP repository paths are not supported by thewrite_dsacommand.
Every hardware platform design must contain a Processing System IP block from theXilinxIP catalog.
Every hardware port interface to theSDSoCplatform 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 theSDSoCcompilers for software control of datamover and accelerator IP.
Every platform must declare at least one AXI slave port that will be used by theSDSoCcompilers to access DDR from datamover and accelerator IP.
To share an AXI port between theSDSoCenvironment and platform logic, for exampleS_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 theSDSoCenvironment.

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 theVivadoIP catalog.
Platform interrupt inputs must be exported by a Concat (xlconcat) IP connected to the Processing System 7 IPIRQ_F2Pport. IP blocks within a platform can use some of the sixteen available fabric interrupts, but must use the least significant bits of theIRQ_F2Pport without gaps.

Begin with a Vivado Project

AnSDSoCplatform project begins with aVivado Design Suiteproject 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 aZynq®-7000,Zynq UltraScale+ MPSoC, orMicroBlaze™processsor can be the basis for anSDSoCproject, there are a few restrictions as described inHardware Requirements.

IMPORTANT:If you are moving the project file from one location to another, you must place the complete Vivado Design Suiteproject in the same directory as the project xprfile. You cannot simply copy the files in a Vivadotools project from one location to another. The Vivado Design Suitemanages internal project states and file relationships in a way that is not preserved through a simple file copy. To properly copy the Vivado Design Suiteproject use the File>Archive Projectcommand from the XilinxIDE to create a zip archive. Copy and unzip this archive file into the new location. If you encounter IP Locked errors when the SDxIDE invokes the Vivadotools, it is a result of failing to properly copy the Vivadoproject, 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 theVivado Design SuiteIDE.
Use theQuick Start > Create Projectlink on theVivado Design Suitehome screen or selectFile>Project>Newon theVivado Design Suitemenu bar to launch theNew Projectwizard. 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 theRTL Projecttype and advance to theDefault Partdialog to select the Xilinx device or a supported board to use for theSDSoCplatform. For this example, use the ZCU102 board. For more information on creating projects and selecting parts or boards, refer to theVivado Design Suite User Guide: Designing IP Subsystems using IP Integrator(UG994).
After the project opens in theVivado Design SuiteIDE, click on theCreate Block Designcommand underneathIP Integratorin theFlow Navigatorwindow. Use the default settings. The block design will be nameddesign_1.
On the IP integrator canvas, instantiate the embedded processor IP using theAdd IP (+)icon. Search for Zynq and select theZynq UltraScale+ MPSoCIP for this example. RunBlock Automationand use theApply Board Presetoption. 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 theVivado Design Suite User Guide: Designing IP Subsystems using IP Integrator(UG994).
For more information on creating an embedded processor block design, refer toVivado Design Suite User Guide: Embedded Processor Hardware Design(UG898).
1. Clocking Wizard
  1. Customize Output Clocks to generate 3 PL clocks
    1. clk_out1at 100 MHz,clk_out2at 200 MHz, andclk_out3at 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. Associateclk_out1withproc_sys_reset_0,clk_out2withproc_sys_reset_1,clk_out3withproc_sys_reset_2
  3. Connect alldcm_lockedinputs to theclk_wiz_0lockedoutput
  4. Connect allext_reset_ininputs topl_resetn0output of the processor block
3. Concat
  1. Customize to setNumber 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 Productsof the IP in the block design.
Use theCreate HDL Wrappercommand to create the top-level RTL design.
Export Hardwareto SDK for additional software development. Note, theSDxIDE can also be used to generate software for standalone and Linux targets. Refer toCreating the Platform Software Componentfor 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 usingwrite_dsaandvalidate_dsaat theVivado Design SuiteTcl 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

TheVivado Design SuiteIP integratoroffers 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 ofAXI4compliant IP is available for most system design needs.

The logic design can be captured usingIP integratoror with RTL sources. A top-level wrapper is used to instantiate theIP integratordesign as well as any top-level RTL modules. RTL modules can also be added directly to theIP integratorblock design (BD).

Capture your hardware platform logic design containing either aZynq®SoC,Zynq UltraScale+ MPSoC, orMicroBlazeprocessor.

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 thezynq_ultra_ps_e_0invokes the customization wizard. Ensure a path for PL to PS interrupts exists. The PCW figure below shows theIRQ0[0-7]input to the processor is enabled. TheAXI HPM0 FPDandAXI HPM1 FPDmaster 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 theSDxenvironment.

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

Declaring Platform (PFM) Interfaces and Properties

After you complete theIP integratorhardware 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 theSDxenvironment. 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 selectingWindow>Platform Interfacesfrom the Vivado menu bar and clicking on theEnable platform interfaceslink. 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 theEnable platform interfaceslink automatically populates the PFM_NAME property and lists all the interfaces that can be enabled for use by hardware accelerators within theSDxenvironment.

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 Interfacesview and selecting the Optionstab in the selected clocks Platform Interface Propertiesdialog. Click on the check-box associated with the is_defaultproperty 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 theIP integratorblock design by right-clicking on theIP integratorcanvas and selectingValidate Design.
In theSourcestab, right-click ondesign_1.bdand selectGenerate Output Products. Use the default Out of context per IP synthesis option and run settings then clickGenerate.
In theSourcestab, right-click ondesign_1.bdand selectCreate HDL Wrapper.
In theFlow NavigatorunderneathProgram and Debugclick onGenerate Bitstream.
Use theFile>Export>Export Hardwarecommand to write the hardware description file for the project. SelectInclude bitstreamwhen 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_NAMEstring[get_files design.bd]

Where:

stringis defined in the standard VLNV format, for example:
```
xilinx.com:my_lib:platformA:1.0
```
design.bdspecifies the file name of the block design.

TIP: PFM_NAMEcan also be specified in simple form with just the Namefrom 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_tclcommand 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 {  {parameters} \  {parameters} ...} [get_bd_cells ] set_property PFM.AXIS_PORT {  {parameters} \  {parameters} ...} [get_bd_cells ] set_property PFM.CLOCK {  {parameters} \  {parameters} ...} [get_bd_cells ] set_property PFM.IRQ {  {}  {} ...} \ [get_bd_cells ]

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 singleset_propertyTcl 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 {  {parameters} \  {parameters} ...} [get_bd_cells ]

Argument Description

Port_name: Clock port name.
Parameters:
- id: Clock ID is a user-defined value that must be a unique non-negative integer.
- is_default: Specify "true" if this is the default clock, "false" otherwise. The default is "false."
- proc_sys_reset: This name/value pair specifies the correspondingproc_sys_resetblock instance for synchronized reset signals connected to the clock port.

IMPORTANT:Every platform must declare one default clock with the is_defaultparameter set to "true" for the SDSoCenvironment 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 {  {parameters} \  {parameters} ...} [get_bd_cells ]

Argument Description

Port_name: AXI port name.
Parameters:
- memporttype: Corresponding memory interface port type. Validtypevalues 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.
- sptagID: (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 samesptag.
- memory: (Optional) Specify the associated MIG IP instance and address_segment. The memory tag is a unique identifier that combines theCellname andBase Namecolumns in the IP integratorAddress 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+ MPSoCplatforms. However, ACP is supported on Zynq-7000 SoCplatforms.

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]\regs.init }

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

.set. 0xFF41A040 = 0x3;

For more information, see theZynq 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 allowsds++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 allowsds++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 allowsds++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 {  {parameters} \  {parameters} .. } [get_bd_cells ]

Argument Description

Port_name: AXI4-Stream port name.
Parameters:
- typevalue: 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-7000family it is the F2P_irqport. For Zynq UltraScale+ MPSoCdevices 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 {  {}  {} ...} \ [get_bd_cells ]

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 $irqPropthat 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 theXilinxSDSoCflow. 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 inVivadosynthesis. 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, theVivadoSettings need to be configured so the Cache location is local to theVivadoproject prior to generating theIP integratorblock 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 theVivado 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 theVivado 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 theVivado 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 theVivado 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 theSDSoCDevelopment Environment. The DSA is a single-file that captures the complete hardware platform design, to be used in creating anSDSoCplatform 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_projectVivado Tcl command.

Once the required properties have been set, you generate a DSA file using thewrite_dsacommand 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 theSDSoCDevelopment Environment. Thewrite_dsacommand will also create a bitstream file if one has not yet been created.

The syntax and short help for thewrite_dsais shown below::

write_dsa [-force] [-include_bit] [-include_emulation] [-legacy] [-minimal] [-quiet] [-verbose] [] 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 [] Device Support Archive filename with alphanumeric characters and .dsa extension.

Validating the DSA

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

validate_dsa <dsa file> -verbose