Basic HLS Tutorial

using C++ language and Vivado Design Suite to design two frequencies PWM

modulator system

January 8, 2018
Contents

1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Purpose of this Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Objectives of this Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 One Possible Solution for the Modulator Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 About HLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Design steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.7 Vivado HLS Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 DEVELOPING CUSTOM IP CORE USING HLS . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Create a New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Develop C Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Verify C Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.1 C Simulation Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Synthesize C Algorithm into an RTL Implementation (High-Level Synthesis) . . . . . . . . . . . 28
2.4.1 C Synthesis Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.2 C Synthesis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.3 Clock, Reset, and RTL Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.4 Applying Optimization Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5 Verify the RTL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.5.1 Using C/RTL Co-Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.5.2 Analyzing RTL Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.6 Package the RTL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.6.1 Packaging IP using IP Catalog Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3 USING DEVELOPED IP CORE IN VIVADO DESIGN SUITE . . . . . . . . . . . . . . . 77

3.1 Create a new project with included developed IP core . . . . . . . . . . . . . . . . . . . . . . . . 77
3.2 Create ARM-based hardware platform with integrated developed IP core . . . . . . . . . . . . . 78
3.3 Debug the design with included developed IP core . . . . . . . . . . . . . . . . . . . . . . . . . . 104

2
Chapter 1

INTRODUCTION

1.1 Motivation
”Basic HLS Tutorial” is a document made for beginners who are entering the world of embedded system design
using FPGAs. This tutorial explains, step by step, the procedure of designing a simple digital system using
C/C++/SystemC languages and Xilinx Vivado Design Suite.

1.2 Purpose of this Tutorial

This tutorial is made to introduce you how to create, simulate and test an project and run it on your
development board.

After completing this tutorial, you will be able to:

• Launch and navigate the Vivado High-Level Synthesis (HLS) tool

• Create a project using New Project Creation Wizard
• Develop a C algorithm for your design
• Verify a C algorithm of your design

• Synthesize a C algorithm into an RTL implementation (High-Level Synthesis)

• Generate reports and analyze the design
• Verify the RTL implementation

• Package the RTL implementations

The following project is designed for:

• Designing Surface: VIVADO 2017.4

• Programming Language: C
• Device: Socius Development Board

1.3 Objectives of this Tutorial

In this tutorial a PWM signal modulated using the sine wave with two different frequencies (1 Hz and 3.5
Hz) will be created. Frequency that will be chosen depends on the position of the two-state on-board switch
(sw0).

1
 2

PWM Signal

Pulse-width modulation (PWM) uses a rectangular pulse wave whose pulse width is modulated by some other
signal (in our case we will use a sine wave) resulting in the variation of the average value of the waveform.
Typically, PWM signals are used to either convey information over a communications channel or control the
amount of power sent to a load. To learn more about PWM signals, please visit http://en.wikipedia.org/
wiki/Pulse-width_modulation.

Figure 1.1. illustrates the principle of pulse-width modulation. In this picture an arbitrary signal is used to
modulate the PWM signal, but in our case sine wave signal will be used.

Figure 1.1: Example of the PWM signal

1.4 One Possible Solution for the Modulator Design

Considering that we are working with digital systems and signals, our task will be to generate an digital
representation of an analog (sine) signal with two frequencies: 1 Hz and 3.5 Hz.

Figure 1.2 is showing the sine wave that will be used to modulate the PWM signal.

Figure 1.2: Sine wave with 256 samples

One period of the sine wave is represented with 256 (28 ) samples, where each sample can take one of 4096 (212 )
possible values. Since the sine wave is a periodic signal, we only need to store samples of one period of the
signal.
3

Note : Pay attention that all of sine signals with the same amplitude, regardless their frequency, look the same
during the one period of a signal. The only thing that is different between those sine signals is duration of a
signal period. This means that the sample rate of those signals is different.

Considering that the whole system will be clocked with the 50 MHz input signal, which is available on the target
development board, to get 1 Hz and 3.5 Hz frequencies (which is much smaller than 50 MHz) we should divide
input clock frequency with integer value N.

In the Tables 1.1 and 1.2 are shown parameters that are necessary for generating sine signals with 1 Hz and 3.5
Hz frequencies.

Table 1.1: Sine signal with the frequency of 1 Hz

Division Factor Steps Calculation Explanation

T=1 s T=1/1 Hz=1 s T is the period of the signal
f1=256 f1=256x1 Hz=256 Hz (or read in time: 1 s/256) f1 is the frequency of reading whole period (T)
with 256 samples
N1=195312.5 N1=50 MHz/256 Hz=195312.5 N1 is the number which divides frequency of the
input clock signal (50 MHz) to the required fre-
quency for the digital sine module
N2=48 N2=195313/4096=47.6838 N2 is the number which divides frequency of the
input clock signal (50 MHz) to the required fre-
quency for the PWM’s FSM module
N1=196608 N1=48x4096=196608 This is new calculation, because N1 must be di-
visible with 4096

Table 1.2: Sine signal with the frequency of 3.5 Hz

Division Factor Steps Calculation Explanation

T=0.286 s T=1/3.5 Hz=0.286 s T is the period of the signal
f2=896 Hz f2=256x3.5 Hz=896 Hz (or read in time: 0.286 s/256) f1 is the frequency of reading whole period
(T) with 256 samples
N1=55803.5714 N1=50 MHz/896 Hz=55803.5714 N1 is the number which divides frequency
of the input clock signal (50 MHz) to the
required frequency for the digital sine mod-
ule
N2=14 N2=50804/4096=13.624 N2 is the number which divides frequency
of the input clock signal (50 MHz) to the
required frequency for the PWM’s FSM
module
N1=57344 N1=14x4096=57344 This is new calculation, because N1 must
be divisible with 4096

Now, it is obvious that the sine wave can be generated by reading sample values of one period, that are stored
in one table, with appropriate speed. In our case the values will be generated using the sine function from the
C numerics library (math.h) and will be stored in an array.
 4

1.5 About HLS

The Xilinx Vivado High-Level Synthesis (HLS) is a tool that transforms a C specification into a register transfer
level (RTL) implementation that you can synthesize into a Xilinx field programmable gate array (FPGA).

You can write C specifications in C, C++, SystemC, or as an Open Computing Language (OpenCL) API C
kernel, and the FPGA provides a massively parallel architecture with benefits in performance, cost, and power
over traditional processors.

By targeting an FPGA as the execution fabric, HLS enables a software engineer to optimize code for throughout,
power, and latency without the need to address the performance bottleneck of a single memory space and limited
computational resources. This allows the implementation of computationally intensive software algorithms into
actual products, not just functionality demonstrators.

High-level synthesis bridges hardware and software domains, providing the following primary benefits:

• Improved productivity for hardware designers

Hardware designers can work at a higher level of abstraction while creating high-performance hardware.

• Improved system performance for software designers

Software developers can accelerate the computationally intensive parts of their algorithms on a new com-
pilation target, the FPGA.

Using a high-level synthesis design methodology allows you to:

• Develop algorithms at the C-level

Work at a level that is abstract from the implementation details, which consume development time.

• Verify at the C-level

Validate the functional correctness of the design more quickly than with traditional hardware descrip-
tion languages.

• Control the C synthesis process through optimization directives

Create specific high-performance hardware implementations.

• Create multiple implementations from the C source code using optimization directives

Explore the design space, which increases the likelihood of finding an optimal implementation.

• Create readable and portable C source code

Retarget the C source into different devices as well as incorporate the C source into new projects.

HLS Phases

High-level synthesis includes the following phases:

• Scheduling

Determines which operations occur during each clock cycle based on:

– Length of the clock cycle or clock frequency

– Time it takes for the operation to complete, as defined by the target device
– User-specified optimization directives
5

If the clock period is longer or a faster FPGA is targeted, more operations are completed within a single
clock cycle, and all operations might complete in one clock cycle. Conversely, if the clock period is shorter
or a slower FPGA is targeted, high-level synthesis automatically schedules the operations over more clock
cycles, and some operations might need to be implemented as multicycle resources.

• Binding

Determines which hardware resource implements each scheduled operation. To implement the optimal
solution, high-level synthesis uses information about the target device.

• Control logic extraction

Extracts the control logic to create a finite state machine (FSM) that sequences the operations in the
RTL design.

1.6 Design steps

This tutorial will be realized step by step with the idea to explain the whole procedure of designing an digital
system, using Vivado HLS tool.

• First, we will develop algorithm at the C-level.

Work at a level that is abstract from the implementation details, which consume development time.

• Then we will verify the algorithm at the C-level.

Validate the functional correctness of the design more quickly than with traditional hardware descrip-
tion languages.

• After that, we will synthesize the C algorithm into an RTL implementation.

Using Vivado HLS tool we will automatically create an RTL implementation of our C algorithm. Vivado
HLS will automatically create data path and control path modules required to implement our algorithm
in hardware.

• Then, we will generate comprehensive reports and analyze the design.

After synthesis, Vivado HLS automatically creates synthesis reports to help you understand the per-
formance of the implementation.

• Then, we verify the RTL implementation

You can use it to verify that the RTL is functionally identical to the original C code.

• At the end, package the RTL implementation into a selection of IP formats.

Using Vivado HLS, you can export the RTL and package the final RTL output files as IP.
 6

Figure 1.3: Design Steps

1.7 Vivado HLS Design Flow

The Xilinx Vivado HLS tool synthesizes a C function into an IP block that you can integrate into a hardware
system. It is tightly integrated with the rest of the Xilinx design tools and provides comprehensive language
support and features for creating the optimal implementation for your C algorithm.

The following Figure shows an overview of the Vivado HLS design flow.
7

Figure 1.4: Vivado HLS Design Flow

Inputs and Outputs

Following are the inputs to Vivado HLS:

• C function written in C, C++, SystemC, or an OpenCL API C kernel

This is the primary input to Vivado HLS. The function can contain a hierarchy of sub-functions.
• Constraints

Constraints are required and include the clock period, clock uncertainty, and FPGA target. The clock
uncertainty defaults to 12.5
• Directives

Directives are optional and direct the synthesis process to implement a specific behavior or optimiza-
tion.
• C test bench and any associated files

Vivado HLS uses the C test bench to simulate the C function prior to synthesis and to verify the RTL
output using C/RTL Cosimulation.

You can add the C input files, directives, and constraints to a Vivado HLS project interactively using the Vivado
HLS graphical user interface (GUI) or using Tcl commands at the command prompt. You can also create a Tcl
file and execute the commands in batch mode.

Following are the outputs from Vivado HLS:

• RTL implementation files in hardware description language (HDL) formats

This is the primary output from Vivado HLS. Using Vivado synthesis, you can synthesize the RTL into
a gate-level implementation and an FPGA bitstream file. The RTL is available in the following industry
standard formats:
– VHDL (IEEE 1076-2000)
 8

– Verilog (IEEE 1364-2001)

Vivado HLS packages the implementation files as an IP block for use with other tools in the Xilinx design
flow. Using logic synthesis, you can synthesize the packaged IP into an FPGA bitstream.

• Report files

This output is the result of synthesis, C/RTL co-simulation, and IP packaging.

Test Bench, Language Support, and C Libraries

In any C program, the top-level function is called main(). In the Vivado HLS design flow, you can specify any
sub-function below main() as the top-level function for synthesis. You cannot synthesize the top-level function
main(). Following are additional rules:

• Only one function is allowed as the top-level function for synthesis.

• Any sub-functions in the hierarchy under the top-level function for synthesis are also synthesized.

• If you want to synthesize functions that are not in the hierarchy under the top-level function for synthesis,
you must merge the functions into a single top-level function for synthesis.

• The verification flow for OpenCL API C kernels requires special handling in the Vivado HLS flow.

Test Bench

When using the Vivado HLS design flow, it is time consuming to synthesize a functionally incorrect C function
and then analyze the implementation details to determine why the function does not perform as expected. To
improve productivity, use a test bench to validate that the C function is functionally correct prior to synthesis.

The C test bench includes the function main() and any sub-functions that are not in the hierarchy under the
top-level function for synthesis. These functions verify that the top-level function for synthesis is functionally
correct by providing stimuli to the function for synthesis and by consuming its output.

Vivado HLS uses the test bench to compile and execute the C simulation. During the compilation process, you
can select the Launch Debugger option to open a full C-debug environment, which enables you to analyze the
C simulation.

Note: Because Vivado HLS uses the test bench to both verify the C function prior to synthesis and to auto-
matically verify the RTL output, using a test bench is highly recommended.

Language Support

Vivado HLS supports the following standards for C compilation/simulation:

• ANSI-C (GCC 4.6)

• C++ (G++ 4.6)

• OpenCL API (1.0 embedded profile)

• SystemC (IEEE 1666-2006, version 2.2)

C, C++, and SystemC Language Constructs

Vivado HLS supports many C, C++, and SystemC language constructs and all native data types for each
language, including float and double types. However, synthesis is not supported for some constructs, including:
9

• Dynamic memory allocation

An FPGA has a fixed set of resources, and the dynamic creation and freeing of memory resources is
not supported.
• Operating system (OS) operations

All data to and from the FPGA must be read from the input ports or written to output ports. OS
operations, such as file read/write or OS queries like time and date, are not supported. Instead, the C
test bench can perform these operations and pass the data into the function for synthesis as function
arguments.

OpenCL API C Language Constructs

Vivado HLS supports the OpenCL API C language constructs and built-in functions from the OpenCL API C
1.0 embedded profile.

C Libraries

C libraries contain functions and constructs that are optimized for implementation in an FPGA. Using these
libraries helps to ensure high quality of results (QoR), that is, the final output is a high-performance design
that makes optimal use of the resources. Because the libraries are provided in C, C++, OpenCL API C, or
SystemC, you can incorporate the libraries into the C function and simulate them to verify the functional
correctness before synthesis.

Vivado HLS provides the following C libraries to extend the standard C languages:
• Arbitrary precision data types
• Half-precision (16-bit) floating-point data types
• Math operations
• Video functions
• Xilinx IP functions, including fast fourier transform (FFT) and finite impulse response (FIR)
• FPGA resource functions to help maximize the use of shift register LUT (SRL) resources

C Libraries Example

C libraries ensure a higher QoR than standard C types. Standard C types are based on 8-bit boundaries (8-bit,
16-bit, 32-bit, 64-bit). However, when targeting a hardware platform, it is often more efficient to use data types
of a specific width.

For example, a design with a filter function for a communications protocol requires 10-bit input data and 18-bit
output data to satisfy the data transmission requirements. Using standard C data types, the input data must
be at least 16-bits and the output data must be at least 32-bits. In the final hardware, this creates a datapath
between the input and output that is wider than necessary, uses more resources, has longer delays (for example,
a 32-bit by 32-bit multiplication takes longer than an 18-bit by 18-bit multiplication), and requires more clock
cycles to complete.

Using an arbitrary precision data type in this design instead, you can specify the exact bit-sizes to be specified
in the C code prior to synthesis, simulate the updated C code, and verify the quality of the output using C
simulation prior to synthesis. Arbitrary precision data types are provided for C and C++ and allow you to
model data types of any width from 1 to 1024-bit. For example, you can model some C++ types up to 32768
bits.

Note: Arbitrary precision types are only required on the function boundaries, because Vivado HLS optimizes
the internal logic and removes data bits and logic that do not fanout to the output ports.
 10

Synthesis, Optimization, and Analysis

Vivado HLS is project based. Each project holds one set of C code and can contain multiple solutions. Each
solution can have different constraints and optimization directives. You can analyze and compare the results
from each solution in the Vivado HLS GUI.

Following are the synthesis, optimization, and analysis steps in the Vivado HLS design process:

1. Create a project with an initial solution.

2. Verify the C simulation executes without error.

3. Run synthesis to obtain a set of results.

4. Analyze the results.

After analyzing the results, you can create a new solution for the project with different constraints and op-
timization directives and synthesize the new solution. You can repeat this process until the design has the
desired performance characteristics. Using multiple solutions allows you to proceed with development while
still retaining the previous results.

Optimization

Using Vivado HLS, you can apply different optimization directives to the design, including:

• Instruct a task to execute in a pipeline, allowing the next execution of the task to begin before the current
execution is complete.

• Specify a latency for the completion of functions, loops, and regions.

• Specify a limit on the number of resources used.

• Override the inherent or implied dependencies in the code and permit specified operations. For example,
if it is acceptable to discard or ignore the initial data values, such as in a video stream, allow a memory
read before write if it results in better performance.

• Select the I/O protocol to ensure the final design can be connected to other hardware blocks with the
same I/O protocol.

Note: Vivado HLS automatically determines the I/O protocol used by any sub-functions. You cannot control
these ports except to specify whether the port is registered.

You can use the Vivado HLS GUI to place optimization directives directly into the source code. Alternatively,
you can use Tcl commands to apply optimization directives.

Analysis

When synthesis completes, Vivado HLS automatically creates synthesis reports to help you understand the
performance of the implementation. In the Vivado HLS GUI, the Analysis Perspective includes the Performance
tab, which allows you to interactively analyze the results in detail.
11

Figure 1.5: Example of performance tab

The Performance tab shows the following for each state:

• C0: The first state includes read operations on ports a, b, and c and the addition operation.
• C1 and C2: The design enters a loop and checks the loop increment counter and exit condition. The
design then reads data into variable x, which requires two clock cycles. Two clock cycles are required,
because the design is accessing a block RAM, requiring an address in one cycle and a data read in the
next.
• C3: The design performs the calculations and writes output to port y. Then, the loop returns to the start.

OpenCL API C Kernel Synthesis

For OpenCL API C kernels, Vivado HLS always synthesizes logic for the entire work group. You cannot apply
the standard Vivado HLS interface directives to an OpenCL API C kernel.

The following OpenCL API C kernel code shows a vector addition design where two arrays of data are summed
into a third. The required size of the work group is 16, that is, this kernel must execute a minium of 16 times
to produce a valid result.

# include < clc .h >

// For VHLS OpenCL C kernels , the full work group is s y n t h e s i z e d

__kernel void __attribute__ (( r e q d _ w o r k _ g r o u p _ s i z e (16 , 1 , 1)))
vadd ( __global int * a ,
__global int * b ,
__global int * c )
{
int idx = get_global_id (0);
c [ idx ] = a [ idx ] + b [ idx ];
}

Vivado HLS synthesizes this design into hardware that performs the following:
• 16 reads from interface a and b
• 16 additions and 16 writes to output interface c

RTL Verification

If you added a C test bench to the project, you can use it to verify that the RTL is functionally identical to the
original C. The C test bench verifies the output from the top-level function for synthesis and returns zero to
the top-level function main() if the RTL is functionally identical. Vivado HLS uses this return value for both
C simulation and C/RTL co-simulation to determine if the results are correct. If the C test bench returns a
non-zero value, Vivado HLS reports that the simulation failed.
 12

Important: Even if the output data is correct and valid, Vivado HLS reports a simulation failure if the test
bench does not return the value zero to function main().

Vivado HLS automatically creates the infrastructure to perform the C/RTL co-simulation and automatically
executes the simulation using one of the following supported RTL simulators:

• Vivado Simulator (XSim)

• ModelSim simulator
• VCS

• NCSim
• Riviera

If you select Verilog or VHDL HDL for simulation, Vivado HLS uses the HDL simulator you specify. The Xilinx
design tools include Vivado Simulator. Third-party HDL simulators require a license from the third-party
vendor. The VCS, NCSim, and Riviera HDL simulators are only supported on the Linux operating system.

RTL Export

Using Vivado HLS, you can export the RTL and package the final RTL output files as IP in any of the following
Xilinx IP formats:
• Vivado IP Catalog

Import into the Vivado IP catalog for use in the Vivado Design Suite.

• Pcore for Embedded Development Kit (EDK)

Import into Xilinx Platform Studio (XPS).

• Synthesized Checkpoint (.dcp)

Import directly into the Vivado Design Suite the same way you import any Vivado Design Suite checkpoint.

Note: The synthesized checkpoint format invokes logic synthesis and compiles the RTL implementation
into a gatelevel implementation, which is included in the IP package.

For all IP formats except the synthesized checkpoint, you can optionally execute logic synthesis from within
Vivado HLS to evaluate the results of RTL synthesis. This optional step allows you to confirm the estimates
provided by Vivado HLS for timing and area before handing off the IP package. These gate-level results are
not included in the packaged IP.

Note: Vivado HLS estimates the timing and area resources based on built-in libraries for each FPGA. When
you use logic synthesis to compile the RTL into a gate-level implementation, perform physical placement of the
gates in the FPGA, and perform routing of the inter-connections between gates, logic synthesis might make
additional optimizations that change the Vivado HLS estimates.
Chapter 2

DEVELOPING CUSTOM IP CORE

USING HLS

In the previous chapter, we have defined the structure of the microprocessor based system that will be used as
a part of the solution of PWM signal generation. In this chapter, we will explain how to generate this system
using Vivado HLS tool.

2.1 Create a New Project

The first step in creating a new HLS design will be to create a new project. We will crate a new project using
the Vivado HLS New Project wizard. The New Project wizard will create an APP project file for us. It will
be place where Vivado HLS will organize our design files and save the design status whenever the processes are
run.

To create a new project:

1. Launch the Vivado HLS software:

Select Start -> All Programs -> Xilinx Design Tools -> Vivado 2017.4 -> Vivado HLS -
> Vivado HLS 2017.4 and the Vivado HLS Welcome Page page will appear, see Figure 2.1.

13
 14

Figure 2.1: The Vivado HLS Welcome Page

As can be seen from the Figure above, the HLS Welcome page contains a lot of usable Quick Start options:

• Create New Project - Launch the project setup wizard.

• Open Project - Navigate to an existing project or select from a list of recent projects.

• Open Example Project - Open Vivado HLS examples.

• Tutorials - Opens the ”Vivado Design Suite Tutorial: High-Level Synthesis” (UG871).

• User Guide - Opens this document, the ”Vivado Design Suite User Guide: High-Level Synthesis”
(UG902).

• Release Notes Guide - Opens the ”Vivado Design Suite User Guide: Release Notes, Installation, and
Licensing” (UG973) for the latest software version.

If any projects were previously opened, they will be shown in the Recent Projects pane, otherwise this window
is not shown in the Welcome screen.

2. In the Vivado HLS Welcome Page page, choose Create New Project option to open the Project
wizard.

3. In the Project Configuration dialog box specify the name and the location of the new project:

• In the Project name field type modulator as the name of the new project

• In the Location field click Browse button to specify the location where project data will be stored,
see Figure 2.2.
15

Figure 2.2: Create a New Vivado Project dialog box

Note: This step is not required when the project is specified as SystemC, because Vivado HLS
automatically identifies the top-level functions.

4. Click Next.

5. In the Add/Remove Files dialog box, specify the C-based design files:

• Specify modulator as the top-level function in the Top Function field, see Figure 2.3.

Figure 2.3: Add/Remove Files dialog box

• Click New File... button and in the Save As dialog box specify modulator.cpp as a new file
name in the File name filed and click Save, see Figure 2.4.
 16

Figure 2.4: Save As dialog box

• After adding new modulator.cpp C++ file, it should appear as a part of the Design Files section,
as it is shown on the Figure 2.5.

Figure 2.5: Save As dialog box

• Click Next.

Note: You can use the Add Files button to add the existing source code files to the project.

Important: Do not add header files (with the .h suffix) to the project using the Add Files button (or
with the associated add files Tcl command).

In this example there is only one C++ design file (modulator.cpp). When there are multiple C files
to be synthesized, you must add all of them to the project at this stage. Any header files that exist in
17

the local directory are automatically included in the project. If the header resides in a different location,
use the Edit CFLAGS... button to add the standard gcc/g++ search path information (for example,
-I<path to header file dir>).

6. In the second Add/Remove Files dialog box, specify the C-based testbench files:

Figure 2.6: Add/Remove Files dialog box

• Click New File... button and in the Save As dialog box specify modulator tb.cpp as a new
testbench file name in the File name filed and click Save, see Figure 2.7.

Figure 2.7: Save As dialog box with testbench file

• After adding the new modulator tb.cpp testbench file, it should appear as a part of the TestBench
Files section, as it is shown on the Figure 2.8.
 18

Figure 2.8: Add/Remove TestBench Files dialog box with added testbench file

• Click Next.

Note: The testbench and all files used by the test bench (except header files) must be included. You can
add files one at a time, or select multiple files to add using the Ctrl and Shift keys.

Note: For SystemC designs with header files associated with the test bench but not the design file, you
must use the Add Files button to add the header files to the project.

In most of the example designs provided with Vivado HLS, the test bench is in a separate file from the
design. Having the test bench and the function to be synthesized in separate files keeps a clean separation
between the process of simulation and synthesis. If the test bench is in the same file as the function to be
synthesized, the file should be added as a source file and a test bench file.

As with the C source files, click the Add Files button to add the C test bench and the Edit CFLAGS
button to include any C compiler options.

If the test bench files exist in a directory, the entire directory might be added to the project, rather than
the individual files, using the Add Folders button.

Both C simulation (and RTL cosimulation) execute in subdirectories of the solution.

If you do not include all the files used by the test bench (for example, data files read by the test bench),
C and RTL simulation might fail due to an inability to find the data files.

The Solution Configuration window (shown on the Figure 2.9) specifies the technical specifications of
the first solution.

A project can have multiple solutions, each using a different target technology, package, constraints,
and/or synthesis directives.

7. In the Solution Configuration dialog box accept the default solution name (solution1), clock period
(10 ns), and blank clock uncertainty (defaults to 12.5% of the clock period, when it is left blank then it
is undefined), see Figure 2.9.
19

Figure 2.9: Solution Configuration dialog box

The the Solution Configuration dialog box allows you to specify the details of the first solution:

• Solution Name: Vivado HLS provides the initial default name solution1, but you can specify any
name for the solution.

• Clock Period: The clock period specified in units of ns or a frequency value specified with the MHz
suffix (for example, 100 MHz).

• Uncertainty: The clock period used for synthesis is the clock period minus the clock uncertainty.
Vivado HLS uses internal models to estimate the delay of the operations for each FPGA. The clock
uncertainty value provides a controllable margin to account for any increases in net delays due to
RTL logic synthesis, place, and route. If not specified in nanoseconds (ns) or a percentage, the clock
uncertainty defaults to 12.5% of the clock period.

• Part: Click to select the appropriate technology, as shown in the following figure.

8. In the Solution Configuration dialog box click the part selection button to open the part selection
window.

You can use the filter to reduce the number of device in the device list. If the target is a board, specify
boards in the top-left corner and the device list is replaced by a list of the supported boards (and Vivado
HLS automatically selects the correct target device).

9. In the Device Selection Dialog dialog box choose a default Xilinx part or board for your project. The
main component of the socius development board is Zynq-7000 AP SoC, so in the Default Part
dialog box select Parts option and set the filter parameters on the same way as it is shown on the Figure
2.10.
 20

Figure 2.10: Device Selection Dialog dialog box

10. Select xc7z020clg400-1 part as it is shown on the figure above and click OK.

In the Solution Configuration dialog box, the selected part name now appears under the Part Selec-
tion heading, see Figure 2.11.

Figure 2.11: Solution Configuration dialog box with selected board

21

11. In the Solution Configuration dialog box, click Finish to open the created Vivado HLS project, see
Figure 2.12.

Figure 2.12: Vivado HLS Project

After we finished with the new project creation, in a few seconds Vivado HLS project will appear, see Figure
2.12.

When Vivado HLS creates a new project, it also creates a directory with the name and at the location that we
specified in the GUI (see Figure 2.2). That means that the all project data will be stored in the project name
(modulator) directory.

In the Vivado HLS project you can notice the following:

• The project name appears on the top line of the Explorer window
• A Vivado HLS project arranges information in a hierarchical form
• The project holds information on the design source, test bench, and solutions
• The solution holds information on the target technology, design directives, and results
• There can be multiple solutions within a project, and each solution is an implementation of the same
source code.

Note: At any time, you can change project or solution settings using the corresponding Project Settings and/or
Solution Settings buttons in the toolbar.

The Vivado HLS GUI consists of four panes:

• Explorer Pane

Shows the project hierarchy. As you proceed through the validation, synthesis, verification, and IP
packaging steps, sub-folders with the results of each step are created automatically inside the solution
directory (named csim, syn, sim, and impl respectively).

When you create new solutions, they appear inside the project hierarchy alongside solution1.
 22

• Information Pane

Shows the contents of any files opened from the Explorer pane. When operations complete, the report file
opens automatically in this pane.

• Auxiliary Pane

Cross-links with the Information pane. The information shown in this pane dynamically adjusts, de-
pending on the file open in the Information pane.

• Console Pane

Shows the messages produced when Vivado HLS runs. Errors and warnings appear in Console pane
tabs.

Figure 2.13: Vivado HLS GUI

In the Vivado HLS GUI you can also find:

• Toolbar Buttons

You can perform the most common operations using the Toolbar buttons.

When you hold the cursor over the button, a popup tool tip opens, explaining the function. Each button
also has an associated menu item available from the pull-down menus.

• Perspectives

The perspectives provide convenient ways to adjust the windows within the Vivado HLS GUI.

– Synthesis Perspective

The default perspective allows you to synthesize designs, run simulations, and package the IP.

– Debug Perspective
23

Includes panes associated with debugging the C code. You can open the Debug Perspective after the
C code compiles (unless you use the Optimizing Compile mode as this disables debug information).

– Analysis Perspective

Windows in this perspective are configured to support analysis of synthesis results. You can use
the Analysis Perspective only after synthesis completes.

2.2 Develop C Algorithm

The first step within an HLS project is to develop a C algorithm for your design. In this tutorial the actual
algorithm will be written in C++ programming language.

As it is already explained in the previous sub-chapter, with the modulator project creation we have already
created two empty C++ files, modulator.cpp and modulator tb.cpp. Now it is time to write their content,
as well as the content of the modulator.h header file that will be stored in the same directory where these two
files are saved.

The content of these three files can be found in the text below.

modulator.cpp

# include " ap_int . h "

# include " math . h "
# include " modulator . h "

// function that c a l c u l a t e s sine wave samples value

void init_sine_ta bl e ( ap_uint < width > * sine )
{
float temp ;

init_sine : for ( int i = 0; i < sine_samples ; i ++)

// sin (2* pi * i / N ) * (2^( width -1) - 1) + 2^( width -1) - 1 , N = 2^ depth
sine [ i ] = ( ap_uint < width >)( sin (2*3.14* i / sine_samples )*( sine_ampl /2.0 -1.0)+ sine_ampl /2.0 -1.0);

// pwm g e n e r a t o r
void modulator (
ap_uint <1 > sw0 , // switch used for s e l e c t i n g f r e q u e n c y
ap_uint <1 > * pwm_out ) // pointer to pwm output
{
static ap_uint < depth > counter = 0; // counter for sine wave sample c o u n t i n g
static ap_uint < width > sine [ sine_samples ]; // samples of the sine wave signal

// sine table i n i t i a l i z a t i o n
init_sine_tab le ( sine );

// hold pwm_out high for s p e c i f i e d number of clock cycles

onloop : for ( ap_uint <20 > j = 0; j < ( ap_uint <20 >)( period [ sw0 ]* sine [ counter ]); j ++)
{
* pwm_out = 1;
}

// hold pwm_out low for s p e c i f i e d number of clock cycles

offloop : for ( ap_uint <20 > j = 0; j < ( ap_uint <20 >)( period [ sw0 ]*( sine_ampl - sine [ counter ])); j ++)
{
* pwm_out = 0;
}

counter ++;
}
 24

modulator tb.cpp

# include < iostream >

# include " ap_int . h "
# include " modulator . h "

using namespace std ;

ap_uint <1 > pwm_out ; // pulse width m o d u l a t e d signal

int main ( int argc , char ** argv )

{
for ( int i = 0; i < 256; i ++)
modulator (0 , & pwm_out );

for ( int i = 0; i < 256; i ++)

modulator (1 , & pwm_out );

return 0;
}

modulator.h

# ifndef __PWM_H__
# define __PWM_H__

# include " ap_int . h "

# include < cmath >
using namespace std ;

# define depth 8 // the number of bits used to r e p r e s e n t sample count of sine wave
# define width 12 // the number of bits used to r e p r e s e n t a m p l i t u d e value

# define sine_samples 256 // maximum number of samples in one period of the signal
# define sine_ampl 4096 // maximum a m p l i t u d e value of the sine wave

# define refclk_f r e q u e n c y 100000000 // r e f e r e n c e clock f r e q u e n c y (100 MHz )

# define freq_low 1 // first f r e q u e n c y for the PWM signal , s p e c i f i e d in Hz

# define freq_high 3.5 // second f r e q u e n c y for the PWM signal , s p e c i f i e d in Hz

// minimum durat i o n of high value of pwm signal for two d i f f e r e n t f r e q u e n c i e s

const float period [2] = {( float )( r e f c l k _ f r e q u e n cy /( sine_ampl * sine_samples * freq_low )) ,
( float )( r e f c l k _f r e q u e n c y /( sine_ampl * sine_samples * freq_high ))};

// P r o t o t y p e of top level f u n c t i o n for C - s y n t h e s i s

void modulator (
ap_uint <1 > sw0 , // switch used for s e l e c t i n g f r e q u e n c y
ap_uint <1 > * pwm_out ); // pointer to pwm output

# endif

To add the content of the modulator.cpp and modulator tb.cpp files, do the following steps:
1. In the Vivado HLS Explorer pane expand Source folder and double-click on the modulator.cpp C++
file to open it, see Figure 2.14.

Figure 2.14: Source folder with modulator.cpp file

2. In the opened modulator.cpp file copy the content of the file from the text above and click Save button.
25

3. Repeat the same procedure for the modulator tb.cpp testbench file. Therefore, in the Vivado HLS
Explorer pane expand Test Bench folder and double-click on the modulator tb.cpp file to open it,
see Figure 2.15.

Figure 2.15: Test Bench folder with modulator tb.cpp file

4. In the opened modulator tb.cpp file copy the content of the file from the text above and click Save
button.

5. For the modulator.h header file creation it is necessary to write it in an text editor and save it in the same
folder where the rest of the files are stored. By doing so, modulator.h header file will be automatically
included in the project and you should find it in the Includes folder of the Explorer pane. The content
of the modulator.h header file you can also find in the text above.

2.3 Verify C Algorithm

The second step within an HLS project is to confirm that the C code is correct. This process is called C
Validation or C Simulation.

Verification in the Vivado HLS flow can be separated into two distinct processes:

1. Pre-synthesis validation that validates the C program correctly implements the required functionality.

2. Post-synthesis verification that verifies the RTL is correct.

Both processes are referred to as simulation: C simulation and C/RTL co-simulation.

Before synthesis, the function to be synthesized should be validated with a test bench using C simulation. A
C test bench includes a top-level function main() and the function to be synthesized. It might include other
functions. An ideal test bench has the following attributes:

• The test bench is self-checking and verifies the results from the function to be synthesized are correct.

• If the results are correct the test bench returns a value of 0 to main(). Otherwise, the test bench should
return any non-zero values.

Vivado HLS synthesizes an OpenCL API C kernel. To simulate an OpenCL API C kernel, you must use a
standard C test bench. You cannot use the OpenCL API C host code as the C test bench.

1. Click the Run C Simulation toolbar button (Figure 2.16) to open the C Simulation dialog box, shown
in the Figure 2.17.
 26

Figure 2.16: Run C Simulation button

Figure 2.17: C Simulation dialog box

The another way to open the C Simulation dialog box is to choose Project -> Run C Simulation
option from the main HLS toolbar menu.

In the C Simulation dialog box you can find the following options:

• Launch Debugger - This option compiles the C code and automatically opens the debug perspec-
tive. From within the debug perspective the Synthesis perspective button (top left) can be used to
return to the synthesis perspective.
• Build Only - This option compiles the C code, but does not run the simulation. Details on executing
the C simulation are covered in ”Reviewing the Output of C Simulation” document.
• Clean Build - This option remove any existing executable and object files from the project before
compiling the code.
• Optimized Compile - By default the design is compiled with debug information, allowing the
compilation to be analyzed in the debug perspective. This option uses a higher level of optimization
effort when compiling the design but removes all information required by the debugger. This increases
the compile time but should reduce the simulation run time.

2. In the C Simulation dialog box, just click OK.

27

If no option is selected in the C Simulation dialog box, the C code is compiled and the C simulation
is automatically executed. The results are shown on the Figure 2.18. When the C code is simulated
successfully, the Console window displays a message.

Figure 2.18: C Simulation dialog box

The design is now ready for synthesis.

Note: If the C simulation ever fails, select the Launch Debugger option in the C Simulation dialog
box, compile the design, and automatically switch to the Debug perspective. There you can use a C
debugger to fix any problems.

2.3.1 C Simulation Output Files

When C simulation completes, a folder csim is created inside the solution1 folder, see Figure 2.19.
 28

Figure 2.19: Explorer window with C Simulation Output Files

The folder csim/build is the primary location for all files related to the C simulation:
• Any files read by the test bench are copied to this folder
• The C executable file csim.exe is created and run in this folder
• Any files written by the test bench are created in this folder.

If the Build Only option is selected in the C Simulation dialog box, the file csim.exe is created in this folder,
but the file is not executed. The C simulation is run manually by executing this file from a command shell. On
Windows the Vivado HLS command shell is available through the start menu.

The folder csim/report contains a log file of the C simulation.

The next step in the Vivado HLS design flow is to execute synthesis.

2.4 Synthesize C Algorithm into an RTL Implementation (High-

Level Synthesis)

In this step, you synthesize the C design into an RTL design and review the synthesis report.

1. Click the Run C Synthesis toolbar button (Figure 2.20) or use the Solution -> Run C Synthe-
sis -> Active Solution option form the main Vivado HLS menu to synthesize the design to an RTL
implementation.

Figure 2.20: Run C Synthesis button

29

During the synthesis process messages are echoed to the console window. The message include information
messages showing how the synthesis process is proceeding. The messages also provide details on the synthesis
process.

When synthesis completes, the synthesis report for the top-level function opens automatically in the Information
pane as shown in the following figure.

Figure 2.21: Information pane with synthesis report

The synthesis report provides details on both the performance and area of the RTL design. The Outline tab
on the righthand side can be used to navigate through the report. In this sub-chapter will be explained only
certain report categories which are important for the current stage of design development.

The detail explanation of all synthesis report categories is presented in the Table 2.1 of sub-chapter 2.4.2 C
Synthesis Results.

2. In the Outline tab click Performance Estimates option, see Figure 2.22.

Figure 2.22: Information pane with synthesis report

 30

In the Performance Estimates pane, expand Timing (ns)/Summary and you can see that the clock period
is set to 10 ns, see Figure 2.23. Vivado HLS targets a clock period of Clock Target minus Clock Uncertainty
(10.00 - 1.25 = 8.75 ns in this example).

Figure 2.23: Performance Estimates report - Timing Summary

The clock uncertainty ensures there is some timing margin available for the (at this stage) unknown net delays
due to place and routing.

The estimated clock period (worst-case delay) is 8.37 ns, which meets the 8.75 ns timing requirement.

In the Performance Estimates pane, expand Latency (clock cycles)/Summary and you can see:

• The design has a latency of ? clock cycles: it takes ? clocks to output the results.

• The interval is ? clock cycles: the next set of inputs is read after ? clocks. This is one cycle after the final
output is written. This indicates the design is not pipelined. The next execution of this function (or next
transaction) can only start when the current transaction completes.

Note: In our design Vivado HLS can’t calculate latency values.

In the Performance Estimates pane, expand Latency (clock cycles)/Detail and you can see:

• There are no sub-blocks in this design. Expanding the Instance section shows no sub-modules in the
hierarchy.

• Expanding the Loop section you can see that all the latency delay is due to the RTL logic synthesized
from the loops named onloop and offloop. This logic executes ? times (Trip Count). Each execution
requires 1 clock cycle (Iteration Latency), for a total of ? clock cycles, to execute all iterations of the logic
synthesized from this loop (Latency).

As we already said, in our design Vivado HLS can’t calculate latency values.
31

Figure 2.24: Performance Estimates report - Loop Latency Detail

3. In the Outline tab click Utilization Estimates option, see Figure 2.22.

Figure 2.25: Utilization Estimates report - Summary

In the Utilization Estimates pane, under the Summary section, you can see:

• The design uses 1 BRAM 18K memory, 3 DSP48E, 727 flip-flops and 1968 LUTs. At this stage, the device
resource numbers are estimates.

• The resource utilization numbers are estimates because RTL synthesis might be able to perform additional
optimizations, and these figures might change after RTL synthesis.

In the Utilization Estimates pane, expand Detail/Instance section and you will see:

Figure 2.26: Utilization Estimates report - Detail Instance

 32

• The resources specified here are used by the sub-blocks instantiated at this level of the hierarchy. Although
our design does not have any hierarchy, Vivado HLS introduced it when performing multiplication of
floating point value and unsigned integer value (see lines 28 and 34 in modulator.cpp source code).
There are two instances created by Vivado HLS:

– modulator fmul 32bkb U1 - used for single precision floating point multiplication and
– modulator sitofp cud U2 - used for converting integer value to floating point value.

For each instance Vivado HLS reports how many resources are necessary to implement it (number of BRAMs,
DSPs, FFs, LUTs).

4. In the Outline tab click Interface option, see Figure 2.22.

Figure 2.27: Interface report - Summary

The Interface report shows the ports and I/O protocols created by interface synthesis:

• The design has a clock and reset port (ap clk and ap rst). These are associated with the Source Object
modulator the design itself.

• There are additional ports associated with the design as indicated by Source Object modulator. Synthesis
has automatically added some block level control ports: ap start, ap done, ap idle, and ap ready.

• The Interface Synthesis tutorial provides more information about these ports.

• Scalar input argument sw0 V is implemented as a data port with no I/O protocol (ap none).

• Finally, the function outputs pwm out V and pwm out V ap vld are 1-bit data ports with an associated
output valid signal indicator pwm out V.

2.4.1 C Synthesis Output Files

When synthesis completes, the folder syn is now available in the solution1 folder.
33

Figure 2.28: Explorer window with C Synthesis Output Files

The syn folder contains 4 sub-folders. A report folder and one folder for each of the RTL output formats.

The report folder contains a report file for the top-level function and one for every sub-function in the design:
provided the function was not inlined using the INLINE directive or inlined automatically by Vivado HLS. The
report for the top-level function provides details on the entire design.

The verilog, vhdl, and systemc folders contain the output RTL files. Figure 2.28 shows all four folders
expanded. The top-level file has the same name as the top-level function for synthesis. In the C design there
is one RTL file for each function (not inlined). There might be additional RTL files to implement sub-blocks
(block RAM, pipelined multipliers, etc).

Important: Xilinx does not recommend using these files for RTL synthesis. Instead, Xilinx recommends using
the packaged IP output files discussed later in this design flow.

In cases where Vivado HLS uses Xilinx IP in the design, such as with floating point designs, the RTL directory
includes a script to create the IP during RTL synthesis. If the files in the syn folder are used for RTL synthesis,
it is your responsibility to correctly use any script files present in those folders. If the package IP is used, this
process is performed automatically by the design Xilinx tools.

2.4.2 C Synthesis Results

The two primary features provided to analyze the RTL design are:

1. Synthesis reports

2. Analysis Perspective
 34

In addition, if you are more comfortable working in an RTL environment, Vivado HLS creates two projects
during the IP packaging process:
• Vivado Design Suite project

• Vivado IP Integrator project

Synthesis Reports

When synthesis completes, the synthesis report for the top-level function opens automatically in the information
pane (Figure 2.21). The report provides details on both the performance and area of the RTL design. The
Outline tab on the right-hand side can be used to navigate through the report.

The following table explains the categories in the synthesis report.

Table 2.1: Synthesis Report Category

Category Desription
General Information Details on when the results were generated, the version of the software
used, the project name, the solution name, and the technology details.
Performance Estimates -> Timing The target clock frequency, clock uncertainty, and the estimate of the
fastest achievable clock frequency.
Performance Estimates -> Latency -> Summary Reports the latency and initiation interval for this block and any sub-
blocks instantiated in this block. Each sub-function called at this level
in the C source is an instance in this RTL block, unless it was inlined.
The latency is the number of cycles it takes to produce the output. The
initiation interval is the number of clock cycles before new inputs can be
applied. In the absence of any PIPELINE directives, the latency is one
cycle less than the initiation interval (the next input is read when the
final output is written).
Performance Estimates -> Latency -> Detail The latency and initiation interval for the instances (sub-functions) and
loops in this block. If any loops contain sub-loops, the loop hierarchy is
shown. The min and max latency values indicate the latency to execute
all iterations of the loop. The presence of conditional branches in the
code might make the min and max different. The Iteration Latency is the
latency for a single iteration of the loop. If the loop has a variable latency,
the latency values cannot be determined and are shown as a question mark
(?). See the text after this table. Any specified target initiation interval is
shown beside the actual initiation interval achieved. The tripcount shows
the total number of loop iterations.
Utilization Estimates -> Summary This part of the report shows the resources (LUTS, Flip-Flops, DSP48s)
used to implement the design.
Utilization Estimates -> Details -> Instance The resources specified here are used by the sub-blocks instantiated at
this level of the hierarchy. If the design only has no RTL hierarchy, there
are no instances reported. If any instances are present, clicking on the
name of the instance opens the synthesis report for that instance.
Utilization Estimates -> Details -> Memory The resources listed here are those used in the implementation of memo-
ries at this level of the hierarchy. Vivado HLS reports a single-port BRAM
as using one bank of memory and reports a dual-port BRAM as using two
banks of memory.
35

Utilization Estimates -> Details -> FIFO The resources listed here are those used in the implementation of any
FIFOs implemented at this level of the hierarchy.
Utilization Estimates -> Details -> Shift Register A summary of all shift registers mapped into Xilinx SRL components.
Additional mapping into SRL components can occur during RTL synthe-
sis.
Utilization Estimates -> Details -> Expressions This category shows the resources used by any expressions such as mul-
tipliers, adders, and comparators at the current level of hierarchy. The
bit-widths of the input ports to the expressions are shown.
Utilization Estimates -> Details -> Multiplexors This section of the report shows the resources used to implement multi-
plexors at this level of hierarchy. The input widths of the multiplexors
are shown.
Utilization Estimates -> Details -> Register A list of all registers at this level of hierarchy is shown here. The report
includes the register bit-widths.
Interface Summary -> Interface This section shows how the function arguments have been synthesized
into RTL ports. The RTL port names are grouped with their protocol
and source object:these are the RTL ports created when that source object
is synthesized with the stated I/O protocol.

Certain Xilinx devices use stacked silicon interconnect (SSI) technology. In these devices, the total available
resources are divided over multiple super logic regions (SLRs). When you select an SSI technology device as
the target technology, the utilization report includes details on both the SLR usage and the total device usage.

Important: When using SSI technology devices, it is important to ensure that the logic created by Vivado HLS
fits within a single SLR. For information on using SSI technology devices.

A common issue for new users of Vivado HLS is seeing a synthesis report similar to the following figure. The
latency values are all shown as a “?” (question mark).

Vivado HLS performs analysis to determine the number of iteration of each loop. If the loop iteration limit is
a variable, Vivado HLS cannot determine the maximum upper limit.

If the latency or throughput of the design is dependent on a loop with a variable index, Vivado HLS reports
the latency of the loop as being unknown (represented in the reports by a question mark “?”).

The TRIPCOUNT directive can be applied to the loop to manually specify the number of loop iterations
and ensure the report contains useful numbers. The -max option tells Vivado HLS the maximum number of
iterations that the loop iterates over, the -min option specifies the minimum number of iterations performed
and the -avg option specifies an average tripcount.

Note: The TRIPCOUNT directive does not impact the results of synthesis.

The tripcount values are used only for reporting, to ensure the reports generated by Vivado HLS show meaningful
ranges for latency and interval. This also allows a meaningful comparison between different solutions.

If the C assert macro is used in the code, Vivado HLS can use it to both determine the loop limits automatically
and create hardware that is exactly sized to these limits.

Analysis Perspective

In addition to the synthesis report, you can use the Analysis Perspective to analyze the results. To open the
Analysis Perspective, click the Analysis button as shown in the following figure.
 36

Figure 2.29: Analysis Perspective Button

The Analysis Perspective provides both a tabular and graphical view of the design performance and resources
and supports cross-referencing between both views. The following figure shows the default window configuration
when the Analysis Perspective is first opened.

Figure 2.30: Default Analysis Perspective in the Vivado HLS GUI

The Module Hierarchy pane provides an overview of the entire RTL design.

• This view can navigate throughout the design hierarchy.

• The Module Hierarchy pane shows the resources and latency contribution for each block in the RTL
hierarchy.

The Performance Profile pane provides details on the performance of the block currently selected in the
Module Hierarchy pane, in this case, the modulator block highlighted in the Module Hierarchy pane.

• The performance of the block is a function of the sub-blocks it contains and any logic within this level
of hierarchy. The Performance Profile pane shows items at this level of hierarchy that contribute to the
overall performance.

• Performance is measured in terms of latency and the initiation interval. This pane also includes details
on whether the block was pipelined or not.

• In this example, you can see that two loops (onloop and offloop) are implemented as logic at this level of
hierarchy.

The Schedule View pane shows how the operations in this particular block are scheduled into clock cycles.
The default view is the Performance view.

• The left-hand column lists the resources.

37

– Sub-blocks are green.

– Operations resulting from loops in the source are coloured yellow.

– Standard operations are purple.

• The modulator has three main parts:

– A call to the init sine table function which initializes sine array,

– A loop called onloop, and

– A loop called offloop.

• The top row lists the control states in the design. Control states are the internal states used by Vivado
HLS to schedule operations into clock cycles. There is a close correlation between the control states and
the final states in the RTL FSM, but there is no one-to-one mapping.

The following figure shows that you can select an operation and right-click the mouse (Goto Source option)
to open the associated variable in the source code view. You can see that the write operation is implementing
the writing of data into the buf array from the input array variable.

Figure 2.31: C Source Code Correlation

The Analysis Perspective also allows you to analyze resource usage. The following figure shows the Resource
profile and the Resource panes.
 38

Figure 2.32: Analysis Perspective with Resource Profile

The Resource Profile pane shows the resources used at this level of hierarchy, see Figure 2.33.

Figure 2.33: Resource Profile pane - Instances and Expressions sections

You can see by expanding the Expression section that the resources at this level of hierarchy are used to
implement 3 subtractors, 5 adders, 2 comparators, 2 shift right operators, 5 select operators and 2 shift left
39

operators.

The Resource pane shows the control state of the operations used, see Figure 2.34. In this example, all the
adder operations are associated with a different adder resource. There is no sharing of the adders. More than
one add operation on each horizontal line indicates the same resource is used multiple times in different states
or clock cycles.

Figure 2.34: Resource pane

The Analysis Perspective is a highly interactive feature. More information on the Analysis Perspective can be
found in the Design Analysis section of the Vivado Design Suite Tutorial, ”High-Level Synthesis (UG871)”.

Note: Even if a Tcl flow is used to create designs, the project can still be opened in the GUI and the Analysis
Perspective used to analyze the design.

Use the Synthesis perspective button to return to the synthesis view.

Generally after design analysis you can create a new solution to apply optimization directives. Using a new
solution for this allows the different solutions to be compared.

2.4.3 Clock, Reset, and RTL Output

The most typical use of Vivado HLS is to create an initial design, then perform optimizations to meet the
desired area and performance goals. Solutions offer a convenient way to ensure the results from earlier synthesis
runs can be both preserved and compared.

1. In the Vivado HLS main toolbar press New Solution button to open the new Solution Configuration
dialog box, see Figure 2.35.
 40

Figure 2.35: New Solution button

The another way to open Solution Configuration dialog box is to use Project -> New Solution option
from the main Vivado HLS menu, see Figure 2.36.

Figure 2.36: New Solution option

The Solution Wizard has the same options as the final window in the New Project wizard (Figure 2.11)
plus an additional option that allow any directives and customs constraints applied to an existing solution to
be conveniently copied to the new solution, where they can be modified or removed.

2. In the Solution Configuration dialog box, leave all parameters unchanged and click Finish, as it is
shown on the Figure 2.37.
41

Figure 2.37: Solution Configuration dialog box

After the new solution has been created, optimization directives can be added (or modified if they were copied
from the previous solution). The next section explains how directives can be added to solutions. Custom
constraints are applied using the configuration options.

2.4.4 Applying Optimization Directives

The first step in adding optimization directives is to open the source code in the Information pane. As shown
in the following figure, expand the Source container located at the top of the Explorer pane, and double-click
the source file (modulator.cpp) to open it for editing in the Information pane.
 42

Figure 2.38: Information pane with opened source code

With the source code active in the Information pane, select the Directive tab on the right to display and
modify directives for the file. The Directive tab contains all the objects and scopes in the currently opened
source code to which you can apply directives.

Note: To apply directives to objects in other C files, you must open the file and make it active in the Infor-
mation pane.

Although you can select objects in the Vivado HLS GUI and apply directives. Vivado HLS applies all directives
to the scope that contains the object. For example, you can apply an INTERFACE directive to an interface
object in the Vivado HLS GUI. Vivado HLS applies the directive to the top-level function (scope), and the
interface port (object) is identified in the directive. In the following example, port data in on function foo is
specified as an AXI4-Lite interface:

s e t _ d i r e c t i v e _ i n t e r f a c e - mode s_axilite " foo " adata_in

You can apply optimization directives to the following objects and scopes:
• Interfaces

When you apply directives to an interface, Vivado HLS applies the directive to the top-level function,
because the top-level function is the scope that contains the interface.
• Functions

When you apply directives to functions, Vivado HLS applies the directive to all objects within the scope of
the function. The effect of any directive stops at the next level of function hierarchy. The only exception
is a directive that supports or uses a recursive option, such as the PIPELINE directive that recursively
unrolls all loops in the hierarchy.
• Loops

When you apply directives to loops, Vivado HLS applies the directive to all objects within the scope
of the loop. For example, if you apply a LOOP MERGE directive to a loop, Vivado HLS applies the
directive to any sub-loops within the loop but not to the loop itself.
43

Note: The loop to which the directive is applied is not merged with siblings at the same level of hi-
erarchy.

• Arrays

When you apply directives to arrays, Vivado HLS applies the directive to the scope that contains the
array.

• Regions

When you apply directives to regions, Vivado HLS applies the directive to the entire scope of the re-
gion. A region is any area enclosed within two braces. For example:

s e t _ d i r e c t i v e _ i n t e r f a c e - mode s_axilite " foo " adata_in

Note: You can apply directives to a region in the same way you apply directives to functions and loops.

1. To apply a directive, select an object in the Directive tab (in our case, sw0), right-click on it and choose
Insert Directive... option to open the Vivado HLS Directives Editor dialog box, see Figure 2.39.

Figure 2.39: Insert Directive option

2. In the Vivado HLS Directives Editor dialog box click on the Directive drop-down menu and select
the appropriate directive, see Figure 2.40.

The drop-down menu shows only directives that you can add to the selected object or scope. For ex-
ample, if you select an array object, the drop-down menu does not show the PIPELINE directive, because
an array cannot be pipelined.
 44

Figure 2.40: Vivado HLS Directives Editor dialog box

In the Vivado HLS Directive Editor dialog box, you can specify either of the following Destination
settings:
• Source File - Vivado HLS inserts the directive directly into the C source file as a pragma.
• Directive File - Vivado HLS inserts the directive as a Tcl command into the file directives.tcl in
the solution directory.

The following table describes the advantages and disadvantages of both approaches.

Table 2.2: Tcl Commands vs Pragmas

Directive Format Advantages Disadvantages

Directives file (Tcl Command) Each solution has independent directives. This If the C source files are transferred to a third-
approach is ideal for design exploration. If any party or archived, the directives.tcl file must
solution is re-synthesized, only the directives be included. The directives.tcl file is required
specified in that solution are applied. if the results are to be re-created.
Source Code (Pragma) The optimization directives are embedded into If the optimization directives are embedded in
the C source code. Ideal when the C sources the code, they are automatically applied to ev-
files are shipped to a third-party as C IP. No ery solution when re-synthesized.
other files are required to recreate the same
results. Useful approach for directives that are
unlikely to change, such as TRIPCOUNT and
INTERFACE.

3. In the Vivado HLS Directive Editor dialog box:

45

• choose INTERFACE as a directive for sw0 input port in the Directive drop-down list
• leave selected Directive File as a Destination
• choose ap none I/O protocol as a mode (optional) option in the Options section
• leave all other parameters unchanged and
• click OK, see Figure 2.41.

Figure 2.41: Vivado HLS Directives Editor dialog box with necessary settings

4. Apply the same directive with the same settings to the pwm out output port and the Directive tab
with applied directives to selected ports looks as it is shown on the Figure 2.42.

Figure 2.42: Directive tab with applied directives

 46

In the following table is presented the complete list of all optimization directives provided by Vivado HLS.

Table 2.3: Vivado HLS Optimization Directives

Directive Format Advantages

ALLOCATION Specify a limit for the number of operations, cores or functions used. This can force the
sharing or hardware resources and may increase latency.
ARRAY MAP Combines multiple smaller arrays into a single large array to help reduce block RAM re-
sources.
ARRAY PARTITION Partitions large arrays into multiple smaller arrays or into individual registers, to improve
access to data and remove block RAM bottlenecks.
ARRAY RESHAPE Reshape an array from one with many elements to one with greater word-width. Useful for
improving block RAM accesses without using more block RAM.
DATA PACK Packs the data fields of a struct into a single scalar with a wider word width.
DATAFLOW Enables task level pipelining, allowing functions and loops to execute concurrently. Used to
minimize interval.
DEPENDENCE Used to provide additional information that can overcome loop-carry dependencies and allow
loops to be pipelined (or pipelined with lower intervals).
EXPRESSION BALANCE Allows automatic expression balancing to be turned off.
FUNCTION INSTANTIATE Allows different instances of the same function to be locally optimized.
INLINE Inlines a function, removing all function hierarchy. Used to enable logic optimization across
function boundaries and improve latency/interval by reducing function call overhead.
INTERFACE Specifies how RTL ports are created from the function description.
LATENCY Allows a minimum and maximum latency constraint to be specified.
LOOP FLATTEN Allows nested loops to be collapsed into a single loop with improved latency.
LOOP MERGE Merge consecutive loops to reduce overall latency, increase sharing and improve logic opti-
mization.
LOOP TRIPCOUNT Used for loops which have variables bounds. Provides an estimate for the loop iteration
count. This has no impact on synthesis, only on reporting.
OCCURRENCE Used when pipelining functions or loops, to specify that the code in a location is executed
at a lesser rate than the code in the enclosing function or loop.
PIPELINE Reduces the initiation interval by allowing the concurrent execution of operations within a
loop or function.
PROTOCOL This commands specifies a region of the code to be a protocol region. A protocol region can
be used to manually specify an interface protocol.
RESET This directive is used to add or remove reset on a specific state variable (global or static).
RESOURCE Specify that a specific library resource (core) is used to implement a variable (array, arithmetic
operation or function argument) in the RTL.
STREAM Specifies that a specific array is to be implemented as a FIFO or RAM memory channel
during dataflow optimization.
UNROLL Unroll for-loops to create multiple independent operations rather than a single collection of
operations.

Applying Optimization Directives to Global Variables

Directives can only be applied to scopes or objects within a scope. As such, they cannot be directly applied to
global variables which are declared outside the scope of any function.
47

To apply a directive to a global variable, apply the directive to the scope (function, loop or region) where the
global variable is used. Open the directives tab on a scope were the variable is used, apply the directive and
enter the variable name manually in Directives Editor.

Applying Optimization Directives to Class Objects

Optimization directives can be also applied to objects or scopes defined in a class. The difference is typically
that classes are defined in a header file. Use one of the following actions to open the header file:

• From the Explorer pane, open the Includes folder, navigate to the header file, and double-click the file
to open it.

• From within the C source, place the cursor over the header file (the #include statement), to open hold
down the Ctrl key, and click the header file.

The directives tab is then populated with the objects in the header file and directives can be applied.

Important: Care should be taken when applying directives as pragmas to a header file. The file might be used
by other people or used in other projects. Any directives added as a pragma are applied each time the header
file is included in a design.

Applying Optimization Directives to Templates

To apply optimization directives manually on templates when using Tcl commands, specify the template argu-
ments and class when referring to class methods. For example, given the following C++ code:

template < uint32 SIZE , uint32 RATE >

void DES10 < SIZE , RATE >:: calcRUN () {...}

The following Tcl command is used to specify the INLINE directive on the function

s e t _ d i r e c t i v e _ i n l i n e DES10 < SIZE , RATE >:: calcRUN

The following section outlines the various optimizations and techniques you can use to direct Vivado HLS to
produce a micro-architecture that satisfies the desired performance and area goals.

2.4.4.1 Clock, Reset, and RTL Output

Clock Frequency

For C and C++ designs only a single clock is supported. The same clock is applied to all functions in the design

For SystemC designs, each SC MODULE may be specified with a different clock. To specify multiple clocks in
a SystemC design, use the -name option of the create clock command to create multiple named clocks and use
the CLOCK directive or pragma to specify which function contains the SC MODULE to be synthesized with
the specified clock. Each SC MODULE can only be synthesized using a single clock. Clocks may be distributed
through functions, such as when multiple clocks are connected from the top-level ports to individual blocks, but
each SC MODULE can only be sensitive to a single clock.

The clock period, in ns, is set in theSolution -> Solution Settings... (main Vivado HLS menu option).
Vivado HLS uses the concept of a clock uncertainty to provide a user defined timing margin. Using the clock
frequency and device target information Vivado HLS estimates the timing of operations in the design but it
cannot know the final component placement and net routing: these operations are performed by logic synthesis
of the output RTL. As such, Vivado HLS cannot know the exact delays.
 48

To calculate the clock period used for synthesis, Vivado HLS subtracts the clock uncertainty from the clock
period, as shown in the following figure.

Figure 2.43: Clock Period and Margin

This provides a user specified margin to ensure downstream processes, such as logic synthesis and place & route,
have enough timing margin to complete their operations. If the FPGA device is mostly utilized the placement
of cells and routing of nets to connect the cells might not be ideal and might result in a design with larger than
expected timing delays. For a situation such as this, an increased timing margin ensures Vivado HLS does not
create a design with too much logic packed into each clock cycle and allows RTL synthesis to satisfy timing in
cases with less than ideal placement and routing options.

By default, the clock uncertainty is 12.5% of the cycle time. The value can be explicitly specified beside the
clock period.

Vivado HLS aims to satisfy all constraints: timing, throughput, latency. However, if a constraints cannot be
satisfied, Vivado HLS always outputs an RTL design.

If the timing constraints inferred by the clock period cannot be met Vivado HLS issues message SCHED-644,
as shown below, and creates a design with the best achievable performance.

@W [ SCHED -644] Max operation delay ( < operation_name > 2.39 ns ) exceeds the effective cycle time

Even if Vivado HLS cannot satisfy the timing requirements for a particular path, it still achieves timing on
all other paths. This behavior allows you to evaluate if higher optimization levels or special handling of those
failing paths by downstream logic syntheses can pull-in and ultimately satisfy the timing.

Important: It is important to review the constraint report after synthesis to determine if all constraints is met.
The fact that Vivado HLS produces an output design does not guarantee the design meets all performance
constraints. Review the “Performance Estimates” section of the design report.

The option relax ii for timing of the config schedule command can be used to change the default timing behavior.
When this option is specified, Vivado HLS automatically relaxes the II for any pipeline directive when it detects
a path is failing to meet the clock period. This option only applies to cases where the PIPELINE directive is
specified without an II value (and an II=1 is implied). If the II value is explicitly specified in the PIPELINE
directive, the relax ii for timing option has no effect.

A design report is generated for each function in the hierarchy when synthesis completes and can be viewed in
the solution reports folder. The worse case timing for the entire design is reported as the worst case in each
function report. There is no need to review every report in the hierarchy.

If the timing violations are too severe to be further optimized and corrected by downstream processes, review
the techniques for specifying an exact latency and specifying exact implementation cores before considering a
faster target technology.
49

Reset

Typically the most important aspect of RTL configuration is selecting the reset behavior. When discussing reset
behavior it is important to understand the difference between initialization and reset.

Initialization Behavior

In C, variables defined with the static qualifier and those defined in the global scope, are by default initialized
to zero. Optionally, these variables may be assigned a specific initial value. For these type of variables, the
initial value in the C code is assigned at compile time (at time zero) and never again. In both cases, the same
initial value is implemented in the RTL.
• During RTL simulation the variables are initialized with the same values as the C code.
• The same variables are initialized in the bitstream used to program the FPGA. When the device powers
up, the variables will start in their initialized state.

The variables start with the same initial state as the C code. However, there is no way to force a return to this
initial state. To return to their initial state the variables must be implemented with a reset.

Controlling the Reset Behavior

The reset port is used in an FPGA to return the registers and block RAM connected to the reset port to an
initial value any time the reset signal is applied. The presence and behavior of the RTL reset port is controlled
using the config rtl configuration.

To access the config rtl configuration:

• In the Vivado HLD Explorer pane, select Solution2, right-click on it and choose Solution Settings...
option,
• In the Solution Settings (solution2) dialog box, select General option and click Add... button to
open RTL Configurations dialog box,
• In the RTL Configurations dialog box click the Command drop down list and choose config rtl
command,
• Leave all other settings unchanged and click OK,
• In the Solution Settings (solution2) dialog box, clok OK.

Important: In our design, we do not need to use reset port, so this config rtl configuration is not needless for
our design!

The reset settings include the ability to set the polarity of the reset and whether the reset is synchronous or
asynchronous but more importantly it controls, through the reset option, which registers are reset when the
reset signal is applied.

Important: When AXI4 interfaces are used on a design the reset polarity is automatically changed to active-Low
irrespective of the setting in the config rtl configuration. This is required by the AXI4 standard.

The reset option has four settings:

• none - No reset is added to the design.
• control - This is the default and ensures all control registers are reset. Control registers are those used
in state machines and to generate I/O protocol signals. This setting ensures the design can immediately
start its operation state.
• state - This option adds a reset to control registers (as in the control setting) plus any registers or
memories derived from static and global variables in the C code. This setting ensures static and global
variable initialized in the C code are reset to their initialized value after the reset is applied.
 50

• all - This adds a reset to all registers and memories in the design.

Finer grain control over reset is provided through the RESET directive. If a variable is a static or global, the
RESET directive is used to explicitly add a reset, or the variable can be removed from those being reset by
using the RESET directive’s off option. This can be particularly useful when static or global arrays are present
in the design.

Initializing and Resetting Arrays

Arrays are often defined as static variables, which implies all elements be initialized to zero, and arrays are
typically implemented as block RAM. When reset options state or all are used, it forces all arrays implemented
as block RAM to be returned to their initialized state after reset. This may result in two very undesirable
attributes in the RTL design:

• Unlike a power-up initialization, an explicit reset requires the RTL design iterate through each address
in the block RAM to set the value: this can take many clock cycles if N is large and require more area
resources to implement.

• A reset is added to every array in the design.

To prevent placing reset logic onto every such block RAM and incurring the cycle overhead to reset all elements
in the RAM:

• Use the default control reset mode and use the RESET directive to specify individual static or global
variables to be reset.

• Alternatively, use reset mode state and remove the reset from specific static or global variables using the
off option to the RESET directive.

RTL Output

Various characteristics of the RTL output by Vivado HLS can be controlled using the config rtl configuration:

• Specify the type of FSM encoding used in the RTL state machines.

• Add an arbitrary comment string, such as a copyright notice, to all RTL files using the -header option.

• Specify a unique name with the prefix option which is added to all RTL output file names.

• Force the RTL ports to use lower case names.

The default FSM coding is style is onehot. Other possible options are auto, binary, and gray. If you select auto,
Vivado HLS implements the style of encoding using the onehot default, but Vivado Design Suite might extract
and re-implement the FSM style during logic synthesis. If you select any other encoding style (binary, onehot,
gray), the encoding style cannot be re-optimized by Xilinx logic synthesis tools.

The names of the RTL output files are derived from the name of the top-level function for synthesis. If different
RTL blocks are created from the same top-level function, the RTL files will have the same name and cannot
be combined in the same RTL project. The prefix option allows RTL files generated from the same top-level
function (and which by default have the same name as the top-level function) to be easily combined in the same
directory. The lower case name option ensures the only lower case names are used in the output RTL. This
option ensures the IO protocol ports created by Vivado HLS, such as those for AXI interfaces, are specified as
s axis <port> tdata in the final RTL rather than the default port name of s axis <port> TDATA.
51

2.4.4.2 Optimizing for Throughput

Use the following optimizations to improve throughput or reduce the initiation interval.

Task Pipelining

Pipelining allows operations to happen concurrently. The task does not have to complete all operations before
it begin the next operation. Pipelining is applied to functions and loops. The throughput improvements in
function pipelining are shown in the following figure.

Figure 2.44: Function Pipelining Behavior

Without pipelining the function reads an input every 3 clock cycles and outputs a value every 2 clock cycles.
The function has an Initiation Interval (II) of 3 and a latency of 2. With pipelining, a new input is read every
cycle (II=1) with no change to the output latency or resources used.

Loop pipelining allows the operations in a loop to be implemented in a concurrent manner as shown in the
following figure. In this figure, (a) shows the default sequential operation where there are 3 clock cycles between
each input read (II=3), and it requires 8 clock cycles before the last output write is performed.

In the pipelined version of the loop shown in (b), a new input sample is read every cycle (II=1) and the final
output is written after only 4 clock cycles: substantially improving both the II and latency while using the same
hardware resources.
 52

Figure 2.45: Loop Pipelining Behavior

Tasks are pipelined using the PIPELINE directive. The initiation interval defaults to 1 if not specified but may
be explicitly specified.

Pipelining is applied to the specified task not to the hierarchy below: all loops in the hierarchy below are auto-
matically unrolled. Any sub-functions in the hierarchy below the specified task must be pipelined individually.
If the sub-functions are pipelined, the pipelined tasks above it can take advantage of the pipeline performance.
Conversely, any sub-function below the pipelined task that is not pipelined, may be the limiting factor in the
performance of the pipeline.

There is a difference in how pipelined functions and loops behave:

• In the case of functions, the pipeline runs forever and never ends.
• In the case of loops, the pipeline executes until all iterations of the loop are completed.

Partitioning Arrays to Improve Pipelining

Pipelining increases the throughput of the system, but sometimes existing data interface do not have sufficient
data throughput to transmit all the necessary data to the data processing system. In this case pipelining
system works under their possibilities and pipelining effects of the limited. This issue is typically caused by
arrays. Arrays are implemented as block RAM which only has a maximum of two data ports. This can limit the
throughput of a read/write (or load/store) intensive algorithm. The bandwidth can be improved by splitting the
array (a single block RAM resource) into multiple smaller arrays (multiple block RAMs), effectively increasing
the number of ports.

Arrays are partitioned using the ARRAY PARTITION directive. Vivado HLS provides three types of array
partitioning, as shown in the following figure. The three styles of partitioning are:
• block - The original array is split into equally sized blocks of consecutive elements of the original array.
53

• cyclic - The original array is split into equally sized blocks interleaving the elements of the original array.

• complete - The default operation is to split the array into its individual elements. This corresponds to
resolving a memory into registers.

Figure 2.46: Array Partitioning

For block and cyclic partitioning the factor option specifies the number of arrays that are created. In the
preceding figure, a factor of 2 is used, that is, the array is divided into two smaller arrays. If the number of
elements in the array is not an integer multiple of the factor, the final array has fewer elements.

When partitioning multi-dimensional arrays, the dimension parameter is used to specify which dimension is
partitioned. The following code shows how the dimension parameter is used to partition the following example
code:

void example (...) {

int my_array [10][6][4];
...
}

The example demonstrates how partitioning dimension 3 results in 4 separate arrays and partitioning dimension
1 results in 10 separate arrays. If zero is specified as the dimension, all dimensions are partitioned.

my_array [10][6][4] -> ARRAY_PARTITION , mode = compete , partition dimension = 3 -> my_array_0 [10][6]
my_array_1 [10][6]
my_array_2 [10][6]
my_array_3 [10][6]
my_array [10][6][4] -> ARRAY_PARTITION , mode = compete , partition dimension = 1 -> my_array_0 [6][4]
my_array_1 [6][4]
my_array_2 [6][4]
my_array_3 [6][4]
my_array_4 [6][4]
my_array_5 [6][4]
my_array_6 [6][4]
my_array_7 [6][4]
my_array_8 [6][4]
my_array_9 [6][4]
my_array [10][6][4] -> ARRAY_PARTITION , mode = compete , partition dimension = 0 -> 10 x6x4 =240 registers

The config array partition configuration determines how arrays are automatically partitioned based on the
number of elements. This configuration is accessed through the Vivado HLS menu Solution -> Solution
Settings -> General -> Add -> config array partition.

The partition thresholds can be adjusted and partitioning can be fully automated with the throughput driven
option. When the throughput driven option is selected Vivado HLS automatically partitions arrays to achieve
the specified throughput.

Loop Unrolling to Improve Pipelining

 54

By default loops are kept rolled in Vivado HLS. That is to say that the loops are treated as a single entity: all
operations in the loop are implemented using the same hardware resources for iteration of the loop.

Vivado HLS provides the ability to unroll or partially unroll for-loops using the UNROLL directive.

The following figure shows both the powerful advantages of loop unrolling and the implications that must be
considered when unrolling loops. This example assumes the arrays a[i], b[i] and c[i] are mapped to block RAMs.
This example shows how easy it is to create many different implementations by the simple application of loop
unrolling.

Figure 2.47: Loop Unrolling Details

• Rolled Loop - When the loop is rolled, each iteration is performed in a separate clock cycle. This
implementation takes four clock cycles, only requires one multiplier and each block RAM can be a single-
port block RAM.
• Partially Unrolled Loop - In this example, the loop is partially unrolled by a factor of 2. This
implementation required two multipliers and dual-port RAMs to support two reads or writes to each
RAM in the same clock cycle. This implementation does however only take 2 clock cycles to complete:
half the initiation interval and half the latency of the rolled loop version.
• Unrolled Loop - In the fully unrolled version all loop operation can be performed in a single clock cycle.
This implementation however requires four multipliers. More importantly, this implementation requires
the ability to perform 4 reads and 4 write operations in the same clock cycle. Because a block RAM only
has a maximum of two ports, this implementation requires the arrays be partitioned.

To perform loop unrolling, you can apply the UNROLL directives to individual loops in the design. Alternatively,
you can apply the UNROLL directive to a function, which unrolls all loops within the scope of the function.
55

If a loop is completely unrolled, all operations will be performed in parallel: if data dependencies allow. If
operations in one iteration of the loop require the result from a previous iteration, they cannot execute in
parallel but will execute as soon as the data is available. A completely unrolled loop will mean multiple copies
of the logic in the loop body.

Partial loop unrolling does not require the unroll factor to be an integer multiple of the maximum iteration
count. Vivado HLS adds an exit checks to ensure partially unrolled loops are functionally identical to the
original loop. For example, given the following code:

for ( int i = 0; i < N ; i ++) {

a [ i ] = b [ i ] + c [ i ];
}

Loop unrolling by a factor of 2 effectively transforms the code to look like the following example where the
break construct is used to ensure the functionality remains the same:

for ( int i = 0; i < N ; i ++) {

a [ i ] = b [ i ] + c [ i ];
if ( i +1 >= N ) break ;
a [ i +1]= b [ i +1]+ c [ i +1];
}

Because N is a variable, Vivado HLS may not be able to determine its maximum value (it could be driven from
an input port). If you know the unrolling factor, 2 in this case, is an integer factor of the maximum iteration
count N, the skip exit check option removes the exit check and associated logic. The effect of unrolling can now
be represented as:

for ( int i = 0; i < N ; i ++) {

a [ i ] = b [ i ] + c [ i ];
a [ i +1] = b [ i +1] + c [ i +1];
}

This helps minimize the area and simplify the control logic.

2.4.4.3 Optimizing for Latency

In order to reduce delays in the data processing (latency) within RTL system, that is the result of the HLS
synthesis using Vivad HLS tool, it is necessary to use the following optimization directives:

• Latency Constraints

• Loop Merging

• Loop Flattening

Latency Constraints

Vivado HLS supports the use of a latency constraint on any scope. Latency constraints are specified using the
LATENCY directive.

When a maximum and/or minimum LATENCY constraint is placed on a scope, Vivado HLS tries to ensure all
operations in the function complete within the range of clock cycles specified.

The LATENCY directive applied to a loop specifies the required latency for a single iteration of the loop. It
specifies the latency for the loop body, as the following examples shows:
 56

for ( int i =0; i < N ; i ++) {

# pragma HLS latency max =10
.. Loop Body ...
}

This example contains LATENCY directive which specifies that the maximum duration of the body loop exe-
cution is not greater than 10 cycles clock signal.

If the intention is to limit the total latency of all loop iterations, the latency directive should be applied to a
region that encompasses the entire loop, as in this example:

Region_Loop : {
# pragma HLS latency max =10
for ( int i =0; i < N ; i ++)
{
.. Loop Body ...
}
}

In this case, even if the loop is unrolled, the latency directive sets a maximum limit on all loop operations.

If Vivado HLS cannot meet a maximum latency constraint it relaxes the latency constraint and tries to achieve
the best possible result.

If a minimum latency constraint is set and Vivado HLS can produce a design with a lower latency than the
minimum required it inserts dummy clock cycles to meet the minimum latency.

Loop Merging

All rolled loops imply and create at least one state in the design FSM. When there are multiple sequential loops
it can create additional unnecessary clock cycles and prevent further optimizations.

The following figure shows a simple example where a seemingly intuitive coding style has a negative impact on
the performance of the RTL design.

Figure 2.48: Loop Directives

On the Figure 2.48, ”Without Loop Merging” shows how, by default, each rolled loop in the design creates
at least one state in the FSM. Moving between those states costs clock cycles: assuming each loop iteration
requires one clock cycle, it take a total of 11 cycles to execute both loops:
• 1 clock cycle to enter the add loop.
57

• 4 clock cycles to execute the add loop.

• 1 clock cycle to exit add and enter sub.

• 4 clock cycles to execute the sub loop.

• 1 clock cycle to exit the sub loop.

• For a total of 11 clock cycles.

In this simple example it is obvious that an else branch in the ADD loop would also solve the issue but in a
more complex example it may be less obvious and the more intuitive coding style may have greater advantages.

The LOOP MERGE optimization directive is used to automatically merge loops. The LOOP MERGE directive
will seek so to merge all loops within the scope it is placed. In the above example, merging the loops creates a
control structure similar to that shown in (B) in the preceding figure, which requires only 6 clocks to complete.

Merging loops allows the logic within the loops to be optimized together. In the example above, using a
dual-port block RAM allows the add and subtraction operations to be performed in parallel.

Loop Flattening

In a similar manner to the consecutive loops discussed in the previous section, it requires additional clock cycles
to move between rolled nested loops. It requires one clock cycle to move from an outer loop to an inner loop
and from an inner loop to an outer loop.

The following example illustrates how, if no care is taken one may spend an additional 200 clock cycles to these
processes when executing external loop.

void func { int a , int b , int c , int d }

{
...
outer_loop : while (j <100) {
inner_loop : while (i <6) { // 1 cycle to enter inner
...
LOOP_BODY
...
} // 1 cycle to exit inner
}
...
}

Vivado HLS provides the set directive loop flatten command to allow labeled perfect and semi-perfect nested
loops to be flattened, removing the need to re-code for optimal hardware performance and reducing the number
of cycles it takes to perform the operations in the loop.

• Perfect loop nest - only the innermost loop has loop body content, there is no logic specified between
the loop statements and all the loop bounds are constant.

• Semi-perfect loop nest - only the innermost loop has loop body content, there is no logic specified
between the loop statements but the outermost loop bound can be a variable.

For imperfect loop nests, where the inner loop has variables bounds or the loop body is not exclusively inside
the inner loop, designers should try to restructure the code, or unroll the loops in the loop body to create a
perfect loop nest.

2.4.4.4 Optimizing for Area

In order to reduce hardware resources needed to implement the RTL system which generates in HLS process
using HSL Vivado tools, it is necessary to use the following optimization directives:
 58

• Bit-Width Narrowing
• Function Inlining
• Array Mapping
• Array Reshaping
• Resource Allocation

Bit-Width Narrowing

The bit-widths of the variables in the C function directly impact the size of the storage elements and operators
used in the RTL implementation. If a variables only requires 12-bits but is specified as an integer type (32-bit)
it will result in larger and slower 32-bit operators being used, reducing the number of operations that can be
performed in a clock cycle and potentially increasing initiation interval and latency.
• Use the appropriate precision for the data types.
• Confirm the size of any arrays that are to be implemented as RAMs or registers. The area impact of any
over-sized elements is wasteful in hardware resources.
• Pay special attention to multiplications, divisions, modulus or other complex arithmetic operations. If
these variables are larger than they need to be, they negatively impact both area and performance.

Function Inlining

Function inlining removes the function hierarchy. A function is inlined using the INLINE directive.

Inlining a function may improve area by allowing the components within the function to be better shared or
optimized with the logic in the calling function. This type of function inlining is also performed automatically
by Vivado HLS. Small functions are automatically inlined.

Inlining allows functions sharing to be better controlled. For functions to be shared they must be used within
the same level of hierarchy. In this code example, function top calls f1 twice and function fsub.

fsub ( int p , int q )

{
int q1 = q + 10;
f1 ( p1 , q ); // the third i n s t a n c e of f1 f u n c t i o n
...
}

void top { int a , int b , int c , int d }

{
...
f1 (a , b ); // the first i n s t a n c e of f1 f u n c t i o n
f1 (a , c ); // the second i n s t a n c e of f1 f u n c t i o n
fsub (a , d );
...
}

Inlining function fsub and using the ALLOCATION directive to specify only 1 instance of function fsub is used,
results in a design which only has one instance of function fsub: one-third the area of the example above.

fsub ( int p , int q )

{
# pragma HLS INLINE
int q1 = q + 10;
f1 ( p1 , q );
...
}
void top { int a , int b , int c , int d }
{
# pragma HLS ALLOCATION instances = f1 limit =1 function
...
59

f1 (a , b );
f1 (a , c );
fsub (a , d );
...
}

The INLINE directive optionally allows all functions below the specified function to be recursively inlined by
using the recursive option. If the recursive option is used on the top-level function, all function hierarchy in the
design is removed.

The INLINE off option can optionally be applied to functions to prevent them being inlined. This option/em
may be used to prevent Vivado HLS from automatically inlining a function.

The INLINE directive is a powerful way to substantially modify the structure of the code without actually per-
forming any modifications to the source code and provides a very powerful method for architectural exploration.

Array Mapping

When there are many small arrays in the C Code, mapping them into a single larger array typically reduces
the number of block RAM required.

Each array is mapped into a block RAM. The basic block RAM unit provide in an FPGA is 18K. If many small
arrays do not use the full 18K, a better use of the block RAM resources is map many of the small arrays into
a larger array. If a block RAM is larger than 18K, they are automatically mapped into multiple 18K units. In
the synthesis report, review Utilization Report -> Details -> Memory for a complete understanding of
the block RAMs in your design.

The ARRAY MAP directive supports two ways of mapping small arrays into a larger one:
• Horizontal mapping - corresponds to creating a new array by concatenating the original arrays. Phys-
ically, this gets implemented as a single array with more elements.
• Vertical mapping - corresponds to creating a new array by concatenating the original words in the
array. Physically, this gets implemented by a single array with a larger bit-width.

Horizontal Array Mapping

The following code example has two arrays that would result in two RAM components.

void func (...) {

int8 array1 [ M ];
int12 array2 [ N ];
...

loop_1 : for ( i =0; i < M ; i ++) {

array1 [ i ] = ...;
array2 [ i ] = ...;
...
}
...
}

Arrays array1 and array2 can be combined into a single array, specified as array3 in the following example:

void func (...) {

int8 array1 [ M ];
int12 array2 [ N ];

# pragma HLS ARRAY_MAP variable = array1 instance = array3 horizontal

# pragma HLS ARRAY_MAP variable = array2 instance = array3 horizontal
...

loop_1 : for ( i =0; i < M ; i ++) {

array1 [ i ] = ...;
array2 [ i ] = ...;
 60

...
}
...
}

In this example, the ARRAY MAP directive transforms the arrays as shown in the following figure.

Figure 2.49: Horizontal Array Mapping

When using horizontal mapping, the smaller arrays are mapped into a larger array. The mapping starts at
location 0 in the larger array and follows in the order the commands are specified. In the Vivado HLS GUI,
this is based on the order the arrays are specified using the menu commands. In the Tcl environment, this is
based on the order the commands are issued.

When you use the horizontal mapping shown in Figure 2.50, the implementation in the block RAM appears as
shown in the following figure.

Figure 2.50: Memory for Horizontal Mapping

Vertical Array Mapping

In vertical mapping, arrays are concatenated by to produce an array with higher bit-widths.Vertical mapping
is applied using the vertical option to the INLINE directive. The following figure shows how the same example
as before transformed when vertical mapping mode is applied.

void func (...) {

int8 array1 [ M ];
int12 array2 [ N ];

# pragma HLS ARRAY_MAP variable = array2 instance = array3 vertical

# pragma HLS ARRAY_MAP variable = array1 instance = array3 vertical
...

loop_1 : for ( i =0; i < M ; i ++) {

array1 [ i ] = ...;
array2 [ i ] = ...;
...
}
...
}
61

The structure of the array3 array, which is the result of vertical mapping array1 and array2 arrays is shown
on the Figure 2.51.

Figure 2.51: Vertical Array Mapping

In vertical mapping, the arrays are concatenated in the order specified by the command, with the first arrays
starting at the LSB and the last array specified ending at the MSB. After vertical mapping the newly formed
array, is implemented in a single block RAM component as shown in the following figure.

Figure 2.52: Memory for Vertical Mapping

Vertical Array Mapping

The ARRAY RESHAPE directive combines ARRAY PARTITIONING with the vertical mode of ARRAY MAP
and is used to reduce the number of block RAM while still allowing the beneficial attributes of partitioning:
parallel access to the data.

Given the following example code:

void func (...) {

int array1 [ N ];
int array2 [ N ];
int array3 [ N ];

# pragma HLS ARRAY_RESHAPE variable = array1 block factor =2 dim =1

# pragma HLS ARRAY_RESHAPE variable = array2 cycle factor =2 dim =1
# pragma HLS ARRAY_RESHAPE variable = array3 complete dim =1
...
}

The ARRAY RESHAPE directive transforms the arrays into the form shown in the following figure.
 62

Figure 2.53: Array Reshaping

The ARRAY RESHAPE directive allows more data to be accessed in a single clock cycle. In cases where
more data can be accessed in a single clock cycle, Vivado HLS may automatically unroll any loops consuming
this data, if doing so will improve the throughput. The loop can be fully or partially unrolled to create enough
hardware to consume the additional data in a single clock cycle. This feature is controlled using the config unroll
command and the option tripcount threshold. In the following example, any loops with a tripcount of less than
16 will be automatically unrolled if doing so improves the throughput.

config_unroll - t r i p c o u n t _ t h r e s h o l d 16

Resource Allocation

During synthesis Vivado HLS performs the following basic tasks:

• First, elaborates the C, C++ or SystemC source code into an internal database containing operators.

The operators represent operations in the C code such as additions, multiplications, array reads, and
writes.

• Then, maps the operators on to cores which implement the hardware operations.

Cores are the specific hardware components used to create the design (such as adders, multipliers, pipelined
multipliers, and block RAM).

Control is provided over each of these steps, allowing you to control the hardware implementation at a fine level
of granularity.

Limiting the Number of Operators

Explicitly limiting the number of operators to reduce area may be required in some cases: the default operation
of Vivado HLS is to first maximize performance. Limiting the number of operators in a design is a useful
technique to reduce the area: it helps reduce area by forcing sharing of the operations.
63

The ALLOCATION directive allows you to limit how many operators, or cores or functions are used in a
design. For example, if a design called foo has 317 multiplications but the FPGA only has 256 multiplier
resources (DSP48s). The ALLOCATION directive shown below directs Vivado HLS to create a design with
maximum of 256 multiplication (mul) operators:

int32 mac_unit ( int16 d [317]) {

static int32 mac ;
int i ;
# pragma HLS ALLOCATION instances = mul limit =256 operation
for ( i =0; i <300; i ++) {
# pragma HLS UNROLL
mac += mac * d [ i ];
}
rerun mac ;
}

You can use the type option to specify if the ALLOCATION directives limits operations, cores, or functions.
The following table lists all the operations that can be controlled using the ALLOCATION directive.

Table 2.4: Vivado HLS Operators

Operator Description
add Integer Addition
ashr Arithmetic Shift-Right
dadd Double-precision floating point addition
dcmp Double-precision floating point comparison
ddiv Double-precision floating point division
dmul Double-precision floating point multiplication
drecip Double-precision floating point reciprocal
drem Double-precision floating point remainder
drsqrt Double-precision floating point reciprocal square root
dsub Double-precision floating point subtraction
dsqrt Double-precision floating point square root
fadd Single-precision floating point addition
fcmp Single-precision floating point comparison
fdiv Single-precision floating point division
fmul Single-precision floating point multiplication
frecip Single-precision floating point reciprocal
frem Single-precision floating point remainder
frsqrt Single-precision floating point reciprocal square root
fsub Single-precision floating point subtraction
fsqrt Single-precision floating point square root
icmp Integer Compare
lshr Logical Shift-Right
mul Multiplication
sdiv Signed Divider
shl Shift-Left
srem Signed Remainder
sub Subtraction
udiv Unsigned Division
urem Unsigned Remainder
 64

Controlling the Hardware Cores

When synthesis is performed, Vivado HLS uses the timing constraints specified by the clock, the delays specified
by the target device together with any directives specified by you, to determine which core is used to implement
the operators. For example, to implement a multiplier operation Vivado HLS could use the combinational
multiplier core or use a pipeline multiplier core.

The cores which are mapped to operators during synthesis can be limited in the same manner as the operators.
Instead of limiting the total number of multiplication operations, you can choose to limit the number of combi-
national multiplier cores, forcing any remaining multiplications to be performed using pipelined multipliers (or
vice versa). This is performed by specifying the ALLOCATION directive type option to be core.

The RESOURCE directive is used to explicitly specify which core to use for specific operations. In the following
example, a 2-stage pipelined multiplier is specified to implement the multiplication for variable The following
command informs Vivado HLS to use a 2-stage pipelined multiplier for variable c. It is left to Vivado HLS
which core to use for variable d.

int func ( int a , int b ) {

int c , d ;

# pragma HLS RESOURCE variable = c latency =2

c = a*b;
d = a*c;

return d ;
}

In the following example, the RESOURCE directives specify that the add operation for variable temp and is
implemented using the AddSub DSP core. This ensures that the operation is implemented using a DSP48
primitive in the final design by default, add operations are implemented using LUTs.

void apint_arith ( int16 inA , int16 inB , int17 * out1 ) {

int17 temp ;
# pragma HLS RESOURCE variable = temp core = AddSub_DSP
temp = inB + inA ;
out1 = temp ;
}

The following table lists the cores used to implement standard RTL logic operations (such as add, multiply, and
compare).

Table 2.5: Functional Cores

Core Description
AddSub This core is used to implement both adders and subtractors.
AddSubnS N-stage pipelined adder or subtractor. Vivado HLS determines how many pipeline stages are
required.
AddSub DSP This core ensures that the add or sub operation is implemented using a DSP48 (Using the
adder or subtractor inside the DSP48).
DivnS N-stage pipelined divider.
DSP48 Multiplications with bit-widths that allow implementation in a single DSP48 macrocell. This
can include pipelined multiplications and multiplications grouped with a pre-adder, post-
adder, or both. This core can only be pipelined with a maximum latency of 4. Values above
4 saturate at 4.
Mul Combinational multiplier with bit-widths that exceed the size of a standard DSP48 macrocell.
Note: Multipliers that can be implemented with a single DSP48 macrocell are mapped to
the DSP48 core.
65

MulnS N-stage pipelined multiplier with bit-widths that exceed the size of a standard DSP48 macro-
cell. Note: Multipliers that can be implemented with a single DSP48 macrocell are mapped
to the DSP48 core.
Mul LUT Multiplier implemented with LUTs.

The following table lists the cores used to implement storage elements, such as registers or memories.

Table 2.6: Storage Cores

Core Description
FIFO A FIFO. Vivado HLS determines whether to implement this in the RTL with a block RAM
or as distributed RAM.
FIFO BRAM A FIFO implemented with a block RAM.
FIFO LUTRAM A FIFO implemented as distributed RAM.
FIFO SRL A FIFO implemented as with an SRL.
RAM 1P A single-port RAM. Vivado HLS determines whether to implement this in the RTL with a
block RAM or as distributed RAM.
RAM 1P BRAM A single-port RAM implemented with a block RAM.
RAM 1P LUTRAM A single-port RAM implemented as distributed RAM.
RAM 2P A dual-port RAM that allows read operations on one port and both read and write operations
on the other port. Vivado HLS determines whether to implement this in the RTL with a
block RAM or as distributed RAM.
RAM 2P BRAM A dual-port RAM implemented with a block RAM that allows read operations on one port
and both read and write operations on the other port.
RAM 2P LUTRAM A dual-port RAM implemented as distributed RAM that allows read operations on one port
and both read and write operations on the other port.
RAM S2P BRAM A dual-port RAM implemented with a block RAM that allows read operations on one port
and write operations on the other port.
RAM S2P LUTRAM A dual-port RAM implemented as distributed RAM that allows read operations on one port
and write operations on the other port.
RAM T2P BRAM A true dual-port RAM with support for both read and write on both ports implemented
with a block RAM.
ROM 1P A single-port ROM. Vivado HLS determines whether to implement this in the RTL with a
block RAM or with LUTs.
ROM 1P BRAM A single-port ROM. Vivado HLS determines whether to implement this in the RTL with a
block RAM or with LUTs.
ROM nP BRAM A multi-port ROM implemented with a block RAM. Vivado HLS automatically determines
the number of ports.
ROM 1P LUTRAM A single-port ROM implemented with distributed RAM.
ROM nP LUTRAM A multi-port ROM implemented with distributed RAM. Vivado HLS automatically deter-
mines the number of ports.
ROM 2P A dual-port ROM. Vivado HLS determines whether to implement this in the RTL with a
block RAM or as distributed ROM.
ROM 2P BRAM A dual-port ROM implemented with a block RAM.
ROM 2P LUTRAM A dual-port ROM implemented as distributed ROM.
 66

XPM MEMORY Specifies the array is to be implemented with an UltraRAM. This core is only usable with
devices supporting UltraRAM blocks.

The RESOURCE directives uses the assigned variable as the target for the resource. If the assignment specifies
multiple identical operators, the code must be modified to ensure there is a single variable for each operator to
be controlled.

2.5 Verify the RTL Implementation

Post-synthesis verification is automated through the C/RTL co-simulation feature which reuses the pre-synthesis
C test bench to perform verification on the output RTL.

C/RTL co-simulation uses the C test bench to automatically verify the RTL design. The verification process
consists of three phases:

1. The C simulation is executed and the inputs to the top-level function, or the Device-Under-Test (DUT),
are saved as “input vectors”.

2. The “input vectors” are used in an RTL simulation using the RTL created by Vivado HLS. The outputs
from the RTL are save as “output vectors”.

3. The “output vectors” from the RTL simulation are applied to C test bench, after the function for synthesis,
to verify the results are correct. The C test bench performs the verification of the results.

The following messages are output by Vivado HLS to show the progress of the verification.

C simulation:

[ SIM -14] Instrumenting C test bench ( wrapc )

[ SIM -302] Generating test vectors ( wrapc )

At this stage, since the C simulation was executed, any messages written by the C test bench will be output in
console window or log file.

RTL simulation:

[ SIM -333] Generating C post check test bench

[ SIM -12] Generating RTL test bench
[ SIM -323] Starting Verilog simulation ( Issued when Verilog is the RTL verified )
[ SIM -322] Starting VHDL simulation ( Issued when VHDL is the RTL verified )

At this stage, any messages from the RTL simulation are output in console window or log file.

C test bench results checking:

[ SIM -316] Starting C post checking

[ SIM -1000] C / RTL co - simulation finished : PASS ( If test bench returns a 0)
[ SIM -4] C / RTL co - simulation finished : FAIL ( If the test bench returns non - zero )

The following Figure 2.54 shows the RTL verification flow.

67

Figure 2.54: RTL Verification Flow

The following is required to use C/RTL co-simulation feature successfully:

• The test bench must be self-checking and return a value of 0 if the test passes or returns a non-zero value
if the test fails.

• The correct interface synthesis options must be selected.

• Any 3rd-party simulators must be available in the search path.

• Any arrays or structs on the design interface cannot use the optimization directives or combinations of
optimization directives.

To verify the RTL design produces the same results as the original C code, use a self-checking test bench to
execute the verification. The following code example shows the important features of a self-checking test bench:

int main () {
int ret =0;
...
// Execute ( DUT ) F u n c t i o n
...

// Write the output results to a file

...

// Check the results

ret = system ( " diff -- brief -w output . dat output . golden . dat " );

if ( ret != 0) {
printf ( " Test failed !!! nn " );
ret =1;
}
else {
printf ( " Test passed ! nn " );
}
...
return ret ;
}

This self-checking test bench compares the results against known good results in the output.golden.dat file.

In the Vivado HLS design flow, the return value to function main() indicates the following:

• Zero: Results are correct.

• Non-zero value: Results are incorrect

Note: The test bench can return any non-zero value. A complex test bench can return different val-
ues depending on the type of difference or failure. If the test bench returns a non-zero value after C
simulation or C/RTL co-simulation, Vivado HLS reports an error and simulation fails.
 68

Constrain the return value to an 8-bit range for portability and safety, because the system environment
interprets the return value of the main() function.

If the test bench does not check the results but returns zero, Vivado HLS indicates that the simulation test
passed even though the results were not actually checked.

After ensuring that the preceding requirements are met, you can use C/RTL co-simulation to verify the RTL
design using Verilog or VHDL. The default simulation language is Verilog, but you can also specify VHDL.
While the default simulator is Vivado Simulator (XSim), you can use any of the following simulators to run
C/RTL co-simulation:

• Vivado Simulator (XSim)

• ModelSim simulator

• VCS simulator (Linux only)

• NC-Sim simulator (Linux only)

• Riviera simulator (PC only)

2.5.1 Using C/RTL Co-Simulation

To perform C/RTL co-simulation from the GUI:

1. In the main Vivado HLS toolbar menu, click the C/RTL Cosimulation button, see Figure 2.55. This
option opens the simulation wizard window shown on the Figure 2.56.

Figure 2.55: RTL Verification Flow

69

Figure 2.56: Run C/RTL Cosimulation button

2. In the C/RTL Co-simulation dialog box set the following parameters:

• choose Vivado Simulator in the Verilog/VHDL Simulation Section drop down list

• select VHDL in the RTL Selection section, and

• choose all in the Dump Trace drop down list, see Figure 2.57.
 70

Figure 2.57: C/RTL Co-simulation dialog box with set parameters

3. Leave all other parameters unchanged and click OK.

As can be seen from the previous figure, in the C/RTL Co-simulation dialog box there is an Options section
where can be found the following options:

• Setup Only - This option creates all the files (wrappers, adapters, and scripts) required to run the
simulation but does not execute the simulator. The simulation can be run in the command shell from
within the appropriate RTL simulation folder <solution name>/sim/<RTL>.

• Dump Trace - This option generates a trace file for every function, which is saved to the <solution>/sim/<RTL>
folder. The drop-down menu allows you to select which signals are saved to the trace file. You can choose
to trace all signals in the design, trace just the top-level ports, or trace no signals. For details on using
the trace file, see the documentation for the selected RTL simulator.

• Optimizing Compile - This option ensures a high level of optimization is used to compile the C test
bench. Using this option increases the compile time but the simulation executes faster.

• Reduce Disk Space - The flow shown on the Figure 2.46 in saves the results for all transactions before
executing RTL simulation. In some cases, this can result in large data files. The reduce diskspace option
can be used to execute one transaction at a time and reduce the amount of disk space required for the file.
If the function is executed N times in the C test bench, the reduce diskspace option ensure N separate
RTL simulations are performed. This causes the simulation to run slower.

• Compiled Library Location - This option specifies the location of the compiled library for a third-party
RTL simulator.

Note: If you are simulating with a third-party RTL simulator and the design uses IP, you must use
an RTL simulation model for the IP before performing RTL simulation. To create or obtain the RTL
simulation model, contact your IP provider.

• Input Arguments - This option allows the specification of any arguments required by the test bench.
71

Pressing the OK button in the C/RTL Co-simulation dialog box, the co-simulation process begins. Co-
simulation flow can be traced within Vivado HLS Console window.

Vivado HLS executes the RTL simulation in the project sub-directory: <SOLUTION>/sim/<RTL>, where

• SOLUTION is the name of the solution.

• RTL is the RTL type chosen for simulation.

Any files written by the C test bench during co-simulation and any trace files generated by the simulator are
written to this directory.

2.5.2 Analyzing RTL Simulations

Optionally, you can review the waveform from C/RTL cosimulation using the Open Wave Viewer... toolbar
button, see Figure 2.58.

Figure 2.58: Open Wave Viewer toolbar button

To view RTL waveforms, you must select the following options before executing C/RTL cosimulation:

• Verilog/VHDL Simulator Selection - Select Vivado Simulator.

For Xilinx 7 series and later devices, you can alternatively select Auto.

• Dump Trace - Select all or port.

When C/RTL cosimulation completes, the Open Wave Viewer toolbar button opens the RTL waveforms in
the Vivado IDE, see Figure 2.59.
 72

Figure 2.59: Waveform Viewer window opened in Vivado IDE

Note: When you open the Vivado IDE using this method, you can only use the waveform analysis features,
such as zoom, pan, and waveform radix.

In the Waveform Viewer window expand Design Top Signals folder and then find sw0 V[0:0] port (in the
C Inputs -> sw0(wire) folder) and pwm out V[0:0] port (in the C Outputs -> pwm out(wire) folder)
and expand them also, see Figure 2.60. Zoom in few times around spot where sw0 V[0:0] port changes its
value from 0 to 1 and you will see the PWM signal period change. You can also notice the change of the duty
cycle of the PWM signal, as it is being modulated by the sine wave. When sw0 V[0:0]=0 the period of the
PWM signal is 3.5 times longer then in case when sw0 V[0:0]=1, as it was expected.

Figure 2.60: Waveform Viewer window with cosimulation results

73

2.6 Package the RTL Implementation

The final step in the Vivado HLS flow is to export the RTL design as a block of Intellectual Property (IP) which
can be used by other tools in the Xilinx design flow. The RTL design can be packaged into the following output
formats:

• IP Catalog formatted IP for use with the Vivado Design Suite

• System Generator for DSP IP for use with Vivado System Generator for DSP

• Synthesized Checkpoint (.dcp)

You can only export designs targeted to 7 series devices, Zynq-7000 AP SoC, and UltraScale devices to the
Vivado Design Suite design flows.

In addition to the packaged output formats, the RTL files are available as standalone files (not part of a packaged
format) in the verilog and vhdl directories located within the implementation directory
<project name>/<solution name>/impl.

When Vivado HLS reports on the results of synthesis, it provides an estimation of the results expected after
RTL synthesis: the expected clock frequency, the expected number of registers, LUTs and block RAMs. These
results are estimations because Vivado HLS cannot know what exact optimizations RTL synthesis performs or
what the actual routing delays will be, and hence cannot know the final area and timing values.

Before exporting a design, you have the opportunity to execute logic synthesis and confirm the accuracy of
the estimates. The evaluate option invokes RTL synthesis during the export process and synthesizes the RTL
design to gates.

Note: The RTL synthesis option is provided to confirm the reported estimates. In most cases, these RTL results
are not included in the packaged IP.

For most export formats, the RTL synthesis is executed in the verilog or vhdl directories, but the results of
RTL synthesis are not included in the packaged IP.

2.6.1 Packaging IP using IP Catalog Format

Upon completion of synthesis and RTL verification:

1. Open the Export RTL dialog box by clicking the Export RTL toolbar button or choosing the Solution
-> Export RTL option from the main Vivado HLS menu, see Figure 2.61.

Figure 2.61: Export RTL option

2. In the Export RTL dialog box choose IP Catalog option from the Format Selection drop down list,
see Figure 2.62.
 74

Figure 2.62: Export RTL dialog box

In the Format Selection drop down list you can choose between IP Catalog, System Generator for
DSP or Synthesized Checkpoint (.dcp) format options in which RTL model will be exported. De-
pending of the chosen format, by clicking the Configuration... button, it is possible to set the additional
parameters, see Illustration 2.63.

Figure 2.63: Configuration dialog box

The Configuration options allow the following identification tags to be embedded in the exported package.
These fields can be used to help identify the packaged RTL inside the Vivado IP Catalog.

The configuration information is used to differentiate between multiple instances of the same design when the
design is loaded into the IP Catalog. For example, if an implementation is packaged for the IP Catalog and then
a new solution is created and packaged as IP, the new solution by default has the same name and configuration
information. If the new solution is also added to the IP Catalog, the IP Catalog will identify it as an updated
version of the same IP and the last version added to the IP Catalog will be used.

An alternative method is to use the prefix option in the config rtl configuration to rename the output design
and files with a unique prefix.

3. In the Configuration dialog box provide the following configuration setting:

• Vendor: so-logic
75

• Library: hls
• Version: 1.0
• Description: An IP generated by Vivado HLS
• Display Name: hls modulator v1.0

Figure 2.64: Configuration dialog box in case IP Catalog format

4. In the Configuration dialog box click OK.

5. In the Export RTL dialog box also click OK.

When you press OK button in the Export RTL dialog box, Vivado HLS will start exporting RTL model into
chosen format.

After the packaging process is complete, the.zip file archive in directory <project name>/<solution name>/impl/ip
can be imported into the Vivado IP Catalog and used in any Vivado design (RTL or IP Integrator).

Important: In this tutorial we will use only exporting IP to IP Catalog!

If you choose System Generator for DSP format option, this package will be written to the
<project name>/<solution name>/impl/sysgen directory and will contain everything necessary to import the
design to System Generator.

A Vivado HLS generated System Generator package may be imported into System Generator using the following
steps:
1. Inside the System Generator design, right-click and use option XilinxBlockAdd to instantiate new block.
2. Scroll down the list in dialog box and select Vivado HLS.

3. Double-click on the newly instantiated Vivado HLS block to open the Block Parameters dialog box.
4. Browse to the solution directory where the Vivado HLS block was exported. Using the example, <project
name>/<solution name¿/impl/sysgen, browse to the <project name>/<solution name> directory and
select apply.
76
Chapter 3

USING DEVELOPED IP CORE IN

VIVADO DESIGN SUITE

How to integrate a custom IP within the ARM-based embedded system using Xilinx Vivado IDE and SDK tool,
will be shown in this chapter.

The main component of the Socius development board is Zynq-7000 AP SoC. The Zynq-7000 AP SoC is
composed of two major functional blocks: Processing System (PS) and Programmable Logic (PL). Since
existing LEDs and switches on the Socius board are connected to the PS part of the Zynq FPGA, it would
require programming PS part of the Zynq FPGA, which is not topic of this tutorial. It is the main topic in the
”Basic Embedded System Design” tutorial.

In our design we will program PL part of the Zynq FPGA with model that will be created using the IP Integrator
tool. PS part is also required to generate clock signal for the Modulator HLS design, since the only reference
clock source on the Socius board is connected to the PS part of the Zynq FPGA. Properly configured PS part
will be described in the socius xz lab ps bd component.

3.1 Create a new project with included developed IP core

First, a new project must be created. Crate a new project using the Vivado IDE New Project wizard and
include developed IP core (hls modulator v1.0) into the new project.

1. Close the Vivado HLS tool and open Vivado IDE tool.

2. In the Vivado IDE tool create a new project, modulator hls, targeting the Socius development board
and save it in the same directory where the Vivado HLS modulator project is saved. For details how to
create Vivado project, please look at the Chapter 2.2 Creating a New Project in the Basic FPGA Tutorial.

3. In the Vivado IDE click Settings command from the Project Manager section to open the Settings
dialog box.

4. In the Settings dialog box, under the General section, change Target language to be VHDL instead
of Verilog.

5. In the Settings dialog box, expand IP option from the Project Settings list and select Repository
command.

6. In the IP Repository window click ”+” icon to add the desire repository.

7. In the IP Repositories dialog box find the HLS modulator/solution2/impl/ip folder, where is the required
so-logic hls modulator 1 0 IP core stored, select it and click Select.

8. In the Add Repository dialog box click OK to add the selected IP core to the Repository Manager.

77
 78

9. In the Settings dialog box, just click OK and the required so-logic hls modulator 1 0 IP core should
appear in the IP Catalog of your project.

Note: For more details how to include packaged IP core to the IP Catalog of your Vivado project,
please look at the Chapter 12.1 IP Packager, steps 33 - 37, in the Basic FPGA Tutorial.

10. In the Flow Navigator, under the Project Manager, click IP Catalog command to verify the presence
of the previously created IP in the IP Catalog. In the Search field type the name of the IP core (in our
case hls modulator v1.0) and you should should find it under the VIVADO HLS IP section, see Figure
3.1.

Figure 3.1: IP Catalog with added hls modulator v1.0 IP core

3.2 Create ARM-based hardware platform with integrated devel-

oped IP core

This sub-chapter will show how to build Zynq-7000 All Programmable (AP) SoC processor ”modulator hls”
design using Vivado IDE and Tcl programming interface. In this sub-chapter, you will instantiate a few IPs in
the IP Integrator tool and then stitch them together to create an IP based system design. At the end, you will
run synthesis and implementation process and generate bitstream file.

The following steps describe how to create ARM-based hardware platform for Socius development board.

1. First, we will create modulator socius arm rtl.vhd and socius components package.vhd files using
Vivado test editor and save them into the working directory.
• modulator socius arm rtl.vhd file will hold the top-level module of our design, in which Zynq PS
component configured for Socius development board will be instantiated
• socius components package.vhd file will contain Socius PS module component declaration.

The content of the both files is presented in the text below.

79

modulator socius arm rtl.vhd

-- Make r e f e r e n c e to l i b r a r i e s that are n e c e s s a r y for this file :

-- the first part is a s y m b o l i c name , the path is defined d e p e n d i n g of the tools
-- the second part is a package name
-- the third part i n c l u d e s all f u n c t i o n s from that package
-- Better for d o c u m e n t a t i o n would be to include only the f u n c t i o n s that are n e c e s s a r y

library ieee ;
use ieee . std_lo gic_116 4 . all ;
use ieee . std_ lo gi c_ a ri th . all ;
use ieee . s t d _ l o g i c _ u n s i g n e d . all ;

library unisim ;
use unisim . vcomponents . all ;

library work ;
use work . s o c i u s _ c o m p o n e n t s _ p a c k a g e . all ;

entity m o d u l a t o r _ s o c i u s _ a r m is
port (
-- ! e x p a n s i o n top slot
pl_io_t_io _p _ io : inout s t d _ l o g i c _ v e c t o r (18 downto 0);
pl_io_t_io _n _ io : inout s t d _ l o g i c _ v e c t o r (18 downto 0);
-- ! e x p a n s i o n main slot
pl_io_m_io _p _ io : inout s t d _ l o g i c _ v e c t o r (18 downto 0);
pl_io_m_io _n _ io : inout s t d _ l o g i c _ v e c t o r (18 downto 0);
-- ! e x p a n s i o n bottom slot
pl_io_b_io _p _ io : inout s t d _ l o g i c _ v e c t o r (18 downto 0);
pl_io_b_io _n _ io : inout s t d _ l o g i c _ v e c t o r (18 downto 0);
-- ps io
ps_ddr3_addr : inout s t d _ lo g i c _ v e c t o r (14 downto 0);
ps_ddr3_ba : inout s t d _ l o gi c _ v e c t o r (2 downto 0);
ps_ddr3_cas_n : inout std_logic ;
ps_ddr3_ck_n : inout std_logic ;
ps_ddr3_ck_p : inout std_logic ;
ps_ddr3_cke : inout std_logic ;
ps_ddr3_cs_n : inout std_logic ;
ps_ddr3_dm : inout s t d _ l o gi c _ v e c t o r ( 3 downto 0);
ps_ddr3_dq : inout s t d _ l o gi c _ v e c t o r (31 downto 0);
ps_ddr3_dqs_n : inout s t d _ l o g i c _v e c t o r ( 3 downto 0);
ps_ddr3_dqs_p : inout s t d _ l o g i c _v e c t o r ( 3 downto 0);
ps_ddr3_odt : inout std_logic ;
ps_ddr3_ras_n : inout std_logic ;
ps_ddr3_ re se t _n : inout std_logic ;
ps_ddr3_we_n : inout std_logic ;
ps_ddr_vrn : inout std_logic ;
ps_ddr_vrp : inout std_logic ;
ps_clk_i : inout std_logic ;
ps_por_n_i : inout std_logic ;
ps_srst_n_i : inout std_logic ;
ps_phy_mdc_io : inout std_logic ;
ps_phy_mdio_ io : inout std_logic ;
ps_phy_rx _ c l k _ i o : inout std_logic ;
ps _ph y_r x _ c t r l _ i o : inout std_logic ;
ps_phy_rxd_io : inout s t d _ l o g i c _v e c t o r (3 downto 0);
ps_phy_tx _ c l k _ i o : inout std_logic ;
ps _ph y_t x _ c t r l _ i o : inout std_logic ;
ps_phy_txd_io : inout s t d _ l o g i c _v e c t o r (3 downto 0);
ps_i2c_scl_io : inout std_logic ;
ps_i2c_sda_io : inout std_logic ;
ps _le d_e r r o r _ n _ i o : inout std_logic ;
ps _le d_f r o n t _ n _ i o : inout s t d _ l o g i c _ v e ct o r (1 downto 0);
p s_ l ed _s d c a r d _ n _ i o : inout std_logic ;
ps_sw0_a_io : inout std_logic ;
ps_sw0_b_io : inout std_logic ;
ps_sw1_a_io : inout std_logic ;
ps_sw1_b_io : inout std_logic ;
ps_sw2_a_io : inout std_logic ;
ps_sw2_b_io : inout std_logic ;
ps_sw3_a_io : inout std_logic ;
ps_sw3_b_io : inout std_logic ;
ps_uart_rx_io : inout std_logic ;
ps_uart_tx_io : inout std_logic ;
ps_qspi_cs _n _ io : inout std_logic ;
ps_qspi_da ta _ io : inout s t d _ l o g i c _ v e c t o r (3 downto 0);
ps_qspi_clk_ io : inout std_logic ;
ps_sdio_clk_ io : inout std_logic ;
ps_sdio_cmd_ io : inout std_logic ;
ps_sdio_da ta _ io : inout s t d _ l o g i c _ v e c t o r (3 downto 0);
ps_usb_clk_io : inout std_logic ;
ps_usb_data_ io : inout s t d _ l o g i c _ v e c to r (7 downto 0);
ps_usb_dir_io : inout std_logic ;
ps_usb_nxt_io : inout std_logic ;
ps_usb_stp_io : inout std_logic
-- ce_o : out std_logic ;
-- pl_clk0_o : out std_logic
);
end entity ;
 80

architecture structural of m o d u l a t o r _ s o c i u s _ a r m is

-- Between a r c h i t e c t u r e and begin is d e c l a r a t i o n area for types , signals and c o n s t a n t s

-- E v e r y t h i n g dec l a r e d here will be visible in the whole a r c h i t e c t u r e

-- bram regis t e r i n t e r f a c e soc

signal p l _b r a m _ s o c _ a d d r _ s : std_logic_vector (15 downto 0);
signal pl _br a m _ s o c _ d i n _ s : std_logic_vector (31 downto 0);
signal p l _b r a m _ s o c _ d o u t _ s : std_logic_vector (31 downto 0);
signal pl_br a m _s o c _ e n _ s : std_logic ;
signal pl _br a m _ s o c _ r s t _ s : std_logic ;
signal pl_br a m _s o c _ w e _ s : s t d _l o g i c _ v e c t o r ( 3 downto 0);
-- bram regis t e r i n t e r f a c e mid
signal p l _b r a m _ m i d _ a d d r _ s : std_logic_vector (15 downto 0);
signal pl _br a m _ m i d _ d i n _ s : std_logic_vector (31 downto 0);
signal p l _b r a m _ m i d _ d o u t _ s : std_logic_vector (31 downto 0);
signal pl_br a m _m i d _ e n _ s : std_logic ;
signal pl _br a m _ m i d _ r s t _ s : std_logic ;
signal pl_br a m _m i d _ w e _ s : s t d _l o g i c _ v e c t o r ( 3 downto 0);
-- bram regis t e r i n t e r f a c e top
signal p l _b r a m _ t o p _ a d d r _ s : std_logic_vector (15 downto 0);
signal pl _br a m _ t o p _ d i n _ s : std_logic_vector (31 downto 0);
signal p l _b r a m _ t o p _ d o u t _ s : std_logic_vector (31 downto 0);
signal pl_br a m _t o p _ e n _ s : std_logic ;
signal pl _br a m _ t o p _ r s t _ s : std_logic ;
signal pl_br a m _t o p _ w e _ s : s t d _l o g i c _ v e c t o r ( 3 downto 0);
-- bram regis t e r i n t e r f a c e bot
signal p l _b r a m _ b o t _ a d d r _ s : std_logic_vector (15 downto 0);
signal pl _br a m _ b o t _ d i n _ s : std_logic_vector (31 downto 0);
signal p l _b r a m _ b o t _ d o u t _ s : std_logic_vector (31 downto 0);
signal pl_br a m _b o t _ e n _ s : std_logic ;
signal pl _br a m _ b o t _ r s t _ s : std_logic ;
signal pl_br a m _b o t _ w e _ s : s t d _l o g i c _ v e c t o r ( 3 downto 0);

-- d e c l a r a t i o n for fixed signal PL to PS

signal pl_clk0_s : std_logic ;
signal pl_clk1_s : std_logic ;
signal pl_clk2_s : std_logic ;
signal pl_clk3_s : std_logic ;
signal pl_reset_n_s : std_logic ;

-- ps signals
signal ps_mio_s : s t d _ l o g i c _ v e c t o r (53 downto 0);

-- uart , i2c , spi signals

signal uart_rxd_s : std_logic ;
signal uart_txd_s : std_logic ;
signal spi_io0_i_s : std_logic ;
signal spi_io0_o_s : std_logic ;
signal spi_io0_t_s : std_logic ;
signal spi_io1_i_s : std_logic ;
signal spi_io1_o_s : std_logic ;
signal spi_io1_t_s : std_logic ;
signal spi_sck_i_s : std_logic ;
signal spi_sck_o_s : std_logic ;
signal spi_sck_t_s : std_logic ;
signal spi_ss1_o_s : std_logic ;
signal spi_ss2_o_s : std_logic ;
signal spi_ss_i_s : std_logic ;
signal spi_ss_o_s : std_logic ;
signal spi_ss_t_s : std_logic ;
signal iic_scl_i_s : std_logic ;
signal iic_scl_o_s : std_logic ;
signal iic_scl_t_s : std_logic ;
signal iic_sda_i_s : std_logic ;
signal iic_sda_o_s : std_logic ;
signal iic_sda_t_s : std_logic ;

-- i n t e r r u p t signals to ps
signal pl_int_soc_s : std_logic ;
signal pl_int_top_s : std_logic ;
signal pl_int_mid_s : std_logic ;
signal pl_int_bot_s : std_logic ;

begin

-- instance of p r o c e s s o r system PS

s o c i u s _ x z _ i o _ p s _ b d _ i : component s o c i u s _ x z _ i o _ p s _ b d
port map (
ddr3_addr = > ps_ddr3_addr ,
ddr3_ba = > ps_ddr3_ba ,
ddr3_cas_n = > ps_ddr3_cas_n ,
ddr3_ck_n = > ps_ddr3_ck_n ,
ddr3_ck_p = > ps_ddr3_ck_p ,
ddr3_cke = > ps_ddr3_cke ,
ddr3_cs_n = > ps_ddr3_cs_n ,
ddr3_dm = > ps_ddr3_dm ,
ddr3_dq = > ps_ddr3_dq ,
ddr3_dqs_n = > ps_ddr3_dqs_n ,
81

ddr3_dqs_p => ps_ddr3_dqs_p ,

ddr3_odt => ps_ddr3_odt ,
ddr3_ras_n => ps_ddr3_ras_n ,
ddr3_reset_n => ps_ddr3_reset_n ,
ddr3_we_n => ps_ddr3_we_n ,
fixed_io_ d d r _ v r n => ps_ddr_vrn ,
fixed_io_ d d r _ v r p => ps_ddr_vrp ,
fixed_io_mio => ps_mio_s ,
fixed_io _p s_ c lk => ps_clk_i ,
fixed_io_ p s _ p o r b => ps_por_n_i ,
fi xed _io _ p s _ s r s t b => ps_srst_n_i ,
pl_uart_1_rxd => uart_rxd_s ,
pl_uart_1_txd => uart_txd_s ,
pl_spi_0_io0 _i => spi_io0_i_s ,
pl_spi_0_io0 _o => spi_io0_o_s ,
pl_spi_0_io0 _t => spi_io0_t_s ,
pl_spi_0_io1 _i => spi_io1_i_s ,
pl_spi_0_io1 _o => spi_io1_o_s ,
pl_spi_0_io1 _t => spi_io1_t_s ,
pl_spi_0_sck _i => spi_sck_i_s ,
pl_spi_0_sck _o => spi_sck_o_s ,
pl_spi_0_sck _t => spi_sck_t_s ,
pl_spi_0_ss1 _o => spi_ss1_o_s ,
pl_spi_0_ss2 _o => spi_ss2_o_s ,
pl_spi_0_ss_i => spi_ss_i_s ,
pl_spi_0_ss_o => spi_ss_o_s ,
pl_spi_0_ss_t => spi_ss_t_s ,
pl_iic_1_scl _i => iic_scl_i_s ,
pl_iic_1_scl _o => iic_scl_o_s ,
pl_iic_1_scl _t => iic_scl_t_s ,
pl_iic_1_sda _i => iic_sda_i_s ,
pl_iic_1_sda _o => iic_sda_o_s ,
pl_iic_1_sda _t => iic_sda_t_s ,
sdio_0_cdn => ’1 ’ , -- pl_sd_cd_n_i ,
usbind_0_port_indctl => open ,
usbind_0_vbus_pwrfault => ’1 ’ , -- p l _ u s b _ f a u l t _ n _ i ,
usbind_0_vbus_pwrselect => open ,
pl_bram_b o t _ a d d r => pl_bram_bot_addr_s ,
pl_bram_ bo t_ c lk => open ,
pl_bram_ bo t_ d in => pl_bram_bot_din_s ,
pl_bram_b o t _ d o u t => pl_bram_bot_dout_s ,
pl_bram_bot_ en => pl_bram_bot_en_s ,
pl_bram_ bo t_ r st => pl_bram_bot_rst_s ,
pl_bram_bot_ we => pl_bram_bot_we_s ,
pl_bram_m i d _ a d d r => pl_bram_mid_addr_s ,
pl_bram_ mi d_ c lk => open ,
pl_bram_ mi d_ d in => pl_bram_mid_din_s ,
pl_bram_m i d _ d o u t => pl_bram_mid_dout_s ,
pl_bram_mid_ en => pl_bram_mid_en_s ,
pl_bram_ mi d_ r st => pl_bram_mid_rst_s ,
pl_bram_mid_ we => pl_bram_mid_we_s ,
pl_bram_s o c _ a d d r => pl_bram_soc_addr_s ,
pl_bram_ so c_ c lk => open ,
pl_bram_ so c_ d in => pl_bram_soc_din_s ,
pl_bram_s o c _ d o u t => pl_bram_soc_dout_s ,
pl_bram_soc_ en => pl_bram_soc_en_s ,
pl_bram_ so c_ r st => pl_bram_soc_rst_s ,
pl_bram_soc_ we => pl_bram_soc_we_s ,
pl_bram_t o p _ a d d r => pl_bram_top_addr_s ,
pl_bram_ to p_ c lk => open ,
pl_bram_ to p_ d in => pl_bram_top_din_s ,
pl_bram_t o p _ d o u t => pl_bram_top_dout_s ,
pl_bram_top_ en => pl_bram_top_en_s ,
pl_bram_ to p_ r st => pl_bram_top_rst_s ,
pl_bram_top_ we => pl_bram_top_we_s ,
pl_clk0 => pl_clk0_s ,
pl_clk1 => pl_clk1_s ,
pl_clk2 => pl_clk2_s ,
pl_clk3 => pl_clk3_s ,
pl_reset_n => pl_reset_n_s ,
pl_int_soc (0) => pl_int_soc_s ,
pl_int_top (0) => pl_int_top_s ,
pl_int_mid (0) => pl_int_mid_s ,
pl_int_bot (0) => pl_int_bot_s
);

-- a s s i g n m e n t of MIO to board names

ps_mio_s (53) <= ps_phy_ mdio_io ;

ps_mio_s (52) <= ps_phy_mdc_io ;
ps_mio_s (51) <= ps_uart_tx_io ;
ps_mio_s (50) <= ps_uart_rx_io ;
ps_mio_s (49) <= ps_led_error_n_io ;
ps_mio_s (48 downto 47) <= p s _ l e d _ f r o n t _ n _ i o (1 downto 0);
ps_mio_s (46) <= ps_led_sdcard_n_io ;
ps_mio_s (45 downto 42) <= ps _s d io _d at a _i o ;
ps_mio_s (41) <= ps_sdio _cmd_io ;
ps_mio_s (40) <= ps_sdio _clk_io ;
ps_mio_s (39) <= ps_usb_ data_io (7);
ps_mio_s (38) <= ps_usb_ data_io (6);
ps_mio_s (37) <= ps_usb_ data_io (5);
 82

ps_mio_s (36) <= ps_usb_clk_io ;

ps_mio_s (35) <= ps_usb_ data_io (3);
ps_mio_s (34) <= ps_usb_ data_io (2);
ps_mio_s (33) <= ps_usb_ data_io (1);
ps_mio_s (32) <= ps_usb_ data_io (0);
ps_mio_s (31) <= ps_usb_nxt_io ;
ps_mio_s (30) <= ps_usb_stp_io ;
ps_mio_s (29) <= ps_usb_dir_io ;
ps_mio_s (28) <= ps_usb_ data_io (4);
ps_mio_s (27) <= ps_phy_rx_ctrl_io ;
ps_mio_s (26 downto 23) <= ps_phy_rxd_io ;
ps_mio_s (22) <= ps_phy_rx_clk_io ;
ps_mio_s (21) <= ps_phy_tx_ctrl_io ;
ps_mio_s (20 downto 17) <= ps_phy_txd_io ;
ps_mio_s (16) <= ps_phy_tx_clk_io ;
ps_mio_s (15) <= ps_i2c_sda_io ;
ps_mio_s (14) <= ps_i2c_scl_io ;
ps_mio_s (13) <= ps_sw3_b_io ;
ps_mio_s (12) <= ps_sw3_a_io ;
ps_mio_s (11) <= ps_sw2_b_io ;
ps_mio_s (10) <= ps_sw2_a_io ;
ps_mio_s (9) <= ps_sw1_b_io ;
ps_mio_s (8) <= ps_sw1_a_io ;
ps_mio_s (7) <= ps_sw0_b_io ;
ps_mio_s (6) <= ps_qs pi_clk_i o ;
ps_mio_s (5 downto 2) <= p s_ q sp i_ da t a_ io ;
ps_mio_s (1) <= p s_ q sp i_ c s_ n_ io ;
ps_mio_s (0) <= ps_sw0_a_io ;

end architecture ;

socius components package.vhd

library ieee ;
use ieee . std_lo gic_116 4 . all ;
use ieee . std _ lo gi c_ a ri th . all ;
use ieee . s t d_ l o g i c _ u n s i g n e d . all ;

package s o c i u s _ c o m p o n e n t s _ p a c k a g e is

component s o c i u s _ x z _ i o _ p s _ b d is
port (
ddr3_addr : inout s t d _ l o g i c _ v e c t o r ( 14 downto 0 );
ddr3_ba : inout s t d _ l o g i c _ ve c t o r ( 2 downto 0 );
ddr3_cas_n : inout std_logic ;
ddr3_ck_n : inout std_logic ;
ddr3_ck_p : inout std_logic ;
ddr3_cke : inout std_logic ;
ddr3_cs_n : inout std_logic ;
ddr3_dm : inout s t d _ l o g i c _ ve c t o r ( 3 downto 0 );
ddr3_dq : inout s t d _ l o g i c _ ve c t o r ( 31 downto 0 );
ddr3_dqs_n : inout s t d _ l o g i c _ v e c t o r ( 3 downto 0 );
ddr3_dqs_p : inout s t d _ l o g i c _ v e c t o r ( 3 downto 0 );
ddr3_odt : inout std_logic ;
ddr3_ras_n : inout std_logic ;
ddr3_reset_n : inout std_logic ;
ddr3_we_n : inout std_logic ;
fixed _ i o _ d d r _ v rn : inout std_logic ;
fixed _ i o _ d d r _ v rp : inout std_logic ;
fixed_io_mio : inout s t d _ l o g i c _ v e c t o r ( 53 downto 0 );
fixed _i o _p s_ cl k : inout std_logic ;
fixed _ i o _ p s _ p o rb : inout std_logic ;
fi xed _ i o _ p s _ s r s t b : inout std_logic ;
pl_uart_1_rxd : in std_logic ;
pl_uart_1_txd : out std_logic ;
pl_sp i_0_io0 _i : in std_logic ;
pl_sp i_0_io0 _o : out std_logic ;
pl_sp i_0_io0 _t : out std_logic ;
pl_sp i_0_io1 _i : in std_logic ;
pl_sp i_0_io1 _o : out std_logic ;
pl_sp i_0_io1 _t : out std_logic ;
pl_sp i_0_sck _i : in std_logic ;
pl_sp i_0_sck _o : out std_logic ;
pl_sp i_0_sck _t : out std_logic ;
pl_sp i_0_ss1 _o : out std_logic ;
pl_sp i_0_ss2 _o : out std_logic ;
pl_spi_0_ss_i : in std_logic ;
pl_spi_0_ss_o : out std_logic ;
pl_spi_0_ss_t : out std_logic ;
pl_ii c_1_scl _i : in std_logic ;
pl_ii c_1_scl _o : out std_logic ;
pl_ii c_1_scl _t : out std_logic ;
pl_ii c_1_sda _i : in std_logic ;
pl_ii c_1_sda _o : out std_logic ;
pl_ii c_1_sda _t : out std_logic ;
sdio_0_cdn : in std_logic ;
usbind_0_port_indctl : out s t d _ l o g i c _ v e c t o r ( 1 downto 0 );
83

usbind_0_vbus_pwrfault : in std_logic ;
usbind_0_vbus_pwrselect : out std_logic ;
pl_b r a m _ b o t _ a d d r : out s t d _ l og i c _ v e c t o r ( 15 downto 0 );
pl_br am _ bo t_ cl k : out std_logic ;
pl_br am _ bo t_ di n : out s t d _ l o g i c _ v e c t o r ( 31 downto 0 );
pl_b r a m _ b o t _ d o u t : in s t d _ l o g i c _ v e c t o r ( 31 downto 0 );
pl_br am_bot_ en : out std_logic ;
pl_br am _ bo t_ rs t : out std_logic ;
pl_br am_bot_ we : out s t d _ l o g i c _ v e c t o r ( 3 downto 0 );
pl_b r a m _ m i d _ a d dr : out st d _ l o g i c _ v e c t o r ( 15 downto 0 );
pl_br am _ mi d_ cl k : out std_logic ;
pl_br am _ mi d_ di n : out s t d _ l o g i c _ v e c t o r ( 31 downto 0 );
pl_b r a m _ m i d _ d o ut : in s t d _ l o g i c _ v e c t o r ( 31 downto 0 );
pl_br am_mid_ en : out std_logic ;
pl_br am _ mi d_ rs t : out std_logic ;
pl_br am_mid_ we : out s t d _ l o g i c _ v e c t o r ( 3 downto 0 );
pl_b r a m _ s o c _ a d dr : out s td _ l o g i c _ v e c t o r ( 15 downto 0 );
pl_br am _ so c_ cl k : out std_logic ;
pl_br am _ so c_ di n : out s t d _ l o g i c _ v e c t o r ( 31 downto 0 );
pl_b r a m _ s o c _ d o ut : in s t d _ l o g i c _ v e c t o r ( 31 downto 0 );
pl_b ram_soc_ en : out std_logic ;
pl_br am _ so c_ rs t : out std_logic ;
pl_b ram_soc_ we : out s t d _ l o g i c _ v e c t o r ( 3 downto 0 );
pl_b r a m _ t o p _ a d d r : out s td _ l o g i c _ v e c t o r ( 15 downto 0 );
pl_br am _ to p_ c lk : out std_logic ;
pl_br am _ to p_ d in : out s t d _ l o g i c _ v e c t o r ( 31 downto 0 );
pl_b r a m _ t o p _ d o u t : in s t d _ l o g i c _ v e c t o r ( 31 downto 0 );
pl_b ram_top_ en : out std_logic ;
pl_br am _ to p_ r st : out std_logic ;
pl_b ram_top_ we : out s t d _ l o g i c _ v e c t o r ( 3 downto 0 );
pl_clk0 : out std_logic ;
pl_clk1 : out std_logic ;
pl_clk2 : out std_logic ;
pl_clk3 : out std_logic ;
pl_reset_n : out std_logic ;
pl_int_bot : in s td _ l o g i c _ v e c t o r ( 0 to 0 );
pl_int_mid : in s td _ l o g i c _ v e c t o r ( 0 to 0 );
pl_int_soc : in s td _ l o g i c _ v e c t o r ( 0 to 0 );
pl_int_top : in s td _ l o g i c _ v e c t o r ( 0 to 0 )
);
end component ;

end package ;

2. When we finished with the modulator socius arm rtl.vhd and socius components package.vhd
files creation, add them into the ”modulator hls” project using Flow Navigator Add Sources option.

Note: To create and add these modules, use steps for creating modules, explained in the Chapter 2.4.1
Creating a Module Using Vivado Text Editor, in the Basic FPGA Tutorial.

Next, we must configure the Zynq PS part to work on Socius development board. This includes a number
of configuration steps, one of them being the proper configuration of the PS GPIO module to connect to the
LEDs and switches that are present on the Socius board. All these PS configuration steps can be done using
the Vivado GUI, by creating a block design. However, since this task includes a lot of manual settings of the
Zynq PS, a better approach would be to do this manual configuration only once and then to create a Tcl script
file that can be used in all future configurations of the Zynq PS part. The Tcl script that should be used to
correctly configure Zynq PS to work on Socius board is shown below.

socius xz io ps bd.tcl:
################################################################
# This is a generated script based on design : s o c i u s _ x z _ i o _ p s _ b d
#
# Though there are limitations about the generated script ,
# the main purpose of this utility is to make learning
# IP Integrator Tcl commands easier .
################################################################

################################################################
# Check if script is running in correct Vivado version .
################################################################
set s c r i p t s _ v i v a d o _ v e r s i o n 2017.3
set c u r r e n t _ v i v a d o _ v e r s i o n [ version - short ]

if { [ string first $ s c r i p t s _ v i v a d o _ v e r s i o n $ c u r r e n t _ v i v a d o _ v e r s i o n ] == -1 } {
puts " "
puts " ERROR : This script was generated using Vivado < $scripts_vivado_version > and is being run in < $current_vivado_version > of Vivado .
Please run the script in Vivado < $scripts_vivado_version > then open the design in Vivado < $current_vivado_version >. Upgrade the design by
running \ " Tools = > Report = > Report IP Status ...\ " , then run write_bd_tcl to create an updated script . "

return 1
}

################################################################
 84

# START
################################################################

# To test this script , run the following commands from Vivado Tcl console :
# source s o c i u s _ x z _ i o _ p s _ b d _ s c r i p t . tcl

# If you do not already have a project created ,

# you can create a project using the following command :
# cr eate_pro ject project_1 myproj - part xc7z020clg400 -1

# CHECKING IF PROJECT EXISTS

if { [ get_projects - quiet ] eq " " } {
puts " ERROR : Please open or create a project ! "
return 1
}

# CHANGE DESIGN NAME HERE

set design_name s o c i u s _ x z _ i o _ p s _ b d

# If you do not already have an existing IP Integrator design open ,

# you can create a design using the following command :
# c r e a t e _ b d _ d e s i g n $design_name

# Creating design if needed

set errMsg " "
set nRet 0

set cur_design [ c u r r e n t _ b d _ d e s i g n - quiet ]

set list_cells [ get_bd_cells - quiet ]

if { $ { design_name } eq " " } {

# USE CASES :
# 1) Design_name not set

set errMsg " ERROR : Please set the variable < design_name > to a non - empty value . "
set nRet 1

} elseif { $ { cur_design } ne " " && $ { list_cells } eq " " } {

# USE CASES :
# 2): Current design opened AND is empty AND names same .
# 3): Current design opened AND is empty AND names diff ; design_name NOT in project .
# 4): Current design opened AND is empty AND names diff ; design_name exists in project .

if { $cur_design ne $design_name } {
puts " INFO : Changing value of < design_name > from < $design_name > to < $cur_design > since current design is empty . "
set design_name [ get_property NAME $cur_design ]
}
puts " INFO : Constructing design in IPI design < $cur_design >... "

} elseif { $ { cur_design } ne " " && $list_cells ne " " && $cur_design eq $design_name } {
# USE CASES :
# 5) Current design opened AND has components AND same names .

set errMsg " ERROR : Design < $design_name > already exists in your project , please set the variable < design_name > to another value . "
set nRet 1
} elseif { [ get_files - quiet $ { design_name }. bd ] ne " " } {
# USE CASES :
# 6) Current opened design , has components , but diff names , design_name exists in project .
# 7) No opened design , design_name exists in project .

set errMsg " ERROR : Design < $design_name > already exists in your project , please set the variable < design_name > to another value . "
set nRet 2

} else {
# USE CASES :
# 8) No opened design , design_name not in project .
# 9) Current opened design , has components , but diff names , design_name not in project .

puts " INFO : Currently there is no design < $design_name > in project , so creating one ... "

c r e a t e _ b d _ d e s i g n $design_name

puts " INFO : Making design < $design_name > as c u r r e n t _ b d _ d e s i g n . "

c u r r e n t _ b d _ d e s i g n $design_name

puts " INFO : Currently the variable < design_name > is equal to \ " $design_name \ " . "

if { $nRet != 0 } {
puts $errMsg
return $nRet
}

##################################################################
# DESIGN PROCs
##################################################################

# Hierarchical cell : s o c i u s _ x z _ b r a m _ s w i t c h _ b d
proc c r e a t e _ h i e r _ c e l l _ s o c i u s _ x z _ b r a m _ s w i t c h _ b d { parentCell nameHier } {

if { $parentCell eq " " || $nameHier eq " " } {

puts " ERROR : c r e a t e _ h i e r _ c e l l _ s o c i u s _ x z _ b r a m _ s w i t c h _ b d () - Empty argument ( s )! "
return
}

# Get object for parentCell

set parentObj [ get_bd_cells $parentCell ]
if { $parentObj == " " } {
puts " ERROR : Unable to find parent cell < $parentCell >! "
return
}

# Make sure parentObj is hier blk

set parentType [ get_property TYPE $parentObj ]
if { $parentType ne " hier " } {
puts " ERROR : Parent < $parentObj > has TYPE = < $parentType >. Expected to be < hier >. "
return
}

# Save current instance ; Restore later

set oldCurInst [ c u r r e n t _ b d _ i n s t a n c e .]

# Set parent object as current

c u r r e n t _ b d _ i n s t a n c e $parentObj

# Create cell and set as current instance

set hier_obj [ cre ate_bd_ cell - type hier $nameHier ]
85

c u r r e n t _ b d _ i n s t a n c e $hier_obj

# Create interface pins

create_bd_intf_pin - mode Slave - vlnv xilinx . com : interface : aximm_rtl :1.0 S00_AXI
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 bram_bot
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 bram_mid
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 bram_soc
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 bram_top

# Create pins
create_bd_pin - dir I - type rst M01_ARESETN
create_bd_pin - dir I - type clk S00_ACLK

# Create instance : axi3_axi4_converter , and set properties

set a x i 3 _ a x i 4 _ c o n v e r t e r [ cre ate_bd_c ell - type ip - vlnv xilinx . com : ip : a x i _ p r o t o c o l _ c o n v e r t e r :2.1 a x i 3 _ a x i 4 _ c o n v e r t e r ]
set_property - dict [ list \
CONFIG . T R A N S L A T I O N _ M O D E {0} \
] $axi3_axi4_converter

# Create instance : axi3_axi4_converter1 , and set properties

set a x i 3 _ a x i 4 _ c o n v e r t e r 1 [ cr eate_bd _cell - type ip - vlnv xilinx . com : ip : a x i _ p r o t o c o l _ c o n v e r t e r :2.1 a x i 3 _ a x i 4 _ c o n v e r t e r 1 ]
set_property - dict [ list \
CONFIG . T R A N S L A T I O N _ M O D E {0} \
] $axi3_axi4_converter1

# Create instance : axi3_axi4_converter2 , and set properties

set a x i 3 _ a x i 4 _ c o n v e r t e r 2 [ cr eate_bd _cell - type ip - vlnv xilinx . com : ip : a x i _ p r o t o c o l _ c o n v e r t e r :2.1 a x i 3 _ a x i 4 _ c o n v e r t e r 2 ]
set_property - dict [ list \
CONFIG . T R A N S L A T I O N _ M O D E {0} \
] $axi3_axi4_converter2

# Create instance : axi3_axi4_converter3 , and set properties

set a x i 3 _ a x i 4 _ c o n v e r t e r 3 [ c reate_bd _cell - type ip - vlnv xilinx . com : ip : a x i _ p r o t o c o l _ c o n v e r t e r :2.1 a x i 3 _ a x i 4 _ c o n v e r t e r 3 ]
set_property - dict [ list \
CONFIG . T R A N S L A T I O N _ M O D E {0} \
] $axi3_axi4_converter3

# Create instance : socius_xz_bram_if_pl_bot , and set properties

set s o c i u s _ x z _ b r a m _ i f _ p l _ b o t [ cre ate_bd_ cell - type ip - vlnv xilinx . com : ip : axi_bram_ctrl :4.0 s o c i u s _ x z _ b r a m _ i f _ p l _ b o t ]
set_property - dict [ list \
CONFIG . PROTOCOL { AXI4LITE } \
CONFIG . S I N G L E _ P O R T _ B R A M {1} \
] $socius_xz_bram_if_pl_bot

# Create instance : socius_xz_bram_if_pl_mid , and set properties

set s o c i u s _ x z _ b r a m _ i f _ p l _ m i d [ cre ate_bd_ cell - type ip - vlnv xilinx . com : ip : axi_bram_ctrl :4.0 s o c i u s _ x z _ b r a m _ i f _ p l _ m i d ]
set_property - dict [ list \
CONFIG . PROTOCOL { AXI4LITE } \
CONFIG . S I N G L E _ P O R T _ B R A M {1} \
] $socius_xz_bram_if_pl_mid

# Create instance : socius_xz_bram_if_pl_soc , and set properties

set s o c i u s _ x z _ b r a m _ i f _ p l _ s o c [ cre ate_bd_ cell - type ip - vlnv xilinx . com : ip : axi_bram_ctrl :4.0 s o c i u s _ x z _ b r a m _ i f _ p l _ s o c ]
set_property - dict [ list \
CONFIG . PROTOCOL { AXI4LITE } \
CONFIG . S I N G L E _ P O R T _ B R A M {1} \
] $socius_xz_bram_if_pl_soc

# Create instance : socius_xz_bram_if_pl_top , and set properties

set s o c i u s _ x z _ b r a m _ i f _ p l _ t o p [ cre ate_bd_ cell - type ip - vlnv xilinx . com : ip : axi_bram_ctrl :4.0 s o c i u s _ x z _ b r a m _ i f _ p l _ t o p ]
set_property - dict [ list \
CONFIG . PROTOCOL { AXI4LITE } \
CONFIG . S I N G L E _ P O R T _ B R A M {1} \
] $socius_xz_bram_if_pl_top

# Create instance : socius_xz_bram_interconnect , and set properties

set s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t [ creat e_bd_ce ll - type ip - vlnv xilinx . com : ip : a x i _ in t e r c o n n e c t :2.1 s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t ]
set_property - dict [ list \
CONFIG . NUM_MI {4} \
] $socius_xz_bram_interconnect

# Create instance : xlconstant_1 , and set properties

set xlconstant_1 [ create_ bd_cell - type ip - vlnv xilinx . com : ip : xlconstant :1.1 xlconstant_1 ]

# Create instance : xlconstant_2 , and set properties

set xlconstant_2 [ create_ bd_cell - type ip - vlnv xilinx . com : ip : xlconstant :1.1 xlconstant_2 ]

# Create instance : xlconstant_3 , and set properties

set xlconstant_3 [ create_ bd_cell - type ip - vlnv xilinx . com : ip : xlconstant :1.1 xlconstant_3 ]

# Create instance : xlconstant_4 , and set properties

set xlconstant_4 [ create_ bd_cell - type ip - vlnv xilinx . com : ip : xlconstant :1.1 xlconstant_4 ]

# Create interface connections

c o n n e c t _ b d _ i n t f _ n e t - intf_net S00_AXI_1 [ g e t _ b d _ i n t f _ p i n s S00_AXI ] [ g e t_ b d _ i n t f _ p i n s s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / S00_AXI ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net a x i 3 _ a x i 4 _ c o n v e r t e r _ M _ A X I [ ge t _ b d _ i n t f _ p i n s a x i 3 _ a x i 4 _ c o n v e r t e r / M_AXI ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ b r a m _ i f _ p l _ s o c / S_AXI ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net a x i 3 _ a x i 4 _ c o n v e r t e r _ M _ A X I 1 [ g e t _ b d _ i nt f _ p i n s a x i 3 _ a x i 4 _ c o n v e r t e r 1 / M_AXI ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ b r a m _ i f _ p l _ m i d / S_AXI ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net a x i 3 _ a x i 4 _ c o n v e r t e r _ M _ A X I 2 [ g e t _ b d _ i nt f _ p i n s a x i 3 _ a x i 4 _ c o n v e r t e r 2 / M_AXI ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ b r a m _ i f _ p l _ t o p / S_AXI ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net a x i 3 _ a x i 4 _ c o n v e r t e r _ M _ A X I 3 [ g e t _ b d _ i nt f _ p i n s a x i 3 _ a x i 4 _ c o n v e r t e r 3 / M_AXI ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ b r a m _ i f _ p l _ b o t / S_AXI ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net a x i _ i n t e r c o n n e c t _ 0 _ M 0 0 _ A X I [ g e t _ b d _ i nt f _ p i n s a x i 3 _ a x i 4 _ c o n v e r t e r / S_AXI ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M00_AXI ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net a x i _ i n t e r c o n n e c t _ 0 _ M 0 1 _ A X I [ g e t _ b d _ i nt f _ p i n s a x i 3 _ a x i 4 _ c o n v e r t e r 1 / S_AXI ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M01_AXI ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net a x i _ i n t e r c o n n e c t _ 0 _ M 0 2 _ A X I [ g e t _ b d _ i nt f _ p i n s a x i 3 _ a x i 4 _ c o n v e r t e r 2 / S_AXI ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M02_AXI ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net a x i _ i n t e r c o n n e c t _ 0 _ M 0 3 _ A X I [ g e t _ b d _ i nt f _ p i n s a x i 3 _ a x i 4 _ c o n v e r t e r 3 / S_AXI ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M03_AXI ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net s o c i u s _ x z _ b r a m _ i f _ p l _ B R A M _ P O R T A [ g e t _ b d _ i n t f _ p in s bram_soc ] [ g e t _ b d _i n t f _ p i n s s o c i u s _ x z _ b r a m _ i f _ p l _ s o c / BRAM_PORTA ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net s o c i u s _ x z _ b r a m _ i f _ p l _ B R A M _ P O R T A 1 [ g e t _ b d _ i n t f _ p i n s bram_mid ] [ g e t _ b d _ i n t f _ pi n s s o c i u s _ x z _ b r a m _ i f _ p l _ m i d / BRAM_PORTA ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net s o c i u s _ x z _ b r a m _ i f _ p l _ B R A M _ P O R T A 2 [ g e t _ b d _ i n t f _ p i n s bram_top ] [ g e t _ b d _ i n t f _ pi n s s o c i u s _ x z _ b r a m _ i f _ p l _ t o p / BRAM_PORTA ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net s o c i u s _ x z _ b r a m _ i f _ p l _ B R A M _ P O R T A 3 [ g e t _ b d _ i n t f _ p i n s bram_bot ] [ g e t _ b d _ i n t f _ pi n s s o c i u s _ x z _ b r a m _ i f _ p l _ b o t / BRAM_PORTA ]

# Create port connections

conn ect_bd_ net - net ACLK_1 [ get_bd_pins S00_ACLK ] [ get_bd_pins a x i 3 _ a x i 4 _ c o n v e r t e r / aclk ] [ get_bd_pins a x i 3 _ a x i 4 _ c o n v e r t e r 1 / aclk ]
[ get_bd_pins a x i 3 _ a x i 4 _ c o n v e r t e r 2 / aclk ] [ get_bd_pins a x i 3 _ a x i 4 _ c o n v e r t e r 3 / aclk ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i f _ p l _ b o t / s_axi_aclk ]
[ get_bd_pins s o c i u s _ x z _ b r a m _ i f _ p l _ m i d / s_axi_aclk ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i f _ p l _ s o c / s_axi_aclk ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i f _ p l _ t o p / s_axi_aclk ]
[ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / ACLK ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M00_ACLK ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M01_ACLK ]
[ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M02_ACLK ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M03_ACLK ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / S00_ACLK ]
conn ect_bd_ net - net ARESETN_1 [ get_bd_pins M01_ARESETN ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / ARESETN ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M00_ARESETN ]
[ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M01_ARESETN ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M02_ARESETN ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / M03_ARESETN ]
[ get_bd_pins s o c i u s _ x z _ b r a m _ i n t e r c o n n e c t / S00_ARESETN ]
conn ect_bd_ net - net x l c o n s t a n t _ 0 _ d o u t [ get_bd_pins a x i 3 _ a x i 4 _ c o n v e r t e r / aresetn ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i f _ p l _ s o c / s_axi_aresetn ] [ get_bd_pins xlconstant_1 / dout ]
conn ect_bd_ net - net x l c o n s t a n t _ 0 _ d o u t 1 [ get_bd_pins a x i 3 _ a x i 4 _ c o n v e r t e r 1 / aresetn ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i f _ p l _ m i d / s_axi_aresetn ] [ get_bd_pins xlconstant_2 / dout ]
conn ect_bd_ net - net x l c o n s t a n t _ 0 _ d o u t 2 [ get_bd_pins a x i 3 _ a x i 4 _ c o n v e r t e r 2 / aresetn ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i f _ p l _ t o p / s_axi_aresetn ] [ get_bd_pins xlconstant_3 / dout ]
conn ect_bd_ net - net x l c o n s t a n t _ 0 _ d o u t 3 [ get_bd_pins a x i 3 _ a x i 4 _ c o n v e r t e r 3 / aresetn ] [ get_bd_pins s o c i u s _ x z _ b r a m _ i f _ p l _ b o t / s_axi_aresetn ] [ get_bd_pins xlconstant_4 / dout ]

# Restore current instance

c u r r e n t _ b d _ i n s t a n c e $oldCurInst
}

# Hierarchical cell : s oc iu s_ x z_ io _p s
proc c r e a t e _ h i e r _ c e l l _ s o c i u s _ x z _ i o _ p s { parentCell nameHier } {

if { $parentCell eq " " || $nameHier eq " " } {

puts " ERROR : c r e a t e _ h i e r _ c e l l _ s o c i u s _ x z _ i o _ p s () - Empty argument ( s )! "
 86

return
}

# Get object for parentCell

set parentObj [ get_bd_cells $parentCell ]
if { $parentObj == " " } {
puts " ERROR : Unable to find parent cell < $parentCell >! "
return
}

# Make sure parentObj is hier blk

set parentType [ get_property TYPE $parentObj ]
if { $parentType ne " hier " } {
puts " ERROR : Parent < $parentObj > has TYPE = < $parentType >. Expected to be < hier >. "
return
}

# Save current instance ; Restore later

set oldCurInst [ c u r r e n t _ b d _ i n s t a n c e .]

# Set parent object as current

c u r r e n t _ b d _ i n s t a n c e $parentObj

# Create cell and set as current instance

set hier_obj [ cre ate_bd_ cell - type hier $nameHier ]
c u r r e n t _ b d _ i n s t a n c e $hier_obj

# Create interface pins

create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : ddrx_rtl :1.0 ddr
create_bd_intf_pin - mode Master - vlnv xilinx . com : d i s p l a y _ p r o c e s s i n g _ s y s t e m 7 : fixedio_rtl :1.0 fixed_io
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : iic_rtl :1.0 iic_1
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 pl_bram_bot
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 pl_bram_mid
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 pl_bram_soc
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 pl_bram_top
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : sdio_rtl :1.0 sdio_0
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : spi_rtl :1.0 spi_0
create_bd_intf_pin - mode Master - vlnv xilinx . com : interface : uart_rtl :1.0 uart_1
create_bd_intf_pin - mode Master - vlnv xilinx . com : d i s p l a y _ p r o c e s s i n g _ s y s t e m 7 : usbctrl_rtl :1.0 usbind_0

# Create pins
create_bd_pin - dir O - type clk fclk_clk0
create_bd_pin - dir O - type clk fclk_clk1
create_bd_pin - dir O - type clk fclk_clk2
create_bd_pin - dir O - type clk fclk_clk3
create_bd_pin - dir O - type rst fclk_reset0_n
create_bd_pin - dir I - from 0 - to 0 pl_int_bot
create_bd_pin - dir I - from 0 - to 0 pl_int_mid
create_bd_pin - dir I - from 0 - to 0 pl_int_soc
create_bd_pin - dir I - from 0 - to 0 pl_int_top

# Create instance : s o c i u s _ x z _ b r a m _ s w i t c h _ b d
c r e a t e _ h i e r _ c e l l _ s o c i u s _ x z _ b r a m _ s w i t c h _ b d $hier_obj s o c i u s _ x z _ b r a m _ s w i t c h _ b d

# Create instance : socius_xz_io_ps_bd , and set properties

set s o c i u s _ x z _ i o _ p s _ b d [ creat e_bd_ce ll - type ip - vlnv xilinx . com : ip : p r o c e s s i n g _ s y s t e m 7 :5.5 s o c i u s _ x z _ i o _ p s _ b d ]
set_property - dict [ list \
CONFIG . P C W _ A C T _ A P U _ P E R I P H E R A L _ F R E Q M H Z {666.666687} \
CONFIG . P C W _ A C T _ C A N 0 _ P E R I P H E R A L _ F R E Q M H Z {23.8095} \
CONFIG . P C W _ A C T _ C A N 1 _ P E R I P H E R A L _ F R E Q M H Z {23.8095} \
CONFIG . P C W _ A C T _ C A N _ P E R I P H E R A L _ F R E Q M H Z {10.000000} \
CONFIG . P C W _ A C T _ D C I _ P E R I P H E R A L _ F R E Q M H Z {10.158731} \
CONFIG . P C W _ A C T _ E N E T 0 _ P E R I P H E R A L _ F R E Q M H Z {125.000000} \
CONFIG . P C W _ A C T _ E N E T 1 _ P E R I P H E R A L _ F R E Q M H Z {10.000000} \
CONFIG . P C W _ A C T _ F P G A 0 _ P E R I P H E R A L _ F R E Q M H Z {50.000000} \
CONFIG . P C W _ A C T _ F P G A 1 _ P E R I P H E R A L _ F R E Q M H Z {100.000000} \
CONFIG . P C W _ A C T _ F P G A 2 _ P E R I P H E R A L _ F R E Q M H Z {125.000000} \
CONFIG . P C W _ A C T _ F P G A 3 _ P E R I P H E R A L _ F R E Q M H Z {200.000000} \
CONFIG . P C W _ A C T _ I 2 C _ P E R I P H E R A L _ F R E Q M H Z {50} \
CONFIG . P C W _ A C T _ P C A P _ P E R I P H E R A L _ F R E Q M H Z {200.000000} \
CONFIG . P C W _ A C T _ Q S P I _ P E R I P H E R A L _ F R E Q M H Z {200.000000} \
CONFIG . P C W _ A C T _ S D I O _ P E R I P H E R A L _ F R E Q M H Z {100.000000} \
CONFIG . P C W _ A C T _ S M C _ P E R I P H E R A L _ F R E Q M H Z {10.000000} \
CONFIG . P C W _ A C T _ S P I _ P E R I P H E R A L _ F R E Q M H Z {166.666672} \
CONFIG . P C W _ A C T _ T P I U _ P E R I P H E R A L _ F R E Q M H Z {200.000000} \
CONFIG . P C W _ A C T _ T T C 0 _ C L K 0 _ P E R I P H E R A L _ F R E Q M H Z {111.111115} \
CONFIG . P C W _ A C T _ T T C 0 _ C L K 1 _ P E R I P H E R A L _ F R E Q M H Z {111.111115} \
CONFIG . P C W _ A C T _ T T C 0 _ C L K 2 _ P E R I P H E R A L _ F R E Q M H Z {111.111115} \
CONFIG . P C W _ A C T _ T T C 1 _ C L K 0 _ P E R I P H E R A L _ F R E Q M H Z {111.111115} \
CONFIG . P C W _ A C T _ T T C 1 _ C L K 1 _ P E R I P H E R A L _ F R E Q M H Z {111.111115} \
CONFIG . P C W _ A C T _ T T C 1 _ C L K 2 _ P E R I P H E R A L _ F R E Q M H Z {111.111115} \
CONFIG . P C W _ A C T _ T T C _ P E R I P H E R A L _ F R E Q M H Z {50} \
CONFIG . P C W _ A C T _ U A R T _ P E R I P H E R A L _ F R E Q M H Z {100.000000} \
CONFIG . P C W _ A C T _ U S B 0 _ P E R I P H E R A L _ F R E Q M H Z {60} \
CONFIG . P C W _ A C T _ U S B 1 _ P E R I P H E R A L _ F R E Q M H Z {60} \
CONFIG . P C W _ A C T _ W D T _ P E R I P H E R A L _ F R E Q M H Z {111.111115} \
CONFIG . P C W _ A P U _ C L K _ R A T I O _ E N A B L E {6:2:1} \
CONFIG . P C W _ A P U _ P E R I P H E R A L _ F R E Q M H Z {666.666666} \
CONFIG . P C W _ C A N 0 _ P E R I P H E R A L _ C L K S R C { External } \
CONFIG . P C W _ C A N 0 _ P E R I P H E R A L _ E N A B L E {0} \
CONFIG . P C W _ C A N 1 _ P E R I P H E R A L _ C L K S R C { External } \
CONFIG . P C W _ C A N 1 _ P E R I P H E R A L _ E N A B L E {0} \
CONFIG . P C W _ C A N _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ C A N _ P E R I P H E R A L _ V A L I D {0} \
CONFIG . PCW_CLK0_FREQ {50000000} \
CONFIG . PCW_CLK1_FREQ {100000000} \
CONFIG . PCW_CLK2_FREQ {125000000} \
CONFIG . PCW_CLK3_FREQ {200000000} \
CONFIG . P C W _ C P U _ C P U _ 6 X 4 X _ M A X _ R A N G E {667} \
CONFIG . P C W _ C P U _ P E R I P H E R A L _ C L K S R C { ARM PLL } \
CONFIG . P C W _ C R Y S T A L _ P E R I P H E R A L _ F R E Q M H Z {33.333333} \
CONFIG . P C W _ D C I _ P E R I P H E R A L _ C L K S R C { DDR PLL } \
CONFIG . P C W _ D C I _ P E R I P H E R A L _ F R E Q M H Z {10.159} \
CONFIG . P C W _ D D R _ P E R I P H E R A L _ C L K S R C { DDR PLL } \
CONFIG . P C W _ D D R _ R A M _ B A S E A D D R {0 x00100000 } \
CONFIG . P C W _ D D R _ R A M _ H I G H A D D R {0 x3FFFFFFF } \
CONFIG . PCW_DM_WIDTH {4} \
CONFIG . PCW_DQS_WIDTH {4} \
CONFIG . PCW_DQ_WIDTH {32} \
CONFIG . P C W _ E N E T 0 _ B A S E A D D R {0 xE000B000 } \
CONFIG . P C W _ E N E T 0 _ E N E T 0 _ I O { MIO 16 .. 27} \
CONFIG . P C W _ E N E T 0 _ G R P _ M D I O _ E N A B L E {1} \
CONFIG . P C W _ E N E T 0 _ G R P _ M D I O _ I O { MIO 52 .. 53} \
CONFIG . P C W _ E N E T 0 _ H I G H A D D R {0 xE000BFFF } \
CONFIG . P C W _ E N E T 0 _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ E N E T 0 _ P E R I P H E R A L _ E N A B L E {1} \
CONFIG . P C W _ E N E T 0 _ P E R I P H E R A L _ F R E Q M H Z {1000 Mbps } \
CONFIG . P C W _ E N E T 1 _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ E N E T 1 _ P E R I P H E R A L _ E N A B L E {0} \
CONFIG . P C W _ E N E T _ R E S E T _ E N A B L E {0} \
CONFIG . P C W _ E N E T _ R E S E T _ P O L A R I T Y { Active Low } \
87

CONFIG . P CW _E N_ 4 K_ TI M ER {0} \
CONFIG . PCW_EN_CAN0 {0} \
CONFIG . PCW_EN_CAN1 {0} \
CONFIG . P C W _ E N _ C L K 0 _ P O R T {1} \
CONFIG . P C W _ E N _ C L K 1 _ P O R T {1} \
CONFIG . P C W _ E N _ C L K 2 _ P O R T {1} \
CONFIG . P C W _ E N _ C L K 3 _ P O R T {1} \
CONFIG . P C W _ E N _ C L K T R I G 0 _ P O R T {0} \
CONFIG . P C W _ E N _ C L K T R I G 1 _ P O R T {0} \
CONFIG . P C W _ E N _ C L K T R I G 2 _ P O R T {0} \
CONFIG . P C W _ E N _ C L K T R I G 3 _ P O R T {0} \
CONFIG . PCW_EN_DDR {1} \
CONFIG . P C W _ E N _ E M I O _ C A N 0 {0} \
CONFIG . P C W _ E N _ E M I O _ C A N 1 {0} \
CONFIG . P C W _ E N _ E M I O _ C D _ S D I O 0 {1} \
CONFIG . P C W _ E N _ E M I O _ C D _ S D I O 1 {0} \
CONFIG . P C W _ E N _ E M I O _ E N E T 0 {0} \
CONFIG . P C W _ E N _ E M I O _ E N E T 1 {0} \
CONFIG . P C W _ E N _ E M I O _ G P I O {0} \
CONFIG . P C W _ E N _ E M I O _ I 2 C 0 {0} \
CONFIG . P C W _ E N _ E M I O _ I 2 C 1 {1} \
CONFIG . P C W _ E N _ E M I O _ M O D E M _ U A R T 0 {0} \
CONFIG . P C W _ E N _ E M I O _ M O D E M _ U A R T 1 {0} \
CONFIG . P C W _ E N _ E M I O _ P J T A G {0} \
CONFIG . P C W _ E N _ E M I O _ S D I O 0 {0} \
CONFIG . P C W _ E N _ E M I O _ S D I O 1 {0} \
CONFIG . P C W _ E N _ E M I O _ S P I 0 {1} \
CONFIG . P C W _ E N _ E M I O _ S P I 1 {0} \
CONFIG . P C W _ E N _ E M I O _ S R A M _ I N T {0} \
CONFIG . P C W _ E N _ E M I O _ T R A C E {0} \
CONFIG . P C W _ E N _ E M I O _ T T C 0 {0} \
CONFIG . P C W _ E N _ E M I O _ T T C 1 {0} \
CONFIG . P C W _ E N _ E M I O _ U A R T 0 {0} \
CONFIG . P C W _ E N _ E M I O _ U A R T 1 {1} \
CONFIG . P CW _E N_ E MI O_ W DT {1} \
CONFIG . P C W _ E N _ E M I O _ W P _ S D I O 0 {0} \
CONFIG . P C W _ E N _ E M I O _ W P _ S D I O 1 {0} \
CONFIG . PCW_EN_ENET0 {1} \
CONFIG . PCW_EN_ENET1 {0} \
CONFIG . PCW_EN_GPIO {1} \
CONFIG . PCW_EN_I2C0 {1} \
CONFIG . PCW_EN_I2C1 {1} \
CONFIG . P C W _ E N _ M O D E M _ U A R T 0 {0} \
CONFIG . P C W _ E N _ M O D E M _ U A R T 1 {0} \
CONFIG . PCW_EN_PJTAG {0} \
CONFIG . PCW_EN_QSPI {1} \
CONFIG . P C W _ E N _ R S T 0 _ P O R T {1} \
CONFIG . P C W _ E N _ R S T 1 _ P O R T {0} \
CONFIG . P C W _ E N _ R S T 2 _ P O R T {0} \
CONFIG . P C W _ E N _ R S T 3 _ P O R T {0} \
CONFIG . PCW_EN_SDIO0 {1} \
CONFIG . PCW_EN_SDIO1 {0} \
CONFIG . PCW_EN_SMC {0} \
CONFIG . PCW_EN_SPI0 {1} \
CONFIG . PCW_EN_SPI1 {0} \
CONFIG . PCW_EN_TRACE {0} \
CONFIG . PCW_EN_TTC0 {0} \
CONFIG . PCW_EN_TTC1 {0} \
CONFIG . PCW_EN_UART0 {1} \
CONFIG . PCW_EN_UART1 {1} \
CONFIG . PCW_EN_USB0 {1} \
CONFIG . PCW_EN_USB1 {0} \
CONFIG . PCW_EN_WDT {1} \
CONFIG . P C W _ F C L K 0 _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ F C L K 1 _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ F C L K 2 _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ F C L K 3 _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ F C L K _ C L K 0 _ B U F { true } \
CONFIG . P C W _ F P G A 0 _ P E R I P H E R A L _ F R E Q M H Z {50} \
CONFIG . P C W _ F P G A 1 _ P E R I P H E R A L _ F R E Q M H Z {100} \
CONFIG . P C W _ F P G A 2 _ P E R I P H E R A L _ F R E Q M H Z {125} \
CONFIG . P C W _ F P G A 3 _ P E R I P H E R A L _ F R E Q M H Z {200} \
CONFIG . P C W _ F P G A _ F C L K 0 _ E N A B L E {1} \
CONFIG . P C W _ G P I O _ B A S E A D D R {0 xE000A000 } \
CONFIG . P C W _ G P I O _ E M I O _ G P I O _ E N A B L E {0} \
CONFIG . P C W _ G P I O _ H I G H A D D R {0 xE000AFFF } \
CONFIG . P C W _ G P I O _ M I O _ G P I O _ E N A B L E {1} \
CONFIG . P C W _ G P I O _ M I O _ G P I O _ I O { MIO } \
CONFIG . P C W _ G P I O _ P E R I P H E R A L _ E N A B L E {0} \
CONFIG . P C W _ I 2 C 0 _ B A S E A D D R {0 xE0004000 } \
CONFIG . P C W _ I 2 C 0 _ G R P _ I N T _ E N A B L E {0} \
CONFIG . P C W _ I 2 C 0 _ H I G H A D D R {0 xE0004FFF } \
CONFIG . P C W _ I 2 C 0 _ I 2 C 0 _ I O { MIO 14 .. 15} \
CONFIG . P C W _ I 2 C 0 _ P E R I P H E R A L _ E N A B L E {1} \
CONFIG . P C W _ I 2 C 1 _ P E R I P H E R A L _ E N A B L E {1} \
CONFIG . P C W _ I 2 C _ P E R I P H E R A L _ F R E Q M H Z {111.111115} \
CONFIG . P C W _ I 2 C _ R E S E T _ E N A B L E {0} \
CONFIG . P C W _ I 2 C _ R E S E T _ P O L A R I T Y { Active Low } \
CONFIG . P C W _ I M P O R T _ B O A R D _ P R E S E T { None } \
CONFIG . P C W _ I N C L U D E _ A C P _ T R A N S _ C H E C K {0} \
CONFIG . P C W _ I R Q _ F 2 P _ I N T R {1} \
CONFIG . P C W _ M I O _ 0 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . P C W _ M I O _ 0 _ P U L L U P { enabled } \
CONFIG . PCW_MIO _0_SLEW { slow } \
CONFIG . P C W _ M I O _ 1 0 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . P C W _ M I O _ 1 0 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 10 _S L EW { slow } \
CONFIG . P C W _ M I O _ 1 1 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . P C W _ M I O _ 1 1 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 11 _S L EW { slow } \
CONFIG . P C W _ M I O _ 1 2 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . P C W _ M I O _ 1 2 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 12 _S L EW { slow } \
CONFIG . P C W _ M I O _ 1 3 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . P C W _ M I O _ 1 3 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 13 _S L EW { slow } \
CONFIG . P C W _ M I O _ 1 4 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . P C W _ M I O _ 1 4 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 14 _S L EW { slow } \
CONFIG . P C W _ M I O _ 1 5 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . P C W _ M I O _ 1 5 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 15 _S L EW { slow } \
CONFIG . P C W _ M I O _ 1 6 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 1 6 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 16 _S L EW { slow } \
CONFIG . P C W _ M I O _ 1 7 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 1 7 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 17 _S L EW { slow } \
CONFIG . P C W _ M I O _ 1 8 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 1 8 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 18 _S L EW { slow } \
 88

CONFIG . P C W _ M I O _ 1 9 _ I O T Y P E { LVCMOS 1.8 V } \

CONFIG . P C W _ M I O _ 1 9 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 19 _S L EW { slow } \
CONFIG . P C W _ M I O _ 1 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . P C W _ M I O _ 1 _ P U L L U P { enabled } \
CONFIG . PCW_MIO _1_SLEW { slow } \
CONFIG . P C W _ M I O _ 2 0 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 2 0 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 20 _S L EW { slow } \
CONFIG . P C W _ M I O _ 2 1 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 2 1 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 21 _S L EW { slow } \
CONFIG . P C W _ M I O _ 2 2 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 2 2 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 22 _S L EW { slow } \
CONFIG . P C W _ M I O _ 2 3 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 2 3 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 23 _S L EW { slow } \
CONFIG . P C W _ M I O _ 2 4 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 2 4 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 24 _S L EW { slow } \
CONFIG . P C W _ M I O _ 2 5 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 2 5 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 25 _S L EW { slow } \
CONFIG . P C W _ M I O _ 2 6 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 2 6 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 26 _S L EW { slow } \
CONFIG . P C W _ M I O _ 2 7 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 2 7 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 27 _S L EW { slow } \
CONFIG . P C W _ M I O _ 2 8 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 2 8 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 28 _S L EW { slow } \
CONFIG . P C W _ M I O _ 2 9 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 2 9 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 29 _S L EW { slow } \
CONFIG . P C W _ M I O _ 2 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . PCW_MIO _2_SLEW { slow } \
CONFIG . P C W _ M I O _ 3 0 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 3 0 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 30 _S L EW { slow } \
CONFIG . P C W _ M I O _ 3 1 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 3 1 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 31 _S L EW { slow } \
CONFIG . P C W _ M I O _ 3 2 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 3 2 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 32 _S L EW { slow } \
CONFIG . P C W _ M I O _ 3 3 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 3 3 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 33 _S L EW { slow } \
CONFIG . P C W _ M I O _ 3 4 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 3 4 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 34 _S L EW { slow } \
CONFIG . P C W _ M I O _ 3 5 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 3 5 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 35 _S L EW { slow } \
CONFIG . P C W _ M I O _ 3 6 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 3 6 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 36 _S L EW { slow } \
CONFIG . P C W _ M I O _ 3 7 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 3 7 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 37 _S L EW { slow } \
CONFIG . P C W _ M I O _ 3 8 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 3 8 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 38 _S L EW { slow } \
CONFIG . P C W _ M I O _ 3 9 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 3 9 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 39 _S L EW { slow } \
CONFIG . P C W _ M I O _ 3 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . PCW_MIO _3_SLEW { slow } \
CONFIG . P C W _ M I O _ 4 0 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 4 0 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 40 _S L EW { slow } \
CONFIG . P C W _ M I O _ 4 1 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 4 1 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 41 _S L EW { slow } \
CONFIG . P C W _ M I O _ 4 2 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 4 2 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 42 _S L EW { slow } \
CONFIG . P C W _ M I O _ 4 3 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 4 3 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 43 _S L EW { slow } \
CONFIG . P C W _ M I O _ 4 4 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 4 4 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 44 _S L EW { slow } \
CONFIG . P C W _ M I O _ 4 5 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 4 5 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 45 _S L EW { slow } \
CONFIG . P C W _ M I O _ 4 6 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 4 6 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 46 _S L EW { slow } \
CONFIG . P C W _ M I O _ 4 7 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 4 7 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 47 _S L EW { slow } \
CONFIG . P C W _ M I O _ 4 8 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 4 8 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 48 _S L EW { slow } \
CONFIG . P C W _ M I O _ 4 9 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 4 9 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 49 _S L EW { slow } \
CONFIG . P C W _ M I O _ 4 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . PCW_MIO _4_SLEW { slow } \
CONFIG . P C W _ M I O _ 5 0 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 5 0 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 50 _S L EW { slow } \
CONFIG . P C W _ M I O _ 5 1 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 5 1 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 51 _S L EW { slow } \
CONFIG . P C W _ M I O _ 5 2 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 5 2 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 52 _S L EW { slow } \
CONFIG . P C W _ M I O _ 5 3 _ I O T Y P E { LVCMOS 1.8 V } \
CONFIG . P C W _ M I O _ 5 3 _ P U L L U P { enabled } \
CONFIG . P CW _M IO _ 53 _S L EW { slow } \
CONFIG . P C W _ M I O _ 5 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . PCW_MIO _5_SLEW { slow } \
CONFIG . P C W _ M I O _ 6 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . PCW_MIO _6_SLEW { slow } \
CONFIG . P C W _ M I O _ 7 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . PCW_MIO _7_SLEW { slow } \
CONFIG . P C W _ M I O _ 8 _ I O T Y P E { LVCMOS 3.3 V } \
89

CONFIG . PCW_MIO _8_SLEW { slow } \

CONFIG . P C W _ M I O _ 9 _ I O T Y P E { LVCMOS 3.3 V } \
CONFIG . P C W _ M I O _ 9 _ P U L L U P { enabled } \
CONFIG . PCW_MIO _9_SLEW { slow } \
CONFIG . P C W _ M I O _ P R I M I T I V E {54} \
CONFIG . P C W _ M I O _ T R E E _ P E R I P H E R A L S { GPIO # Quad SPI Flash # Quad SPI Flash # Quad SPI Flash # Quad SPI Flash # Quad SPI Flash # Quad SPI Flash # GPIO # GPIO # GPIO # GPIO # GPIO # GPIO # GPIO # I2C
0# I2C 0# Enet 0# Enet 0# Enet 0# Enet 0# Enet 0# Enet 0# Enet 0# Enet 0# Enet 0# Enet 0# Enet 0# Enet 0# USB 0# USB 0# USB 0# USB 0# USB 0# USB 0# USB 0# USB 0# USB 0# USB 0# USB 0# USB 0# SD
0# SD 0# SD 0# SD 0# SD 0# SD 0# GPIO # GPIO # GPIO # GPIO # UART 0# UART 0# Enet 0# Enet 0} \
CONFIG . P C W _ M I O _ T R E E _ S I G N A L S { gpio [0]# qspi0_ss_b # qspi0_io [0]# qspi0_io [1]# qspi0_io [2]# qspi0_io [3]# qspi0_sclk # gpio [7]# gpio [8]# gpio [9]# gpio [10]# gpio [11]# gpio [12]# gpio [13]
# scl # sda # tx_clk # txd [0]# txd [1]# txd [2]# txd [3]# tx_ctl # rx_clk # rxd [0]# rxd [1]# rxd [2]# rxd [3]# rx_ctl # data [4]# dir # stp # nxt # data [0]# data [1]# data [2]# data [3]# clk # data [5]# data [6]
# data [7]# clk # cmd # data [0]# data [1]# data [2]# data [3]# gpio [46]# gpio [47]# gpio [48]# gpio [49]# rx # tx # mdc # mdio } \
CONFIG . P C W _ N A N D _ C Y C L E S _ T _ A R {1} \
CONFIG . P C W _ N A N D _ C Y C L E S _ T _ C L R {1} \
CONFIG . P C W _ N A N D _ C Y C L E S _ T _ R C {2} \
CONFIG . P C W _ N A N D _ C Y C L E S _ T _ R E A {1} \
CONFIG . P C W _ N A N D _ C Y C L E S _ T _ R R {1} \
CONFIG . P C W _ N A N D _ C Y C L E S _ T _ W C {2} \
CONFIG . P C W _ N A N D _ C Y C L E S _ T _ W P {1} \
CONFIG . P C W _ N O R _ C S 0 _ T _ C E O E {1} \
CONFIG . P C W _ N O R _ C S 0 _ T _ P C {1} \
CONFIG . P C W _ N O R _ C S 0 _ T _ R C {2} \
CONFIG . P C W _ N O R _ C S 0 _ T _ T R {1} \
CONFIG . P C W _ N O R _ C S 0 _ T _ W C {2} \
CONFIG . P C W _ N O R _ C S 0 _ T _ W P {1} \
CONFIG . P C W _ N O R _ C S 0 _ W E _ T I M E {0} \
CONFIG . P C W _ N O R _ C S 1 _ T _ C E O E {1} \
CONFIG . P C W _ N O R _ C S 1 _ T _ P C {1} \
CONFIG . P C W _ N O R _ C S 1 _ T _ R C {2} \
CONFIG . P C W _ N O R _ C S 1 _ T _ T R {1} \
CONFIG . P C W _ N O R _ C S 1 _ T _ W C {2} \
CONFIG . P C W _ N O R _ C S 1 _ T _ W P {1} \
CONFIG . P C W _ N O R _ C S 1 _ W E _ T I M E {0} \
CONFIG . P C W _ N O R _ S R A M _ C S 0 _ T _ C E O E {1} \
CONFIG . P C W _ N O R _ S R A M _ C S 0 _ T _ P C {1} \
CONFIG . P C W _ N O R _ S R A M _ C S 0 _ T _ R C {2} \
CONFIG . P C W _ N O R _ S R A M _ C S 0 _ T _ T R {1} \
CONFIG . P C W _ N O R _ S R A M _ C S 0 _ T _ W C {2} \
CONFIG . P C W _ N O R _ S R A M _ C S 0 _ T _ W P {1} \
CONFIG . P C W _ N O R _ S R A M _ C S 0 _ W E _ T I M E {0} \
CONFIG . P C W _ N O R _ S R A M _ C S 1 _ T _ C E O E {1} \
CONFIG . P C W _ N O R _ S R A M _ C S 1 _ T _ P C {1} \
CONFIG . P C W _ N O R _ S R A M _ C S 1 _ T _ R C {2} \
CONFIG . P C W _ N O R _ S R A M _ C S 1 _ T _ T R {1} \
CONFIG . P C W _ N O R _ S R A M _ C S 1 _ T _ W C {2} \
CONFIG . P C W _ N O R _ S R A M _ C S 1 _ T _ W P {1} \
CONFIG . P C W _ N O R _ S R A M _ C S 1 _ W E _ T I M E {0} \
CONFIG . P C W _ O V E R R I D E _ B A S I C _ C L O C K {0} \
CONFIG . P C W _ P A C K A G E _ D D R _ B O A R D _ D E L A Y 0 {0.089} \
CONFIG . P C W _ P A C K A G E _ D D R _ B O A R D _ D E L A Y 1 {0.075} \
CONFIG . P C W _ P A C K A G E _ D D R _ B O A R D _ D E L A Y 2 {0.085} \
CONFIG . P C W _ P A C K A G E _ D D R _ B O A R D _ D E L A Y 3 {0.092} \
CONFIG . P C W _ P A C K A G E _ D D R _ D Q S _ T O _ C L K _ D E L A Y _ 0 { -0.025} \
CONFIG . P C W _ P A C K A G E _ D D R _ D Q S _ T O _ C L K _ D E L A Y _ 1 {0.014} \
CONFIG . P C W _ P A C K A G E _ D D R _ D Q S _ T O _ C L K _ D E L A Y _ 2 { -0.009} \
CONFIG . P C W _ P A C K A G E _ D D R _ D Q S _ T O _ C L K _ D E L A Y _ 3 { -0.033} \
CONFIG . P C W _ P A C K A G E _ N A M E { clg400 } \
CONFIG . P C W _ P C A P _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ P C A P _ P E R I P H E R A L _ F R E Q M H Z {200} \
CONFIG . P C W _ P E R I P H E R A L _ B O A R D _ P R E S E T { None } \
CONFIG . P C W _ P J T A G _ P E R I P H E R A L _ E N A B L E {0} \
CONFIG . P C W _ P R E S E T _ B A N K 0 _ V O L T A G E { LVCMOS 3.3 V } \
CONFIG . P C W _ P R E S E T _ B A N K 1 _ V O L T A G E { LVCMOS 1.8 V } \
CONFIG . PCW_PS7 _SI_REV { PRODUCTION } \
CONFIG . P C W _ Q S P I _ G R P _ F B C L K _ E N A B L E {0} \
CONFIG . P C W _ Q S P I _ G R P _ I O 1 _ E N A B L E {0} \
CONFIG . P C W _ Q S P I _ G R P _ S I N G L E _ S S _ E N A B L E {1} \
CONFIG . P C W _ Q S P I _ G R P _ S I N G L E _ S S _ I O { MIO 1 .. 6} \
CONFIG . P C W _ Q S P I _ G R P _ S S 1 _ E N A B L E {0} \
CONFIG . P C W _ Q S P I _ I N T E R N A L _ H I G H A D D R E S S {0 xFCFFFFFF } \
CONFIG . P C W _ Q S P I _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ Q S P I _ P E R I P H E R A L _ E N A B L E {1} \
CONFIG . P C W _ Q S P I _ P E R I P H E R A L _ F R E Q M H Z {200} \
CONFIG . P C W _ Q S P I _ Q S P I _ I O { MIO 1 .. 6} \
CONFIG . P C W _ S D 0 _ G R P _ C D _ E N A B L E {1} \
CONFIG . P C W _ S D 0 _ G R P _ C D _ I O { EMIO } \
CONFIG . P C W _ S D 0 _ G R P _ P O W _ E N A B L E {0} \
CONFIG . P C W _ S D 0 _ G R P _ W P _ E N A B L E {0} \
CONFIG . P C W _ S D 0 _ P E R I P H E R A L _ E N A B L E {1} \
CONFIG . PCW_SD0 _SD0_IO { MIO 40 .. 45} \
CONFIG . P C W _ S D 1 _ P E R I P H E R A L _ E N A B L E {0} \
CONFIG . P C W _ S D I O 0 _ B A S E A D D R {0 xE0100000 } \
CONFIG . P C W _ S D I O 0 _ H I G H A D D R {0 xE0100FFF } \
CONFIG . P C W _ S D I O _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ S D I O _ P E R I P H E R A L _ F R E Q M H Z {100} \
CONFIG . P C W _ S D I O _ P E R I P H E R A L _ V A L I D {1} \
CONFIG . P C W _ S M C _ C Y C L E _ T 0 { NA } \
CONFIG . P C W _ S M C _ C Y C L E _ T 1 { NA } \
CONFIG . P C W _ S M C _ C Y C L E _ T 2 { NA } \
CONFIG . P C W _ S M C _ C Y C L E _ T 3 { NA } \
CONFIG . P C W _ S M C _ C Y C L E _ T 4 { NA } \
CONFIG . P C W _ S M C _ C Y C L E _ T 5 { NA } \
CONFIG . P C W _ S M C _ C Y C L E _ T 6 { NA } \
CONFIG . P C W _ S M C _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ S M C _ P E R I P H E R A L _ V A L I D {0} \
CONFIG . P C W _ S P I 0 _ P E R I P H E R A L _ E N A B L E {1} \
CONFIG . P C W _ S P I 1 _ P E R I P H E R A L _ E N A B L E {0} \
CONFIG . P C W _ S P I _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ S P I _ P E R I P H E R A L _ V A L I D {1} \
CONFIG . P C W _ T P I U _ P E R I P H E R A L _ C L K S R C { External } \
CONFIG . P C W _ T R A C E _ I N T E R N A L _ W I D T H {2} \
CONFIG . P C W _ T R A C E _ P E R I P H E R A L _ E N A B L E {0} \
CONFIG . P C W _ T T C 0 _ C L K 0 _ P E R I P H E R A L _ C L K S R C { CPU_1X } \
CONFIG . P C W _ T T C 0 _ C L K 0 _ P E R I P H E R A L _ D I V I S O R 0 {1} \
CONFIG . P C W _ T T C 0 _ C L K 1 _ P E R I P H E R A L _ C L K S R C { CPU_1X } \
CONFIG . P C W _ T T C 0 _ C L K 1 _ P E R I P H E R A L _ D I V I S O R 0 {1} \
CONFIG . P C W _ T T C 0 _ C L K 2 _ P E R I P H E R A L _ C L K S R C { CPU_1X } \
CONFIG . P C W _ T T C 0 _ C L K 2 _ P E R I P H E R A L _ D I V I S O R 0 {1} \
CONFIG . P C W _ T T C 0 _ P E R I P H E R A L _ E N A B L E {1} \
CONFIG . P C W _ T T C 1 _ C L K 0 _ P E R I P H E R A L _ C L K S R C { CPU_1X } \
CONFIG . P C W _ T T C 1 _ C L K 0 _ P E R I P H E R A L _ D I V I S O R 0 {1} \
CONFIG . P C W _ T T C 1 _ C L K 1 _ P E R I P H E R A L _ C L K S R C { CPU_1X } \
CONFIG . P C W _ T T C 1 _ C L K 1 _ P E R I P H E R A L _ D I V I S O R 0 {1} \
CONFIG . P C W _ T T C 1 _ C L K 2 _ P E R I P H E R A L _ C L K S R C { CPU_1X } \
CONFIG . P C W _ T T C 1 _ C L K 2 _ P E R I P H E R A L _ D I V I S O R 0 {1} \
CONFIG . P C W _ T T C 1 _ P E R I P H E R A L _ E N A B L E {0} \
CONFIG . P C W _ U A R T 0 _ B A S E A D D R {0 xE0000000 } \
CONFIG . P C W _ U A R T 0 _ B A U D _ R A T E {115200} \
CONFIG . P C W _ U A R T 0 _ G R P _ F U L L _ E N A B L E {0} \
CONFIG . P C W _ U A R T 0 _ H I G H A D D R {0 xE0000FFF } \
CONFIG . P C W _ U A R T 0 _ P E R I P H E R A L _ E N A B L E {1} \
CONFIG . P C W _ U A R T 0 _ U A R T 0 _ I O { MIO 50 .. 51} \
 90

CONFIG . P C W _ U A R T 1 _ P E R I P H E R A L _ E N A B L E {1} \
CONFIG . P C W _ U A R T 1 _ U A R T 1 _ I O { EMIO } \
CONFIG . P C W _ U A R T _ P E R I P H E R A L _ C L K S R C { IO PLL } \
CONFIG . P C W _ U A R T _ P E R I P H E R A L _ F R E Q M H Z {100} \
CONFIG . P C W _ U I P A R A M _ A C T _ D D R _ F R E Q _ M H Z {533.333374} \
CONFIG . P C W _ U I P A R A M _ D D R _ A D V _ E N A B L E {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ A L {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ B L {8} \
CONFIG . P C W _ U I P A R A M _ D D R _ B O A R D _ D E L A Y 0 {0.0} \
CONFIG . P C W _ U I P A R A M _ D D R _ B O A R D _ D E L A Y 1 {0.0} \
CONFIG . P C W _ U I P A R A M _ D D R _ B O A R D _ D E L A Y 2 {0.0} \
CONFIG . P C W _ U I P A R A M _ D D R _ B O A R D _ D E L A Y 3 {0.0} \
CONFIG . P C W _ U I P A R A M _ D D R _ B U S _ W I D T H {32 Bit } \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 0 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 0 _ P A C K A G E _ L E N G T H {80.4535} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 0 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 1 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 1 _ P A C K A G E _ L E N G T H {80.4535} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 1 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 2 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 2 _ P A C K A G E _ L E N G T H {80.4535} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 2 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 3 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 3 _ P A C K A G E _ L E N G T H {80.4535} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ 3 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ C L O C K _ S T O P _ E N {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 0 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 0 _ P A C K A G E _ L E N G T H {105.056} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 0 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 1 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 1 _ P A C K A G E _ L E N G T H {66.904} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 1 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 2 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 2 _ P A C K A G E _ L E N G T H {89.1715} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 2 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 3 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 3 _ P A C K A G E _ L E N G T H {113.63} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ 3 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ T O _ C L K _ D E L A Y _ 0 {0.0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ T O _ C L K _ D E L A Y _ 1 {0.0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ T O _ C L K _ D E L A Y _ 2 {0.0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q S _ T O _ C L K _ D E L A Y _ 3 {0.0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 0 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 0 _ P A C K A G E _ L E N G T H {98.503} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 0 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 1 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 1 _ P A C K A G E _ L E N G T H {68.5855} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 1 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 2 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 2 _ P A C K A G E _ L E N G T H {90.295} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 2 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 3 _ L E N G T H _ M M {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 3 _ P A C K A G E _ L E N G T H {103.977} \
CONFIG . P C W _ U I P A R A M _ D D R _ D Q _ 3 _ P R O P O G A T I O N _ D E L A Y {160} \
CONFIG . P C W _ U I P A R A M _ D D R _ E N A B L E {1} \
CONFIG . P C W _ U I P A R A M _ D D R _ F R E Q _ M H Z {533.333333} \
CONFIG . P C W _ U I P A R A M _ D D R _ H I G H _ T E M P { Normal (0 -85)} \
CONFIG . P C W _ U I P A R A M _ D D R _ M E M O R Y _ T Y P E { DDR 3} \
CONFIG . P C W _ U I P A R A M _ D D R _ P A R T N O { MT41K256M16 RE -125} \
CONFIG . P C W _ U I P A R A M _ D D R _ T R A I N _ D A T A _ E Y E {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ T R A I N _ R E A D _ G A T E {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ T R A I N _ W R I T E _ L E V E L {0} \
CONFIG . P C W _ U I P A R A M _ D D R _ U S E _ I N T E R N A L _ V R E F {0} \
CONFIG . P C W _ U I P A R A M _ G E N E R A T E _ S U M M A R Y { NA } \
CONFIG . P C W _ U S B 0 _ B A S E A D D R {0 xE0102000 } \
CONFIG . P C W _ U S B 0 _ H I G H A D D R {0 xE0102fff } \
CONFIG . P C W _ U S B 0 _ P E R I P H E R A L _ E N A B L E {1} \
CONFIG . P C W _ U S B 0 _ U S B 0 _ I O { MIO 28 .. 39} \
CONFIG . P C W _ U S B 1 _ P E R I P H E R A L _ E N A B L E {0} \
CONFIG . P C W _ U S B _ R E S E T _ E N A B L E {0} \
CONFIG . P C W _ U S B _ R E S E T _ P O L A R I T Y { Active Low } \
CONFIG . P C W _ U S E _ A X I _ F A B R I C _ I D L E {0} \
CONFIG . P C W _ U S E _ C O R E S I G H T {0} \
CONFIG . P C W _ U S E _ C R O S S _ T R I G G E R {0} \
CONFIG . P C W _ U S E _ C R _ F A B R I C {1} \
CONFIG . P C W _ U S E _ D D R _ B Y P A S S {0} \
CONFIG . PCW_USE_DEBUG {0} \
CONFIG . PCW_USE_DMA0 {0} \
CONFIG . PCW_USE_DMA1 {0} \
CONFIG . PCW_USE_DMA2 {0} \
CONFIG . PCW_USE_DMA3 {0} \
CONFIG . P C W _ U S E _ E X P A N D E D _ I O P {0} \
CONFIG . P C W _ U S E _ F A B R I C _ I N T E R R U P T {1} \
CONFIG . P C W _ U S E _ H I G H _ O C M {0} \
CONFIG . P C W _ U S E _ M _ A X I _ G P 0 {1} \
CONFIG . P C W _ U S E _ M _ A X I _ G P 1 {0} \
CONFIG . P C W _ U S E _ P R O C _ E V E N T _ B U S {0} \
CONFIG . P C W _ U S E _ P S _ S L C R _ R E G I S T E R S {0} \
CONFIG . P C W _ U S E _ S _ A X I _ A C P {0} \
CONFIG . P C W _ U S E _ S _ A X I _ G P 0 {0} \
CONFIG . P C W _ U S E _ S _ A X I _ G P 1 {0} \
CONFIG . P C W _ U S E _ S _ A X I _ H P 0 {1} \
CONFIG . P C W _ U S E _ S _ A X I _ H P 1 {1} \
CONFIG . P C W _ U S E _ S _ A X I _ H P 2 {1} \
CONFIG . P C W _ U S E _ S _ A X I _ H P 3 {1} \
CONFIG . PCW_USE_TRACE {0} \
CONFIG . P C W _ V A L U E _ S I L V E R S I O N {3} \
CONFIG . P C W _ W D T _ P E R I P H E R A L _ C L K S R C { CPU_1X } \
CONFIG . P C W _ W D T _ P E R I P H E R A L _ D I V I S O R 0 {1} \
CONFIG . P C W _ W D T _ P E R I P H E R A L _ E N A B L E {1} \
] $socius_xz_io_ps_bd

# Create instance : xlconcat_0 , and set properties

set xlconcat_0 [ cre ate_bd_c ell - type ip - vlnv xilinx . com : ip : xlconcat :2.1 xlconcat_0 ]
set_property - dict [ list \
CONFIG . IN0_WIDTH {1} \
CONFIG . IN1_WIDTH {1} \
CONFIG . IN2_WIDTH {1} \
CONFIG . IN3_WIDTH {1} \
CONFIG . NUM_PORTS {4} \
] $xlconcat_0

# Create interface connections

c o n n e c t _ b d _ i n t f _ n e t - intf_net Conn1 [ g e t _ b d _ i n t f _ p i n s spi_0 ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ i o _ p s _ b d / SPI_0 ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net Conn2 [ g e t _ b d _ i n t f _ p i n s iic_1 ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ i o _ p s _ b d / IIC_1 ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net Conn3 [ g e t _ b d _ i n t f _ p i n s uart_1 ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ i o _ p s _ b d / UART_1 ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net Conn12 [ g e t _ b d _ i n t f _ p i n s pl_bram_bot ] [ g e t _ b d _ i n tf _ p i n s s o c i u s _ x z _ b r a m _ s w i t c h _ b d / bram_bot ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net Conn13 [ g e t _ b d _ i n t f _ p i n s pl_bram_mid ] [ g e t _ b d _ i n tf _ p i n s s o c i u s _ x z _ b r a m _ s w i t c h _ b d / bram_mid ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net Conn14 [ g e t _ b d _ i n t f _ p i n s pl_bram_soc ] [ g e t _ b d _ i n tf _ p i n s s o c i u s _ x z _ b r a m _ s w i t c h _ b d / bram_soc ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net Conn15 [ g e t _ b d _ i n t f _ p i n s pl_bram_top ] [ g e t _ b d _ i n tf _ p i n s s o c i u s _ x z _ b r a m _ s w i t c h _ b d / bram_top ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net p r o c e s s i n g _ s y s t e m 7 _ 0 _ D D R [ g e t _ b d _ i n t f _ p i n s ddr ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ i o _ p s _ b d / DDR ]
91

connect_bd_intf_net - intf_net p r o c e s s i n g _ s y s t e m 7 _ 0 _ F I X E D _ I O [ g e t _ b d _ i n t f _ p i n s fixed_io ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ i o _ p s _ b d / FIXED_IO ]

connect_bd_intf_net - intf_net p r o c e s s i n g _ s y s t e m 7 _ 0 _ S D I O _ 0 [ g e t _ b d _ i n t f _ p i n s sdio_0 ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ i o _ p s _ b d / SDIO_0 ]
connect_bd_intf_net - intf_net p r o c e s s i n g _ s y s t e m 7 _ 0 _ U S B I N D _ 0 [ g e t _ b d _ i n t f _ p i n s usbind_0 ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ i o _ p s _ b d / USBIND_0 ]
connect_bd_intf_net - intf_net s o c i u s _ x z _ i o _ p s _ b d _ M _ A X I _ G P 0 [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ b r a m _ s w i t c h _ b d / S00_AXI ] [ g e t _ b d _ i n t f _ p i n s s o c i u s _ x z _ i o _ p s_ b d / M_AXI_GP0 ]

# Create port connections

conn ect_bd_ net - net pl_int_bot_1 [ get_bd_pins pl_int_bot ] [ get_bd_pins xlconcat_0 / In3 ]
conn ect_bd_ net - net pl_int_mid_1 [ get_bd_pins pl_int_mid ] [ get_bd_pins xlconcat_0 / In1 ]
conn ect_bd_ net - net pl_int_soc_1 [ get_bd_pins pl_int_soc ] [ get_bd_pins xlconcat_0 / In0 ]
conn ect_bd_ net - net pl_int_top_1 [ get_bd_pins pl_int_top ] [ get_bd_pins xlconcat_0 / In2 ]
conn ect_bd_ net - net s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 0 [ get_bd_pins fclk_clk0 ] [ get_bd_pins s o c i u s _ x z _ i o _ p s _ b d / FCLK_CLK0 ]
conn ect_bd_ net - net s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 1 [ get_bd_pins fclk_clk1 ] [ get_bd_pins s o c i u s _ x z _ b r a m _ s w i t c h _ b d / S00_ACLK ] [ get_bd_pins s o c i u s _ xz _ io _ ps _b d / FCLK_CLK1 ]
[ get_bd_pins s o c i u s _ x z _ i o _ p s _ b d / M _AXI_GP0 _ACLK ] [ get_bd_pins s o c i u s _ x z _ i o _ p s _ b d / S_AXI_HP 0_ACLK ] [ get_bd_pins s o c i u s _ x z _ i o _ p s _ b d / S_AXI_ HP1_ACLK ]
[ get_bd_pins s o c i u s _ x z _ i o _ p s _ b d / S _AXI_HP2 _ACLK ] [ get_bd_pins s o c i u s _ x z _ i o _ p s _ b d / S_AXI_HP 3_ACLK ]
conn ect_bd_ net - net s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 2 [ get_bd_pins fclk_clk2 ] [ get_bd_pins s o c i u s _ x z _ i o _ p s _ b d / FCLK_CLK2 ]
conn ect_bd_ net - net s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 3 [ get_bd_pins fclk_clk3 ] [ get_bd_pins s o c i u s _ x z _ i o _ p s _ b d / FCLK_CLK3 ]
conn ect_bd_ net - net s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ R E S E T 0 _ N [ get_bd_pins fclk_reset0_n ] [ get_bd_pins s o c i u s _ x z _ b r a m _ s w i t c h _ b d / M01_ARESETN ]
[ get_bd_pins s o c i u s _ x z _ i o _ p s _ b d / FCLK_RESET0_N ]
conn ect_bd_ net - net x l co nc a t_ 0_ do u t [ get_bd_pins s o c i u s _ x z _ i o _ p s _ b d / IRQ_F2P ] [ get_bd_pins xlconcat_0 / dout ]

# Perform GUI Layout

r e g e n e r a t e _ b d _ l a y o u t - hierarchy [ get_bd_cells / so ci u s_ xz _ io _p s ] - layout_string {
guistr : " # # String gsaved with Nlview 6.5.5 2015 -06 -26 bk =1.3371 VDI =38 GEI =35 GUI = JA :1.8
# - string - flagsOSRD
preplace port pl_bram_mid - pg 1 -y 320 - defaultsOSRD
preplace port fixed_io - pg 1 -y 70 - defaultsOSRD
preplace port fclk_reset0_n - pg 1 -y 410 - defaultsOSRD
preplace port pl_bram_bot - pg 1 -y 300 - defaultsOSRD
preplace port uart_1 - pg 1 -y 90 - defaultsOSRD
preplace port iic_1 - pg 1 -y 110 - defaultsOSRD
preplace port spi_0 - pg 1 -y 130 - defaultsOSRD
preplace port fclk_clk0 - pg 1 -y 190 - defaultsOSRD
preplace port sdio_0 - pg 1 -y 150 - defaultsOSRD
preplace port ddr - pg 1 -y 50 - defaultsOSRD
preplace port fclk_clk1 - pg 1 -y 210 - defaultsOSRD
preplace port fclk_clk2 - pg 1 -y 230 - defaultsOSRD
preplace port fclk_clk3 - pg 1 -y 250 - defaultsOSRD
preplace port usbind_0 - pg 1 -y 170 - defaultsOSRD
preplace port pl_bram_top - pg 1 -y 360 - defaultsOSRD
preplace port pl_bram_soc - pg 1 -y 340 - defaultsOSRD
preplace portBus pl_int_bot - pg 1 -y 330 - defaultsOSRD
preplace portBus pl_int_mid - pg 1 -y 290 - defaultsOSRD
preplace portBus pl_int_top - pg 1 -y 310 - defaultsOSRD
preplace portBus pl_int_soc - pg 1 -y 270 - defaultsOSRD
preplace inst xlconcat_0 - pg 1 - lvl 1 -y 300 - defaultsOSRD
preplace inst s o c i u s _ x z _ i o _ p s _ b d - pg 1 - lvl 2 -y 170 - defaultsOSRD
preplace inst s o c i u s _ x z _ b r a m _ s w i t c h _ b d - pg 1 - lvl 3 -y 330 - defaultsOSRD
preplace netloc Conn1 1 2 2 NJ 120 NJ
preplace netloc p r o c e s s i n g _ s y s t e m 7 _ 0 _ D D R 1 2 2 NJ 40 NJ
preplace netloc Conn2 1 2 2 NJ 100 NJ
preplace netloc pl_int_top_1 1 0 1 N
preplace netloc Conn3 1 2 2 NJ 90 NJ
preplace netloc pl_int_bot_1 1 0 1 N
preplace netloc s o c i u s _ x z _ i o _ p s _ b d _ M _ A X I _ G P 0 1 2 1 630
preplace netloc pl_int_mid_1 1 0 1 N
preplace netloc s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 0 1 2 2 NJ 190 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 1 1 1 3 200 350 650 210 NJ
preplace netloc p r o c e s s i n g _ s y s t e m 7 _ 0 _ U S B I N D _ 0 1 2 2 NJ 160 NJ
preplace netloc xl c on ca t_ 0 _d ou t 1 1 1 N
preplace netloc s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 2 1 2 2 NJ 220 NJ
preplace netloc pl_int_soc_1 1 0 1 N
preplace netloc p r o c e s s i n g _ s y s t e m 7 _ 0 _ F I X E D _ I O 1 2 2 NJ 60 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 3 1 2 2 NJ 240 NJ
preplace netloc Conn12 1 3 1 NJ
preplace netloc Conn13 1 3 1 NJ
preplace netloc Conn14 1 3 1 NJ
preplace netloc p r o c e s s i n g _ s y s t e m 7 _ 0 _ S D I O _ 0 1 2 2 NJ 140 NJ
preplace netloc Conn15 1 3 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ R E S E T 0 _ N 1 2 2 620 410 NJ
levelinfo - pg 1 0 110 410 790 930 - top 0 - bot 430
",
}

# Restore current instance

c u r r e n t _ b d _ i n s t a n c e $oldCurInst
}

# Procedure to create entire design ; Provide argument to make

# procedure reusable . If parentCell is " " , will use root .
proc c r e a t e _ r o o t _ d e s i g n { parentCell } {

if { $parentCell eq " " } {

set parentCell [ get_bd_cells /]
}

# Get object for parentCell

set parentObj [ get_bd_cells $parentCell ]
if { $parentObj == " " } {
puts " ERROR : Unable to find parent cell < $parentCell >! "
return
}

# Make sure parentObj is hier blk

set parentType [ get_property TYPE $parentObj ]
if { $parentType ne " hier " } {
puts " ERROR : Parent < $parentObj > has TYPE = < $parentType >. Expected to be < hier >. "
return
}

# Save current instance ; Restore later

set oldCurInst [ c u r r e n t _ b d _ i n s t a n c e .]

# Set parent object as current

c u r r e n t _ b d _ i n s t a n c e $parentObj

# Create interface ports

set ddr3 [ c r e a t e _ b d _ i n t f _ p o r t - mode Master - vlnv xilinx . com : interface : ddrx_rtl :1.0 ddr3 ]
set fixed_io [ c r e a t e _ b d _ i n t f _ p o r t - mode Master - vlnv xilinx . com : d i s p l a y _ p r o c e s s i n g _ s y s t e m 7 : fixedio_rtl :1.0 fixed_io ]
set pl_bram_bot [ c r e a t e _ b d _ i n t f _ p o r t - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 pl_bram_bot ]
set_property - dict [ list \
CONFIG . MASTER_TYPE { BRAM_CTRL } \
] $pl_bram_bot
set pl_bram_mid [ c r e a t e _ b d _ i n t f _ p o r t - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 pl_bram_mid ]
set_property - dict [ list \
CONFIG . MASTER_TYPE { BRAM_CTRL } \
] $pl_bram_mid
set pl_bram_soc [ c r e a t e _ b d _ i n t f _ p o r t - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 pl_bram_soc ]
set_property - dict [ list \
CONFIG . MASTER_TYPE { BRAM_CTRL } \
 92

] $pl_bram_soc
set pl_bram_top [ c r e a t e _ b d _ i n t f _ p o r t - mode Master - vlnv xilinx . com : interface : bram_rtl :1.0 pl_bram_top ]
set_property - dict [ list \
CONFIG . MASTER_TYPE { BRAM_CTRL } \
] $pl_bram_top
set pl_iic_1 [ c r e a t e _ b d _ i n t f _ p o r t - mode Master - vlnv xilinx . com : interface : iic_rtl :1.0 pl_iic_1 ]
set pl_spi_0 [ c r e a t e _ b d _ i n t f _ p o r t - mode Master - vlnv xilinx . com : interface : spi_rtl :1.0 pl_spi_0 ]
set pl_uart_1 [ c r e a t e _ b d _ i n t f _ p o r t - mode Master - vlnv xilinx . com : interface : uart_rtl :1.0 pl_uart_1 ]
set sdio_0 [ c r e a t e _ b d _ i n t f _ p o r t - mode Master - vlnv xilinx . com : interface : sdio_rtl :1.0 sdio_0 ]
set usbind_0 [ c r e a t e _ b d _ i n t f _ p o r t - mode Master - vlnv xilinx . com : d i s p l a y _ p r o c e s s i n g _ s y s t e m 7 : usbctrl_rtl :1.0 usbind_0 ]

# Create ports
set pl_clk0 [ c reate_b d_port - dir O - type clk pl_clk0 ]
set pl_clk1 [ c reate_b d_port - dir O - type clk pl_clk1 ]
set pl_clk2 [ c reate_b d_port - dir O - type clk pl_clk2 ]
set pl_clk3 [ c reate_b d_port - dir O - type clk pl_clk3 ]
set pl_int_bot [ cre ate_bd_p ort - dir I - from 0 - to 0 pl_int_bot ]
set pl_int_mid [ cre ate_bd_p ort - dir I - from 0 - to 0 pl_int_mid ]
set pl_int_soc [ cre ate_bd_p ort - dir I - from 0 - to 0 pl_int_soc ]
set pl_int_top [ cre ate_bd_p ort - dir I - from 0 - to 0 pl_int_top ]
set pl_reset_n [ cre ate_bd_p ort - dir O - type rst pl_reset_n ]

# Create instance : so ci us _ xz _i o _p s
c r e a t e _ h i e r _ c e l l _ s o c i u s _ x z _ i o _ p s [ c u r r e n t _ b d _ i n s t a n c e .] s oc iu s_ x z_ io _ ps

# Create interface connections

c o n n e c t _ b d _ i n t f _ n e t - intf_net p r o c e s s i n g _ s y s t e m 7 _ 0 _ D D R [ g e t _ b d _ i n t f _ p o r t s ddr3 ] [ g e t _ b d _ i n t f _ p i n s s oc iu s _x z_ io _ ps / ddr ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net p r o c e s s i n g _ s y s t e m 7 _ 0 _ F I X E D _ I O [ g e t _ b d _ i n t f _ p o r t s fixed_io ] [ g e t _ b d _ i n t f _ p i n s s oc iu s _x z_ io _ ps / fixed_io ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net p r o c e s s i n g _ s y s t e m 7 _ 0 _ S D I O _ 0 [ g e t _ b d _ i n t f _ p o r t s sdio_0 ] [ ge t _ b d _ i n t f _ p i n s s oc iu s _x z_ i o_ ps / sdio_0 ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net p r o c e s s i n g _ s y s t e m 7 _ 0 _ U S B I N D _ 0 [ g e t _ b d _ i n t f _ p o r t s usbind_0 ] [ g e t _ b d _ i n t f _ p i n s s oc iu s _x z_ io _ ps / usbind_0 ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net s o c i u s _ x z _ i o _ p s _ I I C _ 1 [ g e t _ b d _ i n t f _ p o r t s pl_iic_1 ] [ g e t _ bd _ i n t f _ p i n s s oc i us _x z_ i o_ ps / iic_1 ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net s o c i u s _ x z _ i o _ p s _ S P I _ 0 [ g e t _ b d _ i n t f _ p o r t s pl_spi_0 ] [ g e t _ bd _ i n t f _ p i n s s oc i us _x z_ i o_ ps / spi_0 ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net s o c i u s _ x z _ i o _ p s _ U A R T _ 1 [ g e t _ b d _ i n t f _ p o r t s pl_uart_1 ] [ g e t _ b d _ i n t f _ p i n s so ci u s_ xz _ io _p s / uart_1 ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net s o c i u s _ x z _ i o _ p s _ b r a m _ b o t [ g e t _ b d _ i n t f _ p o r t s pl_bram_bot ] [ g e t _ b d _ i n t f _ p i n s so ci u s_ xz _i o _p s / pl_bram_bot ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net s o c i u s _ x z _ i o _ p s _ b r a m _ m i d [ g e t _ b d _ i n t f _ p o r t s pl_bram_mid ] [ g e t _ b d _ i n t f _ p i n s so ci u s_ xz _i o _p s / pl_bram_mid ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net s o c i u s _ x z _ i o _ p s _ b r a m _ s o c [ g e t _ b d _ i n t f _ p o r t s pl_bram_soc ] [ g e t _ b d _ i n t f _ p i n s so ci u s_ xz _i o _p s / pl_bram_soc ]
c o n n e c t _ b d _ i n t f _ n e t - intf_net s o c i u s _ x z _ i o _ p s _ b r a m _ t o p [ g e t _ b d _ i n t f _ p o r t s pl_bram_top ] [ g e t _ b d _ i n t f _ p i n s so ci u s_ xz _i o _p s / pl_bram_top ]

# Create port connections

conn ect_bd_ net - net In0_1 [ get_bd_ports pl_int_mid ] [ get_bd_pins so ci us _ xz _i o _p s / pl_int_mid ]
conn ect_bd_ net - net In1_2 [ get_bd_ports pl_int_top ] [ get_bd_pins so ci us _ xz _i o _p s / pl_int_top ]
conn ect_bd_ net - net In2_2 [ get_bd_ports pl_int_bot ] [ get_bd_pins so ci us _ xz _i o _p s / pl_int_bot ]
conn ect_bd_ net - net In3_1 [ get_bd_ports pl_int_soc ] [ get_bd_pins so ci us _ xz _i o _p s / pl_int_soc ]
conn ect_bd_ net - net s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 0 [ get_bd_ports pl_clk0 ] [ get_bd_pins s oc iu s_ x z_ io _p s / fclk_clk0 ]
conn ect_bd_ net - net s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 1 [ get_bd_ports pl_clk1 ] [ get_bd_pins s oc iu s_ x z_ io _p s / fclk_clk1 ]
conn ect_bd_ net - net s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 2 [ get_bd_ports pl_clk2 ] [ get_bd_pins s oc iu s_ x z_ io _p s / fclk_clk2 ]
conn ect_bd_ net - net s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 3 [ get_bd_ports pl_clk3 ] [ get_bd_pins s oc iu s_ x z_ io _p s / fclk_clk3 ]
conn ect_bd_ net - net s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ R E S E T 0 _ N [ get_bd_ports pl_reset_n ] [ get_bd_pins so ci us _ xz _i o _p s / fclk_reset0_n ]

# Create address segments

c r e a t e _ b d _ a d d r _ s e g - range 0 x10000 - offset 0 x40030000 [ g e t _ b d _ a d d r _ s p a c e s so ci u s_ xz _ io _p s / s o c i u s _ x z _ i o _ p s _ b d / Data ]
[ g e t _ b d _ a d d r _ s e g s so ci u s_ xz _ io _p s / s o c i u s _ x z _ b r a m _ s w i t c h _ b d / s o c i u s _ x z _ b r a m _ i f _ p l _ b o t / S_AXI / Mem0 ] S E G _ s o c i u s _ x z _ b r a m _ i f _ p l _ b o t _ M e m 0
c r e a t e _ b d _ a d d r _ s e g - range 0 x10000 - offset 0 x40010000 [ g e t _ b d _ a d d r _ s p a c e s so ci u s_ xz _ io _p s / s o c i u s _ x z _ i o _ p s _ b d / Data ]
[ g e t _ b d _ a d d r _ s e g s so ci u s_ xz _ io _p s / s o c i u s _ x z _ b r a m _ s w i t c h _ b d / s o c i u s _ x z _ b r a m _ i f _ p l _ m i d / S_AXI / Mem0 ] S E G _ s o c i u s _ x z _ b r a m _ i f _ p l _ m i d _ M e m 0
c r e a t e _ b d _ a d d r _ s e g - range 0 x10000 - offset 0 x40000000 [ g e t _ b d _ a d d r _ s p a c e s so ci u s_ xz _ io _p s / s o c i u s _ x z _ i o _ p s _ b d / Data ]
[ g e t _ b d _ a d d r _ s e g s so c iu s_ xz _ io _p s / s o c i u s _ x z _ b r a m _ s w i t c h _ b d / s o c i u s _ x z _ b r a m _ i f _ p l _ s o c / S_AXI / Mem0 ] S E G _ s o c i u s _ x z _ b r a m _ i f _ p l _ s o c _ M e m 0
c r e a t e _ b d _ a d d r _ s e g - range 0 x10000 - offset 0 x40020000 [ g e t _ b d _ a d d r _ s p a c e s so ci u s_ xz _ io _p s / s o c i u s _ x z _ i o _ p s _ b d / Data ]
[ g e t _ b d _ a d d r _ s e g s so c iu s_ xz _ io _p s / s o c i u s _ x z _ b r a m _ s w i t c h _ b d / s o c i u s _ x z _ b r a m _ i f _ p l _ t o p / S_AXI / Mem0 ] S E G _ s o c i u s _ x z _ b r a m _ i f _ p l _ t o p _ M e m 0

# Perform GUI Layout

r e g e n e r a t e _ b d _ l a y o u t - layout_string {
guistr : " # # String gsaved with Nlview 6.5.5 2015 -06 -26 bk =1.3371 VDI =38 GEI =35 GUI = JA :1.8
# - string - flagsOSRD
preplace port pl_spi_0 - pg 1 -y 130 - defaultsOSRD
preplace port pl_bram_mid - pg 1 -y 210 - defaultsOSRD
preplace port fixed_io - pg 1 -y 70 - defaultsOSRD
preplace port pl_uart_1 - pg 1 -y 150 - defaultsOSRD
preplace port pl_iic_1 - pg 1 -y 90 - defaultsOSRD
preplace port pl_bram_bot - pg 1 -y 190 - defaultsOSRD
preplace port pl_clk0 - pg 1 -y 270 - defaultsOSRD
preplace port pl_clk1 - pg 1 -y 290 - defaultsOSRD
preplace port sdio_0 - pg 1 -y 110 - defaultsOSRD
preplace port pl_reset_n - pg 1 -y 350 - defaultsOSRD
preplace port pl_clk2 - pg 1 -y 310 - defaultsOSRD
preplace port pl_clk3 - pg 1 -y 330 - defaultsOSRD
preplace port usbind_0 - pg 1 -y 170 - defaultsOSRD
preplace port pl_bram_top - pg 1 -y 250 - defaultsOSRD
preplace port pl_bram_soc - pg 1 -y 230 - defaultsOSRD
preplace port ddr3 - pg 1 -y 50 - defaultsOSRD
preplace portBus pl_int_bot - pg 1 -y 170 - defaultsOSRD
preplace portBus pl_int_mid - pg 1 -y 190 - defaultsOSRD
preplace portBus pl_int_top - pg 1 -y 230 - defaultsOSRD
preplace portBus pl_int_soc - pg 1 -y 210 - defaultsOSRD
preplace inst s o ci us _x z _i o_ ps - pg 1 - lvl 1 -y 200 - defaultsOSRD
preplace netloc p r o c e s s i n g _ s y s t e m 7 _ 0 _ D D R 1 1 1 NJ
preplace netloc In1_2 1 0 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b r a m _ t o p 1 1 1 NJ
preplace netloc In2_2 1 0 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ S P I _ 0 1 1 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b r a m _ b o t 1 1 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b r a m _ s o c 1 1 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ I I C _ 1 1 1 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 0 1 1 1 NJ
preplace netloc In0_1 1 0 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 1 1 1 1 NJ
preplace netloc p r o c e s s i n g _ s y s t e m 7 _ 0 _ U S B I N D _ 0 1 1 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 2 1 1 1 NJ
preplace netloc In3_1 1 0 1 NJ
preplace netloc p r o c e s s i n g _ s y s t e m 7 _ 0 _ F I X E D _ I O 1 1 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ C L K 3 1 1 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b r a m _ m i d 1 1 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ U A R T _ 1 1 1 1 NJ
preplace netloc p r o c e s s i n g _ s y s t e m 7 _ 0 _ S D I O _ 0 1 1 1 NJ
preplace netloc s o c i u s _ x z _ i o _ p s _ b d _ F C L K _ R E S E T 0 _ N 1 1 1 NJ
levelinfo - pg 1 -30 150 370 - top 0 - bot 400
",
}

# Restore current instance

c u r r e n t _ b d _ i n s t a n c e $oldCurInst

save _bd_des ign

}
# End of c r e a t e _ r o o t _ d e s i g n ()

##################################################################
# MAIN FLOW
##################################################################

create_root_design ""
93

3. Execute the presented Tcl file in the Vivado IDE. Go to the Tcl console window and type the following
and press enter:

source <path>/socius xz io ps bd.tcl

<path> stands for the full path to the folder where the socius xz io ps bd.tcl Tcl file is stored.

Figure 3.2: Tcl Console window

After Vivado has finished with the Tcl script execution, a created block diagram containing Zynq PS will
be visible in the Vivado IDE, as shown on the Figure 3.3.

Figure 3.3: Block diagram of Zynq PS configured to run on socius board

4. The next step will be to add all the necessary IPs into the design canvas.

Note: For details how to add necessary IPs into the Vivado project, please look at the ”Chapter 12.2
IP Integrator” in the ”Basic FPGA Tutorial”.

Add the following IPs into the design canvas:

• hls modulator v1.0 (modulator 0 )

• Binary Counter (c counter binary 0 )
• ILA (Integrated Logic Analyzer) (ila 0 )
• VIO (Virtual Input/Output) (vio 0 )
 94

• Utility Vector Logic (util vector logic 0 )

• 2x Constant (xconstant)

After adding all the necessary IPs into the design canvas, it should look like the same as it is shown on
the Figure 3.4

Figure 3.4: IP Integrator design canvas with instantiated all the necessary IPs

The next step will be to make all the necessary IP re-customizations.

5. Double-click on the Binary Counter (c counter binary 0 ) IP and in the Binary Counter (12.0) Re-
customization IP dialog box set the following parameters:

• in the Basic tab:

– set Output Width value to 32, see Figure 3.5 and

95

Figure 3.5: Binary Counter (12.0) re-customization IP dialog box - Basic tab

• in the Control tab:

– enable Clock Enable (CE) and Synchronous Clear (SCLR) options, see Figure 3.6 and
click OK.
 96

Figure 3.6: Binary Counter (12.0) re-customization IP dialog box - Control tab

6. Double-click on the Utility Vector Logic ((util vector logic 0 ) IP and in the Utility Vector Logic
(2.0) Re-customization IP dialog box set the following parameters:

• change the C OPERATION to not and

• set the C SIZE to be 1, see Figure 3.7, and

• click OK.
97

Figure 3.7: Utility Vector Logic (2.0) re-customization IP dialog box

7. Double-click on the ILA IP and in the ILA (Integrated Logic Analzyer (6.2)) dialog box, in the
General Options, set the following parameters:

• select Native as Monitor Type

• set 2 as Number of Probes

• enable Capture Control option in the Trigger And Storage Settings section, as it is shown on
the Figure 3.8.
 98

Figure 3.8: ILA (Integrated Logic Analyzer (6.2)) Re-customize IP dialog box - General Options

and in the Probe Ports(0..7), set the following parameters:

• set 32 bits as Probe Width[1..4096] value of PROBE0 probe, as it is shown on the Figure 3.9,
and

• click OK.
99

Figure 3.9: ILA (Integrated Logic Analyzer (6.2)) Re-customize IP dialog box - Probe Ports(0..7)

8. In case of 2x Constant (xconstant) IP cores:

• leave Constant (xconstant 0 ) IP core with default values, where Const Val value is 1, and

• in the Constant (xconstant 1 ) IP core, change the Const Val value to be 0, see Figure 3.9.
 100

Figure 3.10: Constant Re-customize IP dialog box

9. In case of VIO (Virtual Input/Output) (vio 0 ) and hls modulator v1.0 (modulator 0 ) IP cores,
leave all parameters unchanged.

After all the necessary IP re-customizations, the IP Integrator design canvas should look as it is shown
on the Figure 3.10.

Figure 3.11: IP Integrator design canvas after all necessary IP re-customizations

101

10. Next step will be to manually connect the IPs. Connect all the IPs on the same way as it is shown on the
Figure 3.11.

Figure 3.12: IP Integrator design canvas with manually connected IPs

Note: As you can see from the Figure 3.11 we connected all the IPs, except:

• all clock ports, and

• ap done, ap idle and ip ready ports of the hls modulator v1.0 ap ctrl bus.

11. In the IP Integrator window, click the Run Connection Automation link and the list of the ports/in-
terfaces that can use the Connection Automation feature will show up.

12. In the Run Connection Automation dialog box enable All Automation (0 out of 4 selected) and
click OK.

After running the connection automation, the connections will be made and highlighted in the IP Integrator
design canvas, see Figure 3.12.
 102

Figure 3.13: IP Integrator design canvas after running connection automation

13. From the sidebar menu of the design canvas, run the IP subsystem design rule checks by clicking the
Validate Design button.

14. In the Validate Design dialog box, click OK.

15. At this point, you should save the IP integrator design. Use the File -> Save Block Design command
from the main menu to save the design.

16. Now is the time to create constraints file for the Socius board, modulator socius.xdc. Open Vivado
text editor, copy your constraints code in it or write directly in it and save the constraints file in your
working directory. The complete modulator socius.xdc constraints file you can find in the text below.

Note: If you do not know how to add constraints files to the project, please see Sub-chapter 10.1 Creating
XDC File for XDC constraints file, in the Basic FPGA Tutorial.

modulator socius.xdc

# ##############################################################################
# File : s o c i u s _ x z _ g e n e r a l . xdc
# Project : socius
# Creation : 2015 -04 -01
# Limitations : none
# Errors : none known
# Simulator : none
# Synthesizer : none
# Platform :
# Targets : Implem entation
# #################################
# Naming conv . : lower case
# #################################
# Authors : thor
# Organization : so - logic
# Email : thor@so - logic . net
# Address : Lustkandlg . 52 , A -1090 Vienna Austria / Europe / Earth
# ##############################################################################
# Copyright Notice
# Copying of this document and giving it to others and the
# communication of the contents thereof is forbidden without authority .
# Offenders are liable to payment of damages . All rights are reserved in
# event of the grant or patent of the utility model or design .
# ##############################################################################
# bitsream option
103

# false path between clock domains

# power analzer options
# ##############################################################################

# set properties for bitstream genration

set_property BITSTREAM . GENERAL . COMPRESS TRUE [ curr ent_des ign ]
# set_property BITSTREAM . GENERAL . X A D C E N H A N C E D L I N E A R I T Y ON [ curren t_design ]
# set_property BITSTREAM . GENERAL . XADCPOWERDOWN ENABLE [ curre nt_desig n ]

# set configuration bank voltages

set_property CFGBVS VCCO [ current _design ]
set_property CON FIG_VOL TAGE 3.3 [ cur rent_de sign ]

# set condition for power analyzer

s e t _ o p e r a t i n g _ c o n d i t i o n s - ambient_temp 50
s e t _ o p e r a t i n g _ c o n d i t i o n s - board small
s e t _ o p e r a t i n g _ c o n d i t i o n s - airflow 250
s e t _ o p e r a t i n g _ c o n d i t i o n s - heatsink low
s e t _ o p e r a t i n g _ c o n d i t i o n s - board_layers 12 to15

# unrelate clock domains in PL for clocks genrated in PS f

# set_false_path - from [ get_clocks clk_fpga_1 ] - to [ get_clocks clk_fpga_0 ]
# set_false_path - from [ get_clocks clk_fpga_0 ] - to [ get_clocks clk_fpga_1 ]
# set_clock_groups - asynchronous - group clk_fpga_0 - group clk_fpga_1

# only for power designs

# set_property C _ C L K _ I N P U T _ F R E Q _ H Z 300000000 [ g et _ de bu g _c or es dbg_hub ]
# set_property C _ E N A B L E _ C L K _ D I V I D E R false [ ge t_ d eb ug _c o re s dbg_hub ]
# set_property C_U S E R _ S C A N _ C H A I N 1 [ g et _d e bu g_ co r es dbg_hub ]
# co n ne c t_ de b ug _ po r t dbg_hub / clk [ get_nets pl_clk3 ]

# Push flip flops to IOBs

# set_property IOB true [ get_cells - hier * io_i_s_reg *]
# set_property IOB true [ get_cells - hier * io_o_reg *]
# set_property IOB true [ get_cells - hier * io_t_reg *]

# PL pins with fixed functionality for xz1 and xz2

set_property PACKAGE_PIN M14 [ get_ports pl_b35_m14_io ]

set_property IOSTANDARD LVCMOS33 [ get_ports pl_b35_m14_io ]
s et_output_delay - clock [ get_clocks clk_fpga_0 ] - max 1.000 [ get_ports pl_b35_m14_io ]
s et_output_delay - clock [ get_clocks clk_fpga_0 ] - min 0.500 [ get_ports pl_b35_m14_io ]

set_property PACKAGE_PIN M15 [ get_ports pl_b35_m15_io ]

set_property IOSTANDARD LVCMOS33 [ get_ports pl_b35_m15_io ]
s et_output_delay - clock [ get_clocks clk_fpga_0 ] - max 1.000 [ get_ports pl_b35_m15_io ]
s et_output_delay - clock [ get_clocks clk_fpga_0 ] - min 0.500 [ get_ports pl_b35_m15_io ]

set_property PACKAGE_PIN T19 [ get_ports pl_hsw_good_i ]

set_property IOSTANDARD LVCMOS33 [ get_ports pl_hsw_good_i ]
s et_input_delay - clock [ get_clocks clk_fpga_0 ] - max 5.000 [ get_ports pl_hsw_good_i ]
s et_input_delay - clock [ get_clocks clk_fpga_0 ] - min 4.500 [ get_ports pl_hsw_good_i ]

set_property PACKAGE_PIN V13 [ get_ports p l _ p h y _ r e s e t _n _ o ]

set_property IOSTANDARD LVCMOS33 [ get_ports p l _ p h y _ r es e t _ n _ o ]

set_property PACKAGE_PIN T15 [ get_ports pl_sd_cd_n_i ]

set_property IOSTANDARD LVCMOS33 [ get_ports pl_sd_cd_n_i ]

set_property PACKAGE_PIN J15 [ get_ports pl_pwm_fan_o ]

set_property IOSTANDARD LVCMOS33 [ get_ports pl_pwm_fan_o ]

set_property PACKAGE_PIN R19 [ get_ports pl_pwr_en_i ]

set_property IOSTANDARD LVCMOS33 [ get_ports pl_pwr_en_i ]
s et_input_delay - clock [ get_clocks clk_fpga_0 ] - max 5.000 [ get_ports pl_pwr_en_i ]
s et_input_delay - clock [ get_clocks clk_fpga_0 ] - min 4.500 [ get_ports pl_pwr_en_i ]

set_property PACKAGE_PIN G14 [ get_ports pl_rtc_out_i ]

set_property IOSTANDARD LVCMOS33 [ get_ports pl_rtc_out_i ]
s et_input_delay - clock [ get_clocks clk_fpga_0 ] - max 5.000 [ get_ports pl_rtc_out_i ]
s et_input_delay - clock [ get_clocks clk_fpga_0 ] - min 4.500 [ get_ports pl_rtc_out_i ]

set_property PACKAGE_PIN U13 [ get_ports p l _ u s b _ r e s e t _n _ o ]

set_property IOSTANDARD LVCMOS33 [ get_ports p l _ u s b _ r es e t _ n _ o ]
s et_output_delay - clock [ get_clocks clk_fpga_0 ] - min 1.000 [ get_ports p l_ u s b _ r e s e t _ n _ o ]
s et_output_delay - clock [ get_clocks clk_fpga_0 ] - max 0.500 [ get_ports p l_ u s b _ r e s e t _ n _ o ]

set_property PACKAGE_PIN T14 [ get_ports p l _ u s b _ f a u l t _n _ i ]

set_property IOSTANDARD LVCMOS33 [ get_ports p l _ u s b _ f au l t _ n _ i ]
s et_input_delay - clock [ get_clocks clk_fpga_0 ] - max 5.000 [ get_ports p l _ us b _ f a u l t _ n _ i ]
s et_input_delay - clock [ get_clocks clk_fpga_0 ] - min 4.500 [ get_ports p l _ us b _ f a u l t _ n _ i ]

# set_property PACKAGE_PIN M14 [ get_ports pl_b35_m14_io ]

# set_property IOSTANDARD LVCMOS33 [ get_ports pl_b35_m14_io ]
# set_output_delay - clock [ get_clocks clk_fpga_0 ] - max 1.000 [ get_ports pl_b35_m14_io ]
# set_output_delay - clock [ get_clocks clk_fpga_0 ] - min 0.500 [ get_ports pl_b35_m14_io ]

# set_property PACKAGE_PIN M15 [ get_ports pl_b35_m15_io ]

# set_property IOSTANDARD LVCMOS33 [ get_ports pl_b35_m15_io ]
# set_output_delay - clock [ get_clocks clk_fpga_0 ] - max 1.000 [ get_ports pl_b35_m15_io ]
# set_output_delay - clock [ get_clocks clk_fpga_0 ] - min 0.500 [ get_ports pl_b35_m15_io ]
 104

# set_property PACKAGE_PIN T19 [ get_ports pl_hsw_good_i ]

# set_property IOSTANDARD LVCMOS33 [ get_ports pl_hsw_good_i ]
# set_input_delay - clock [ get_clocks clk_fpga_0 ] - max 5.000 [ get_ports pl_hsw_good_i ]
# set_input_delay - clock [ get_clocks clk_fpga_0 ] - min 4.500 [ get_ports pl_hsw_good_i ]

# set_property PACKAGE_PIN V13 [ get_ports p l _ p h y _ r e s e t _ n _ o ]

# set_property IOSTANDARD LVCMOS33 [ get_ports p l _ p h y _ r e s e t _ n _ o ]
# set_output_delay - clock [ get_clocks clk_fpga_1 ] - max 1.000 [ get_ports p l _ p hy _ r e s e t _ n _ o ]
# set_output_delay - clock [ get_clocks clk_fpga_1 ] - min 0.500 [ get_ports p l _ p hy _ r e s e t _ n _ o ]

# set_property PACKAGE_PIN T15 [ get_ports pl_sd_cd_n_i ]

# set_property IOSTANDARD LVCMOS33 [ get_ports pl_sd_cd_n_i ]

# set_property PACKAGE_PIN J15 [ get_ports pl_pwm_fan_o ]

# set_property IOSTANDARD LVCMOS33 [ get_ports pl_pwm_fan_o ]
# set_output_delay - clock [ get_clocks clk_fpga_1 ] - max 1.000 [ get_ports pl_pwm_fan_o ]
# set_output_delay - clock [ get_clocks clk_fpga_1 ] - min 0.500 [ get_ports pl_pwm_fan_o ]

# set_property PACKAGE_PIN R19 [ get_ports pl_pwr_en_i ]

# set_property IOSTANDARD LVCMOS33 [ get_ports pl_pwr_en_i ]
# set_input_delay - clock [ get_clocks clk_fpga_0 ] - max 5.000 [ get_ports pl_pwr_en_i ]
# set_input_delay - clock [ get_clocks clk_fpga_0 ] - min 4.500 [ get_ports pl_pwr_en_i ]

# set_property PACKAGE_PIN G14 [ get_ports pl_rtc_out_i ]

# set_property IOSTANDARD LVCMOS33 [ get_ports pl_rtc_out_i ]
# set_input_delay - clock [ get_clocks clk_fpga_0 ] - max 5.000 [ get_ports pl_rtc_out_i ]
# set_input_delay - clock [ get_clocks clk_fpga_0 ] - min 4.500 [ get_ports pl_rtc_out_i ]

# set_property PACKAGE_PIN U13 [ get_ports p l _ u s b _ r e s e t _ n _ o ]

# set_property IOSTANDARD LVCMOS33 [ get_ports p l _ u s b _ r e s e t _ n _ o ]
# set_output_delay - clock [ get_clocks clk_fpga_0 ] - min 1.000 [ get_ports p l _ u sb _ r e s e t _ n _ o ]
# set_output_delay - clock [ get_clocks clk_fpga_0 ] - max 0.500 [ get_ports p l _ u sb _ r e s e t _ n _ o ]

# set_property PACKAGE_PIN T14 [ get_ports p l _ u s b _ f a u l t _ n _ i ]

# set_property IOSTANDARD LVCMOS33 [ get_ports p l _ u s b _ f a u l t _ n _ i ]
# set_input_delay - clock [ get_clocks clk_fpga_0 ] - max 5.000 [ get_ports p l _ u s b _ f a u l t _ n _ i ]
# set_input_delay - clock [ get_clocks clk_fpga_0 ] - min 4.500 [ get_ports p l _ u s b _ f a u l t _ n _ i ]

17. Synthesize your design with Run Synthesis option from the Flow Navigator / Synthesis (see ”Sub-
chapter 6.5.2 Run Synthesis”, in the ”Basic FPGA Tutorial”).

18. Implement your design with Run Implementation option from the Flow Navigator / Implementa-
tion (see ”Sub-chapter 10.2.2 Run Implementation”, in the ”Basic FPGA Tutorial”).

19. Generate bitstream file with ”Generate Bitstream” option from the Flow Navigator / Program
and Debug (see Sub-Chapter 10.3 Generate Bitstream File, in the ”Basic FPGA Tutorial”).

20. Program your Socius device (see ”Sub-Chapter 10.4 Program Device”, in the ”Basic FPGA Tutorial”).

Note: Because of using Socius development board, it is necessary to arm the processor that is present on
the board. To arm the processor you have to run some dummy application (e.g. hello world) using the
SDK tool. If you are not familiar with this procedure, open the ”Sub-Chapter 10.4 Program Device”, in
the ”Basic FPGA Tutorial” where you can find all of these information and more.

3.3 Debug the design with included developed IP core

Vivado Logic Analyzer is an integrated logic analyzer in the Vivado Design Suite. In this chapter you will
learn how to debug your ARM-based system using the Vivado logic analyzer and you will take advantage of it’s
functions to debug and discover some potential root causes of your design.

The next step in our design process is to set up the ILA core. When the debug cores are detected upon
refreshing a hardware device, the default dashboard for each debug core is automatically opened. The default
ILA Dashboard can be seen on the Figure 3.14.
105

Figure 3.14: ILA Dashboard

1. Open the VIO dashboard by clicking the hw vios tab and press blue + button in the middle of the VIO
dashboard to add the probes.

2. In the Add Probes window select both offered modulator 0 pwm out V 1 and vio 0 probe out0
probes and click OK, see Figure 3.15.

Figure 3.15: Add Probes to the VIO window

Note: In the VIO Probes window, you can observe the rate of change of the modulator 0 pwm out V 1
signal. You can change the frequency of the modulator 0 pwm out V 1 signal by changing the value
of the vio 0 probe out0 probe from 0 to 1 and from 1 to 0. The default vio 0 probe out0 value is 0.
 106

3. Turn back to the ILA dashboard by clicking the h ila 1 tab and in the Trigger Setup window press
blue + button in the middle to add the probes.

4. In the Add Probes window select modulator 0 pwm out V 1 probe and click OK.

5. Now, when the ILA debug probe modulator 0 pwm out V 1 is in the Trigger Setup window, we will
create trigger conditions and debug probe compare values. In the Trigger Setup window, leave ==
(equal) value in the Operator cell, [H] (Hexadecimal) value in the Radix cell and set the Value
parameter to be 0 (logical zero), as it is shown on the Figure 3.16.

Figure 3.16: Changing the Compare Values in the Trigger Setup window

6. In the ILA Settings window, change the Capture mode to be BASIC in the Capture Mode Settings
section, see Figure 3.17.

Figure 3.17: ILA Settings window

7. In the Capture Setup window press blue + button in the middle to add the probes.

8. In the Add Probes window select only modulator 0 pwm out V 1 probe and click OK, see Figure
3.18.

9. In the Capture Setup window, leave == (equal) value in the Operator cell, [B] (Binary) value in
the Radix cell and set the Value parameter to be F (1-to-0 transition), as it is shown on the Figure
3.18.
107

Figure 3.18: Changing the Compare Values in the Capture Setup window

10. After we set all the ILA core parameters, we can run or arming the ILA core trigger.

Once the ILA core captured data has been uploaded to the Vivado IDE, it is displayed in the Waveform
Viewer, see Figure 3.19.

Note: After triggering the ILA core, in the waveform viewer change the c counter binary 0 Q[31:0] Wave-
form Style from Digital to Analog, and your captured waveform should look like as the waveform on
the Figure 3.19.

Figure 3.19: Captured waveform of the sine signal, when sw0=0

11. Turn back to the VIO Probes window and change the Value of the vio 0 probe out0 signal from 0 to
1.
12. Arm the trigger ones more and after triggering the ILA core your captured waveform should look like as
the waveform on the Figure 3.20.

Figure 3.20: Captured waveform of the sine signal, when sw0=1

By comparing the waveforms shown on Figures 3.19 and 3.20 we can observe that they differ in the amplitude
value. This is expected since the waveforms actually represent the width of the PWM pulse generated by the
 108

modulator module. Since the frequencies of two generated PWM signals differ (one has a frequency of 1 Hz
and the other of 3.5 Hz) and the PWM pulse width measurement module always uses the same frequency for
measuring the duration of the PWM pulse, when the PWM frequency increases the duration of the PWM pulse
will decrease, therefore decreasing the amplitude of the output signal of the PWM pulse width measurement
module.