1. Vivado Design Flow for SoC
Cristian Sisterna
Universidad Nacional de San Juan
Argentina
Vivado
ICTP

2. Why Vivado Design Suite?
Larger FPGAs lead to more difficult design issues
Users integrating more functionality into the FPGA
Use of multiple hard logic objects (block RAMs, GTs, DSP slices, and microprocessors, for example)
I/O and clock planning critical to FPGA performance
Higher routing and utilization density
Complex timing constraints with designs that have multiple clock domains
FPGA designs are now looking like ASIC platform designs
Assembled from IP cores—commercial or developed in-house
Maintaining place and route solutions is very important (this is resolved with the use of partitions)
Bottom-up design methodology
Team design flows becoming a necessity
Vivado Design Suite provides solution to all of the above
Vivado
ICTP

3. Hierarchical Design Analysis and Implementation Environment
Vivado IDE Solution
Interactive design and analysis
Timing analysis, connectivity, resource utilization, timing constraint analysis
RTL development and analysis
Elaboration of HDL
Hierarchical exploration
Schematic generation
XSIM simulator integration
Synthesis, implementation and simulation in one package
I/O pin planning
Interactive rule-based I/O assignment
Hierarchical Design Analysis and Implementation Environment
Vivado
ICTP

4. Vivado Visualization Features
Visualize and debug a design at any flow stage
Cross-probing between netlist/schematic/RTL
Vivado
ICTP

5. Gain Faster Timing Closure
Analyze multiple implementation results
Highlight failing timing paths from post-route timing analysis
Quickly identify and constrain critical logic path
Connectivity display
I/Os, net bundles, clock domains
Hierarchical floorplanning
Guide place & route toward better results
The Vivado IDE provides a comprehensive environment for analyzing timing issues and easily constraining timing-critical logic to improve performance. Results can be used to plan a floorplan of the design by determining what logic should be grouped together and where it should placed on the die. When timing-critical logic is grouped closer together, the implementation tools can use faster routing resources to improve timing.
Grouping logic is performed with physical blocks (called Pblocks) by selecting logic in a variety of different ways.
The Vivado IDE also provides resource utilization estimates to help size any Pblocks. These same statistics report clock information, carry chain size, and a variety of other useful information.
The Vivado IDE provides excellent insight into the design by displaying I/O interconnect as well as Pblock net bundles. Inter-Pblock net bundles change color and size depending on the number of signals shared by Pblocks. This makes it easy to see heavily connected Pblocks and the data flow through the FPGA. Designers can then take corrective action to place heavily connected Pblocks closer or merge them into one Pblock.
Utilization estimates
All resource types shown for each Pblock
Clocks or carry chains
Vivado
ICTP

6. Tool Command Line (.tcl) Features
Tcl Console enables the designer to actively query the design netlist
Full Tcl scripting support in two design flows
Project-based design flow provides easy project management by the Vivado IDE
Non-project batch design flow enables entire flow to be executed in memory
Journal and log files can be used for script construction
Vivado
ICTP

7. Vivado Design Suite Introduction
ICTP

8. Typical vs Vivado Design Flow
Interactive IP plug-n-play environment
AXI4, IP_XACT
Common constraint language (XDC) throughout flow
Apply constraints at any stage
Reporting at any stage
Robust Tcl API
Common data model throughout the flow
“In memory” model improves speed
Generate reports at all stages
Save checkpoint designs at any stage
Netlist, constraints, place and route results
synth_design is normal except that it now can read in XDC constraints into synthesis. The Vivado IDE includes a timing-driven synthesis tool that uses a common constraint language throughout the flow. From synthesis all the way through place and route.
Netlist linking is done in link_design. Here if you do have third-party EDF, the files can be read into the Vivado IDE.
opt_design, power_opt_design, and place_design are the packing and placement functions. power_opt_design is optional, however.
phys_opt_design is also optional. The significant thing is that all of data is stored in one data model.
You can run that entire flow in memory and never write anything files out when using the non-project batch design flow. But in any flow there is no data translation, no data model. There are huge advantages to that in terms of speed. Checkpoints can be saved at any stage of the design flow when using the non-project batch design flow. A checkpoint is basically a snapshot of your design in time. All of these commands can be scripted, so the flow is very flexible.
The single data model in memory allows you to do a lot of things, such as cross-probing and fixing your timing at the end of the implementation without having to reimplement again.
Vivado
ICTP

9. Project Data and Directories
All project data is stored in a project_name directory containing the following directories
project_name.xpr file: Object that is selected to open a project (Vivado IDE project file)
project_name.runs directory: Contains all run data
project_name.srcs directory: Contains all imported local HDL source files, netlists, and XDC files
project_name.data directory: Stores floorplan and netlist data
Vivado
ICTP

10. Journal and Log Files Journal file (vivado.jou) Log file (vivado.log)
Contains just the Tcl commands executed by the Vivado IDE
Log file (vivado.log)
Contains all messages produced by the Vivado IDE, including Tcl commands and results, info, warning, error messages, etc.
Location
Linux: directory where the Vivado IDE is invoked
Windows via icon: %APPDATA%\Xilinx\Vivado or C:\Users\<user_name>\AppData\Roaming\Xilinx\Vivado
Windows via command line: directory where the Vivado IDE is invoked
From the GUI
Select File > Open Log File
Select File > Open Journal File
Vivado
ICTP

11. Embedded System Design – Vivado Flow
Create Project
(Block Design)
Spec
IPs
Synthesis
Constraints
Constraints
Optional
HDL
Implementation
Constraints
Elaborate
Timing Verification
Optional
Behavioral Verification
Optional
Bitstream Generation / Hardware Export
Vivado
ICTP

12. Vivado Flow Practical Steps
As FPGAs become larger and more complex, and as design schedules become shorter, use of third-party IP and design reuse is becoming mandatory. Xilinx® recognizes the
challenges designers face, and to aid designers with design and reuse issues, has created a powerful feature within the Vivado® Design Suite called the Vivado IP integrator.
The Vivado IP integrator feature lets you create complex system designs by instantiating and interconnecting IP from the Vivado IP catalog on a design canvas. You can create
designs interactively through the IP integrator canvas GUI or programmatically through a Tcl programming interface. Designs are typically constructed at the interface level (for
enhanced productivity) but may also be manipulated at the port level (for precision design manipulation).
An interface is a grouping of signals that share a common function. An AXI4-Lite master, for example, contains a large number of individual signals plus multiple buses, which are all
required to make a connection. If each signal or bus is visible individually on an IP symbol, the symbol will be visually very complex. By grouping these signals and buses into an
interface, the following advantages can be realized. First, a single connection in IP integrator (or Tcl command) creates a master to slave connection. Next, the graphical
representation of this connection is a simple, single connection. Finally, Design Rule Checks (DRCs) that are aware of the specific interface can be run to assure that all the required
signals are connected properly. A key strength of IP integrator is that it provides a Tcl extension mechanism for its automation services so that system design tasks such as parameter propagation, can be optimized per-IP or application domain. Additionally, IP integrator implements dynamic, runtime DRCs to ensure, for example, that connections between the IP in an IP integrator design are compatible and that the IP themselves are properly configured.
Designing for Zynq-7000 AP SoC devices is different using the Vivado IDE than in the ISE® Design Suite and Embedded Development Kit (EDK).
The Vivado IDE uses the IP integrator tool for embedded development. The IP integrator is a GUI-based interface that lets you stitch together complex IP subsystems.
A variety of IP are available in the Vivado IDE IP Catalog to accommodate complex designs.
You can also add custom IP to the IP Catalog. See the Vivado Design Suite User Guide:
Designing IP Subsystems Using IP Integrator (UG994) [Ref 2] for more information.
Vivado
ICTP

13. Creating a Project
While entire designs can be created using IP integrator, the typical design will consist of HDL, IP, and IP integrator block designs. This section is an introduction to creating a new IP
integrator-based design. As shown in the figure below, you start by clicking on Create New Project in the Vivado® IDE graphical user interface (GUI) to create a new project. The Vivado Design Suite supports many different types of design projects. Refer to this link in the Vivado Design Suite User Guide: System-Level Design Entry (UG895) [Ref 3] for more information
To add or create a block design in a project, you must create an RTL project, or open an Example Project as shown in Figure 2-2. You can add VHDL or Verilog design files, IP from
the Vivado IP catalog, and other types of design source files to the project using the NewProject wizard.
RTL Project:
The RTL Project environment enables analysis of the compiled RTL design including logic exploration, resource and power estimation, DRCs, and I/O pin planning.
Post-synthesis Project:
This is where pre-implementation design analysis, debug core insertion, and constraint definition is performed. You can explore various constraints sets, devices, and implementation options.
Import ISE tool results:
The Implemented Design environment loads the netlist and implementation results directly from the run directory to ensure that the viewed data represents the launched run.
Vivado
ICTP

14. Creating a Project
After adding design sources, existing IP, and design constraints, you can also select the default Xilinx device or platform board to target for the project, as shown in Figure 2-3,
page 8. For more information, see Chapter 10, Using the Platform Board Flow in IP Integrator.
IMPORTANT: The Vivado tools support multiple versions of Xilinx target boards, so carefully select your target hardware.
Vivado
ICTP

15. Menu Bar Main Toolbar Workspace Status Bar Data Window Flow Navigator
Results Window Area
Vivado
ICTP

16. Main Components of the Project Navigator
Menu Bar: Vivado IDE commands
Main Toolbar: Access to the most commonly used Vivado IDE commands
Workspace: area for schematic panel, device panel, package panel, text editor panel.
Project Status Bar: displays the status of the currently active design
Flow Navigator: provide easy access to the tools and commands necessary to guide the design from start to finish.
Data Window Pane: by default displays information that relates to design data and sources, such as Property Window, Netlist Window, and Source Window
Status Bar: displays information about menu bar and toolbar commands; task progresses
Results Window Area: there are a set of windows, such as Messages, showing message for each process, Tcl Console, Tcl commands of each activity, Reports, reports generated throughout the design flow, Desing Runs, display the different run for the current project
Vivado
ICTP

17. Create a Block design Creating a Block Design
You can create a block design inside the current project directory, or outside of the project directory structure. A common use case for creating the block design outside of a project is
to use the block design in non-project mode, or to use it in multiple projects, or to use it in a team-based design flow.
You create a new block design in the Flow Navigator by clicking the Create Block Design under the IP Integrator heading, as shown in the following figure.
Select Flow Navigator >IP Integrator > Create Block Design.
In the Create Block Design dialog box, specify the Design name and the Directory.
The default value for the Directory field is <Local to Project>. You can override this default value by clicking the Directory field and selecting Choose Location.
3. Choose the location in which to create the block design, and click OK.
The entire block design directory is created local to the current project, or at the specified location with its own directory structure.
Vivado
ICTP

18. Adding IP Modules to the Design Canvas
You can add IP modules to a diagram in the following ways:
1. Right-click in the diagram and select Add IP. A searchable IP Catalog opens.
2. By typing in the first few letters of the IP name in the Search filter at the top of the catalog, only IP modules matching the search string are displayed.
3. To add a single IP, you can either click on the IP name and press the Enter key on your keyboard, or double click on the IP name.
4. To add multiple IP to the Block Design, you can highlight the additional desired IP (Ctrl+Click) and press the Enter key.
5. You can also add IP to the block diagram by opening the IP Catalog from the Flow Navigator.
To add multiple IP to the Block Design, you can highlight the additional desired IP (Ctrl+Click) and press the Enter key.
Vivado
ICTP

19. Adding More IPs
Vivado
ICTP

20. Customizing the PS
3. Double-click the processing system graphic to invoke the Re-customize IP process, which displays the Re-customize IP for the ZYNQ7 Processing System dialog box as
shown in Figure 2-6.
Vivado
ICTP

21. PS Customization Options
Review the contents of the block design. The green colored blocks in the ZYNQ7 Processing System are configurable items. You can click a green block to open the
coordinating configuration options.
Vivado
ICTP

22. PS-PL Configuration Options
AXI_GP Interfaces
AXI_GP features include:
• Standard AXI protocol
• Data bus width: 32
• Master port ID width: 12
• Master port issuing capability: 8 reads, 8 writes
• Slave port ID width: 6
• Slave port acceptance capability: 8 reads, 8 writes
These interfaces are connected directly to the ports of the master interconnect and the slave interconnect without additional FIFO buffering, unlike the AXI_HP interfaces, which
have elaborate FIFO buffering to increase performance and throughput. Therefore, the performance is constrained by the ports of the master interconnect and the slave
interconnect. These interfaces are for general-purpose use only; they are not intended to achieve high performance.
Vivado
ICTP

23. MIO and EMIO Configuration
From the Page Navigator, you can view and configure I/O pins by either clicking on the Peripheral I/O Pins option or MIO Configuration option.
The Zynq-7000 PS has over 20 peripherals available. You can route these peripherals directly to the dedicated Multiplexed I/Os (MIO) on the device, or through the Extended Multiplexed I/Os (EMIOs) routing to the fabric.
The configuration interface also lets you select I/O standards and slew settings for the MIO.
The I/O peripheral block appears with a checkmark when you enable a peripheral. The block design depicts the status of enabled and disabled peripherals.
Vivado
ICTP

24. MIO I/O Pins Configuration
Bank Settings
After you select peripherals, the individual I/O signals for the peripheral appear in the respective MIO locations. Use this section primarily for selecting I/O standards for the various peripherals. The PS MIO I/O buffers split into two voltage domains. Within each domain, each MIO is independently programmable.
There are two I/O voltage banks:
• Bank 0 consists of pins 0:15.
• Bank 1 consists of pins 16:53.
Each MIO pin is individually programmed for voltage signaling:
• 1.8 and 2.5/3.3 volts
• CMOS single-ended or HSTL differential receiver mode
IMPORTANT: The entire bank must have the same voltage, but the pins
Vivado
ICTP

25. Running Block Automation
Using the Designer Assistance Feature
IP integrator offers a feature called Designer Assistance, which includes Block Automation and Connection Automation, to assist you in putting together a basic microprocessor system by making internal connections between different blocks and making connections to external interfaces. The Block Automation Feature is provided when an embedded processor such as the Zynq® Processing System 7 or MicroBlaze™ processor, or some other hierarchical IP such as an Ethernet is instantiated in the IP integrator block design.
Click the Run Block Automation link in the banner of the design canvas, as shown in the following figure, for assistance in putting together a simple MicroBlaze system.
The Run Block Automation dialog box opens, as shown in Figure 2-35, page 31, and lets you provide input about basic features that the microprocessor system needs. (UG994)
After you specify the necessary options, the Block Automation feature automatically creates a basic system as shown in the following figure.
Vivado
ICTP

26. Run Block Automation – Customized PS
Vivado
ICTP

27. Connecting IPs – Making Connections With the Tool
Connection Automation
Because the design is not connected to any external I/O at this point, IP integrator offers the Connection Automation feature as shown in the light green banner of the design canvas in the preceding figure. When you click Run Connection Automation, IP integrator provides assistance in hooking interfaces and/or ports to external I/O ports.
The Run Connection Automation dialog box, as shown in the following figure, lists ports and interfaces that the Connection Automation feature supports, along with a brief description of the available automation, and available options for each automation.
For Xilinx Target Reference Platforms or evaluation boards, IP integrator has knowledge of the FPGA pins that are used on the target boards. Based on that information, the IP integrator connection automation feature can assist you in tying the ports in the design to xternal ports on the board. IP integrator then creates the appropriate physical constraintsand other I/O constraints required for the I/O port in question. (UG994)
Clicking Run Connection Automation does the following:
• Instantiates an AXI Interconnect, a Block Memory Generator, and a Proc Sys Reset IP
• Connects the AXI BRAM Controller to the ZYNQ7 PS IP using the AXI Interconnect
• Appropriately connects the Proc Sys Reset IP as shown in Figure 2-38 (UG898)
Vivado
ICTP

28. Connecting IPs – Making Connections With the Tool
Vivado
ICTP

29. Connecting IPs – Making Connections Manually
When you create a design in IP integrator, you add blocks to the diagram, configure the blocks as needed, make interface-level or simple-net connections, and add interface or simple ports. Making connections in IP integrator is simple. As you move the cursor near an interface or pin connector on an IP block, the cursor changes into a pencil. You can then click on an interface or pin connector on an IP block, hold down the left-mouse button, and then draw the connection to the destination block.
A signal or bus-level connection is shown as a narrow connection line on a symbol. Buses are treated identically to individual signals for connection purposes. An interface-level connection is indicated by a more prominent connection box on a symbol, as shown on the SLMB interface pin in the following figure.
Manual Connections in a Design
Figure 2-39 shows how you can connect the ILA SLOT_0_AXI or the clk pin to the clock and the AXI interface that needs to be monitored in the design. You can do this manually.
As you move the cursor near an interface or pin connector on an IP block, the cursor
changes to a pencil. Click an interface or pin connector on an IP block, and drag the
connection to the destination block. (UG898)
Vivado
ICTP

30. Adding GPIO IP Block
Vivado
ICTP

31. Run Connection Automation for GPIO IP
For example, assume that you instantiate the AXI_GPIO IP into the design. The Run Connection Automation link reappears in the banner on top of the design canvas. You can then click Run Connection Automation and the S_AXI port of the newly added AI GPIO can be connected to the MicroBlaze processor using the AXI Interconnect. Likewise the GPIO interface can be tied to one of the several interfaces present on the target board.
The connection option are: GPIO interface port can be connected to either the Dip Switches that are 4-bits, or to the LCD that are 7-bits, LEDs that are 8-bits, 5-bits of Push Buttons, the Rotary Switch on the board, or can be connected to a Custom interface.
Selecting any one of the choices connects the GPIO port to the existing connections on the board.
Selecting the S_AXI interface for automation, as shown in the following figure, informs you that the slave AXI port of the GPIO can be connected to the MicroBlaze master. If there are multiple masters in the design, then you have a choice to select between different masters. You can also specify the clock connection for the slave interface such as S_AXI interface of the GPIO.
Vivado
ICTP

32. GPIO IP Connected
Vivado
ICTP

33. Options for External Connections
You can connect signals and interfaces to external I/O ports as follows:
• Make External
• Create Port
• Create Interface Port
These options are described in the following sections.
Making Ports External
1. To connect signals or interfaces to external ports on a diagram, first select a pin, bus, or interface connection, as shown in the following figure.
2. Right-click and select Make External. You can also use Ctrl+Click to select multiple pins and invoke the Make External
command for all pins at one time.
This command ties a pin on an IP to an I/O port on the block design. IP integrator connects the port on the IP to an external I/O.
Creating Ports
1. To use the create port option, right-click and select Create Port, as shown in the following figure. This feature is used for connecting individual signals, such as a clock, reset, and uart_txd.
Create Port gives you more control in specifying the input and output, the bit-width and the type (such as clk, reset, and data).
When you specify a clock, you can also specify the input frequency.
Specify the port name, the direction such as input, output or bidirectional, and the type (such as clock, reset, interrupt, data, clock enable or custom type).
You can also create a bit-vector by checking the Create Vector field and then selecting the appropriate bit-width.
Manually Creating and Connecting to I/O Ports
You can manually create external I/O ports in the Vivado IP integrator. You can connect signals or interfaces to external I/O ports by selecting a pin, a bus, or an interfaceconnection.
Make External. You can use the Ctrl+Click keyboard combination to select multiple pins and invoke the Make External connection. This command ties a pin on an IP to an I/O port on the block design.
• Create Port. Use this command for non-interface signals, such as a clock, reset, or uart_txd.
The Create Port option gives more control in terms of specifying the input/output, the bit-width and the type (clk, reset, or data). In case of a clock, you can even specify the input frequency.
• Create Interface Port. This command creates ports on the interface for groupings of signals that share a common function.
For example, the S_AXI is an interface port on several Xilinx IP. The command gives more control in terms of specifying the interface type and the mode (master or slave). (UG898)
Vivado
ICTP

34. DRC (Desing Rule Check) Design Validation
IP integrator runs basic design rule checks in real time as the design is being assembled.
However, there is a potential for something to go wrong during design creation. As an
example, the frequency on a clock pin may not be set right. As shown in the following
figure, you can run a comprehensive design check on the design by clicking Validate
Design.
You can also click the Validate Design button in the toolbar on the IP integrator canvas.
If the design is free of Warnings and/or Errors, a confirmation dialog box displays, as shown
in the following figure.
Running Design Rule Checks
The Vivado IP integrator runs basic DRCs in real time as you put the design together.
However, errors can occur during design creation. For example, the frequency on a clock pin
might not be set correctly.
To run a comprehensive DRC, click the Validate Design toolbar button .
If no warnings or errors occur in the design, a validation dialog box displays to confirm that
there are no errors or critical warnings in your design, (UG898)
Vivado
ICTP

35. DRC – Design Validation
Vivado
ICTP

36. DRC
Vivado
ICTP

37. Address Map Memory-Map Address Space Introduction
Master interfaces reference an assigned memory range container called address spaces, or
bd_address_space objects. Slave interfaces reference a requested memory range
container, called a memory map.
By convention:
• Memory-maps are named after the slave interface pins that reference them, for
example the S_AXI interface references the S_AXI memory-map, though that is not
required.
• Address space names are related to its usage; for example, the MicroBlaze™ processor
has a Data address space and an Instruction address space.
The memory-map for each slave interface pin contains slave segments, or
bd_address_seg objects. These address segments correspond to the address decode
window for that slave.
A typical AXI4-Lite slave has only one address segment, representing a range of memory.
However, some slaves, like a bridge, have multiple address segments, or a range of
addresses for each address decode window.
When a slave segment is mapped to the master address space, a master bd_address_seg
object is created, mapping the address segments of the slave to the master. The Vivado® IP
integrator can automatically assign addresses for all slaves in the design. However, you can
also manually assign the addresses using the Address Editor.
TIP: The Address Editor tab only appears if the diagram contains an IP block that functions as a bus master (such as the MicroBlaze processor) or if an external bus master (outside of IP integrator) is present.
Click the Address Editor tab above the design canvas. In the Address Editor, you can see
the address segments of the slaves, and can map them to address spaces in the masters.
If you generate the RTL from an IP integrator block design without first generating
addresses, the IP integrator prompts you to automatically assign addresses at that point.
You can also set addresses manually by entering values in the Offset Address and Range
columns.
A master such as a processor communicates with peripheral devices through device
registers. Each of the peripheral devices is allocated a block of memory within a master’s
overall memory space. IP Integrator follows the industry standard IP-XACT data format for
capturing memory requirements and capabilities of endpoint masters and slaves.
IP integrator provides an Address Editor to allocate these memory ranges to the
master/slave interfaces of different peripherals. Master and slave interfaces each reference
specific memory objects.
The columns of the Address Editor are as follows:
• Cell: Describes the master and the connected peripherals that can be addressed by that
master.
You can expand the tree by clicking the Expand All button, or by clicking the + sign
to expand the selection.
Slave Interface: Lists the name of the slave interface pin of the peripheral instance.
Base Name: Specifies the name of the slave segment.
By convention, the two names that IP integrator creates “on-the-fly” are Mem (memory)
and Reg (register), as shown in Figure 3-5, which shows a design with multiple memory
instantiations.
Offset Address: Describes the offset from the start of the address block.
As an example the addressable range for data and instruction address spaces are 4G
each in Figure 3-5. The address space starts at 0x and ends at 0xFFFFFFFF.
Within this address space the axi_uartlite_0 can be addressed to a range starting
at offset 0x , axi_gpio_0 can be addressed starting at offset 0x
and so forth. This field is automatically populated as the slaves are mapped in the
address space of the master. However, they can also be changed by the user.
The Offset Address and the Range fields are interdependent. The Offset Address field
must be aligned with the Range field. Alignment implies that for a range of 2N the least
significant bits of the starting offset must have at least N 0’s. As an example, if the range
of a slave segment happens to be 64K or 216, the Offset Address must be in the form
0xXXXX0000. This means the lowest 16-bits need to be 0’s. If this field is not set
correctly, the error message, shown in Figure 3-6 displays.
• High Address: Adjusts itself based on the Offset Address and the Range value. This is
the last addressable address in a particular assigned segment.
Memory Mapping in Address Editor
While memory mapping of the peripherals (slaves) instantiated in the block design are
automatically assigned, users can also manually assign the addresses. To generate the
address map for this design:
1. Click the Address Editor tab above the diagram.
2. Click the Auto Assign Address button (bottom on the left side).
You can manually set addresses by entering values in Offset Address and Range columns.
Refer to this link in the Vivado Design Suite User Guide: Designing IP Subsystems Using IP (UG898)
Vivado
ICTP

38. Generating Output Products
To generate output products, do one of the following:
• In the Block Design panel, expand the Design Sources hierarchy and select Generate
Output Products.
• In the Flow Navigator panel, under IP Integrator, click Generate Block Design.
The Vivado Design Suite generates the HDL source files and the appropriate constraints for
all the IP used in the block design. The source files are generated based upon the Target
Language that you selected during project creation, or in the Project Settings dialog box.
Refer to the Vivado Design Suite User Guide: Designing IP Subsystems Using IP Integrator
(UG994) [Ref 2], for more information on generating output products. (UG898)
Vivado
ICTP

39. Creating an HDL Wrapper
You can integrate an IP integrator block design into a higher-level design. To do so,
instantiate the design in a higher-level HDL file.
To instantiate at a higher level, in the Design Sources hierarchy of the Block Design panel,
right-click the design and select Create HDL Wrapper.
Vivado offers two choices for creating an HDL wrapper:
• Let Vivado create and automatically update the wrapper, which is the default option
• Create a user-modifiable script, which you can edit and maintain. Choosing this option
requires that you update the wrapper every time you make port-level changes in the
block design.
This generates a top-level HDL file for the IP integrator subsystem. You can now take your
design through the other design flows: elaboration, synthesis, and implementation.
Vivado
ICTP

40. Vivado Design Suite Elaboration Process
ICTP

41. Embedded System Design – Vivado Flow
Create Project
(Block Design)
Spec
IPs
Synthesis
Constraints
HDL
Implementation
Elaborate
Timing Verification
Behavioral Verification
Bitstream Generation
Vivado
ICTP

42. Elaboration Elaboration is the RTL optimization to an FPGA technology
Vivado IDE allows designers to import and manage RTL sources
Verilog, System Verilog, VHDL, NGC, or testbenches
Create and modify sources with the RTL Editor
Cross-selection between all the views
Sources view
Hierarchy view: Display the modules in the design by hierarchy
Libraries view: Display sources by category
Vivado
ICTP

43. Elaborated Design
Accessed through the Flow Navigator by selecting Open Elaborated Design
Representation of the design before synthesis
Interconnected netlist of hierarchical and generic technology cells
Instances of modules/entities
Generic technology representations of hardware components
AND, OR, buffer, multiplexers, adders, comparators, etc…
Vivado
ICTP

44. Object Names in Elaborated Design
Object names are extracted from RTL
Instance and pin names of hierarchical objects
Inferred flip-flops from underlying reg/signal/logic
Suffix _reg is added
Nets from underlying reg/signal/logic when it makes sense
Vivado
ICTP

45. Elaboration and Analysis
In a RTL based design, elaboration is the first step
Click on the Open Elaborated Design under RTL Analysis to
Compile the RTL source files and load the RTL netlist for interactive analysis
You can check RTL structure, syntax, and logic definitions
Analysis and reporting capabilities include:
RTL compilation validation and syntax checking
Netlist and schematic exploration
Design rule checks
Early I/O pin planning using an RTL port list
Ability to select an object in one view and cross probe to the object in other views, including instantiations and logic definitions within the RTL source files
Vivado
ICTP

46. Schematic View of an Elaborated Design
When Schematic is clicked under the Elaborated Design, the schematic is opened showing the hierarchical blocks
Note that no IO buffers are inferred at this stage
Vivado
ICTP

47. Cross Probing
Select an object in the schematic, right-click, and select Go To Source to view where the object is defined in the source file
Vivado
ICTP

48. Vivado Design Suite Synthesis Process
ICTP

49. Embedded System Design – Vivado Flow
Create Project
(Block Design)
Optional
Spec
IPs
Synthesis
Constraints
Constraints
HDL
Implementation
Elaborate
Timing Verification
Behavioral Verification
Bitstream Generation
Vivado
ICTP

50. Vivado IDE Synthesis Applicable only for RTL (HDL) design flows
EDIF is black boxed and linked after synthesis
Synthesis tool uses XDC constraints to drive synthesis optimization
Design must first be synthesized without timing constraints for constraints editor usage
XDC file must exist
Synthesis settings provide access to additional options
Vivado
ICTP

51. Logic Optimization and Mapping to Device Primitives
Synthesis of an RTL design not only optimizes the gate-level design but also maps the netlist to Xilinx primitives (sometimes called technology mapping)
Getting behavioral logic to map to specific primitives may require specific HDL coding techniques or synthesis-specific primitives. Hopefully generic inference is sufficient, but it will depend on the architecture resource and the synthesis tool
Vivado
ICTP

52. Synthesized Design
Accessed through the Flow Navigator by selecting Open Synthesized Design
Representation of the design after synthesis
Interconnected netlist of hierarchical and basic elements (BELs)
Instances of modules/entities
Basic elements
LUTs, flip-flops, carry chain elements, wide MUXes
Block RAMs, DSP cells
Clocking elements (BUFG, BUFR, MMCM, …)
I/O elements (IBUF, OBUF, I/O flip-flops)
Object names are the same as names in the elaborated netlist when possible
Vivado
ICTP

53. Commands Available After Synthesis
Flow Navigator is optimized to provide quick access to the options most frequently used after synthesis
Report Timing Summary: Generate a default timing report
Report Clock Networks: Generates a clock tree for the design
Report Clock Interaction: Verifies constraint coverage on paths between clock domains
Report DRC: Performs design rule check on the entire design
Report Noise: Performs an SSO analysis of output and bidirectional pins in the design
Report Utilization: Generates a graphical version of the Utilization Report
Report Power: Detailed power analysis reports that can be customized for the power supply and application environment
Schematic: Opens the Schematic viewer
Vivado
ICTP

54. Synthesis Reports
While the Flow Navigator points to the most important reports, the Reports tab contains several other useful reports
Vivado Synthesis Report shows
HDL files synthesized, synthesis progress, timing constraints read, and RTL primitives from the RTL design
Timing optimization goals, technology mapping, removed pins/ports, and final cell usage (technology-mapped cell usage)
Utilization Report shows
Technology-mapped cell usage in an easy-to-read tabular format
Vivado
ICTP

55. Synthesis Utilization Report
Reports slice logic, memory, DSP slice, IO, clocking, and other resources used by the design
Vivado
ICTP

56. Vivado Design Suite Implementacion Process
ICTP

57. Embedded System Design – Vivado Flow
Create Project
(Block Design)
Spec
IPs
Synthesis
Constraints
Optional
HDL
Implementation
Constraints
Elaborate
Timing Verification
Behavioral Verification
Bitstream Generation
Vivado
ICTP

58. Vivado Implementation Sub-Processes
Vivado Design Suite Implementation process transform a logical netlist (generated by the synthesis tool) into a placed and routed design ready for bitstream generation
Opt design
Optimizes the logical design to make it easier to fit onto the target FPGA
Place design
Places the design onto the FPGA’s logic cells
Route design
Routing of connections between the FPGA’s cells
Vivado
ICTP

59. Using Design Constraints for Guiding Implementation
There are two types of design constraints, physical constraints and timing constraints.
Physical Constraints: define a relationship between logic design objects and device resources
Package pin placement
Absolute or relative placement of cells:
Block RAM
DSP
LUTs
Filp-Flops
Floorplanning constraints that assign cells to general regions of an FPGA
Timing Constraints: define the frequency requirements for the design. Without timing constraints, Vivado Design Suite optimizes the design solely for wire length and routing congestion and makes no effort to asses or improve design performance
Vivado
ICTP

60. Implementation Log Messages
Viewing the Log in the Log Window
The Log window opens in the Vivado IDE after you launch a run. It shows the standard output messages. It also displays details about the progress of each individual implementation process, such as place_design and route_design.
Viewing the Log in the Log Window
The Log window opens in the Vivado IDE after you launch a run. It shows the standard
output messages. It also displays details about the progress of each individual
implementation process, such as place_design and route_design.
The Log window, shown Figure 3-4, can help you understand where different messages
originate to aid in debugging the implementation run.
Pausing Output
Click Pause to pause the output to the Log window. Pausing allows you to read the log
while implementation continues running.
Vivado
ICTP

61. After Implementation Sources and Netlist tabs do not change
Now as each resources is selected, it will show the exact placement of the resource on the die
Timing results have to be generated with the Report Timing Summary
As each path is selected, the placement of the logic and its connections is shown in the Device view
This is the cross-probing feature that helps with static timing analysis
Vivado
ICTP

62. After Completing Implementation
Moving Forward After Implementation
After implementation has completed, for both Project Mode and Non-Project Mode, the
direction you take the design next depends on the results of the implementation.
• Is the design fully placed and routed, or are there issues that need to be resolved?
• Have the timing constraints and design requirements been met, or are their additional
changes required to complete the design?
• Are you ready to generate the bitstream for the Xilinx part?
Recommended Steps After Implementation
The recommended steps after implementation are:
1. Review the implementation messages.
2. Review the implementation reports to validate key aspects of the design:
° Timing constraints are met (report_timing_summary).
° Utilization is as expected (report_utilization).
° Power is as expected (report_power).
3. Write the bitstream file.
Writing the bitstream file includes a final DRC to ensure that the design does not violate
any hardware rules.
4. If any design requirements have not been met:
a. In Project Mode, open the implemented design for further analysis.
b. In Non-Project Mode, open a post-implementation design checkpoint.
In the Implementation Completed dialog box:
1. Select the appropriate option:
° Open Implemented Design
Imports the netlist, design constraints, the target part, and the results from place
and route into the Vivado IDE for design analysis and further work as needed.
° Generate Bitstream
Launches the Generate Bitstream dialog box. For more information, see this link in
the Vivado Design Suite User Guide: Programming and Debugging (UG908) [Ref 12].
° View Reports
Opens the Reports window for you to select and view the various reports produced
by the Vivado tools during implementation. For more information, see Viewing
Implementation Reports, page 104.
Vivado
ICTP

63. Implementation Out-of-Date Message
Viewing Out-of-Date Status
If source files or design constraints change, and either synthesis or implementation was
previously completed, the project might be marked as Out-of-Date, as shown in Figure 3-5.
The project status bar shows an Out-of-Date status. Click more info to display which
aspects of the design are out of date. It might be necessary to rerun implementation, or
both synthesis and implementation.
Forcing Runs Up-to-Date
Click Force-up-to-date to force the implementation or synthesis runs up to date. Use
Force-up-to-date if you changed the design or constraints, but still want to analyze the
results of the current run.
TIP: The Force-up-to-date command is also available from the popup menu of the Design Runs window
when an out-of-date run is selected.
Vivado
ICTP

64. Exporting a Hardware Description
Once a design has been implemented and the bitstream generated, you can export the
design to SDK for software application development. In rare cases where the Processing
Logic does not contain any logic at all, you can also export the design without
implementing or generating the bitstream.
To export your design to SDK, do the following:
1. In the main Vivado IDE, select File > Export > Export Hardware.
The Export Hardware for SDK dialog box opens (Figure 2-47).
In the Export Hardware for SDK dialog box, check the Include bitstream check box.
3. After the hardware definition has been exported, select File > Launch SDK to launch
SDK from Vivado
The Launch SDK dialog box opens.
The Exported location and Workspace fields are typically set to <Local to Project> in
a project based flow. However, if the user specified a different location for exporting the
hardware definition, set the Exported location field to that particular location.
Likewise, the Workspace location can be set to a the appropriate directory location if
desired.
After you export the hardware definition to SDK, and launch SDK, you can start writing your
software application in SDK.
You can do further debug and downloading of the software from SDK.
Alternatively, you can import the ELF file for the software back into the Vivado tools, and
integrate it with the FPGA bitstream for further download and testing. (UG898)
Vivado
ICTP

65. Export Hardware Design to SDK
Software development is performed with the Xilinx Software Development Kit tool (SDK)
The design must be opened if a bitstream of the design is generated
The Block design must be open before the design can be exported
An XML description of the hardware is imported in the SDK tool
The hardware platform is built on this description
Only one hardware platform for an SDK project
The SDK tool will then associate user software projects to hardware
Vivado
ICTP

66. Exporting IP Integrator Design to SDK – Main Files
Description
system.xml
This file opens by default when you launch SDK and displays the address map of your system
ps7_init.c
s7_init.h
The ps7_init.c and ps7_init.h files contain the initialization code for the Zynq Processing System and initialization settings for DDR, clocks, PLLs and MIOs. SDK uses these settings when initializing the PS so applications can run on top of the PS.
ps7_init.tcl
This is the Tcl version of the init file
ps7_init.html
This init file describes the initialization data.
When you export a Zynq-7000 processor hardware design from the IP integrator tool to
SDK, the IP integrator generates the following files:
See the Zynq-7000 All Programmable SoC Software Developers Guide (UG821) [Ref 1] for
more information about generated files. UG898
Vivado
ICTP

67. Vivado Design Suite Basic Static Timing Constraints
ICTP

68. Basic Timing Constraints
There are three basic timing constraints applicable to a sequential machine
Period
Paths between synchronous elements clocked by the reference clock net
Synchronous elements include flip-flops, latches, synchronous RAM, and DSP slices
Use create_clock to create the constraint
Input Delay
Paths between input pin and synchronous elements
Use set_input_delay to create the constraint
Output delay
Paths between synchronous elements and output pin
Use set_output_delay to create the constraint
Vivado
ICTP

69. Timing Paths Example
Vivado
ICTP

70. Creating Basic Timing Constraints in Vivado IDE
Run Synthesis
Open the synthesized design
Invoke constraints editor
Vivado
ICTP

71. Clock Constraint Setting
Vivado
ICTP

72. Clock Constraint Setting
Vivado
ICTP

73. Clock Network Report
Vivado
ICTP

74. Clock Network Report and Visualization
Vivado
ICTP

75. Vivado Design Suite Generate Bit Stream Process Configuring FPGA Process
ICTP

76. Steps to Configure only the PL
Blue “Done” LED
Vivado
ICTP

77. Software Development Kit (SDK)
Vivado
ICTP

78. Embedded System Design – Vivado-SDK Flow
Create Project
(Block Design)
Spec
IPs
Synthesis
Constraints
HDL
Implementation
Elaborate
Timing Verification
Behavioral Verification
Hardware Export
Vivado
ICTP

79. Embedded System Design – Vivado-SDK Flow
ICTP

80. Embedded System Tools: Software
Eclipse IDE-based Software Development Kit (SDK)
Board support package creation : LibGen
GNU software development tools
C/C++ compiler for the ARM Cortex-A9 processor (gcc)
Debugger for the ARM Cortex-A9 processor (gdb)
Board support packages (BSPs)
Stand-alone BSP
Free basic device drivers and utilities from Xilinx
NOT an RTOS
Vivado
ICTP

81. SDK Workbench Views 1
C/C++ project outline displays the elements of a project with file decorators (icons) for easy identification C/C++ editor for integrated software creation Code outline displays elements of the software file under development with file decorators (icons) for easy identification Problems, Console, Properties views list output information associated with the software development flow 2 3
Software Development Kit
The Xilinx Software Development Kit (SDK) provides a complete environment for creating software applications targeted for Xilinx embedded processors. It includes a GNU-based compiler toolchain (GCC compiler, GDB debugger, utilities, and libraries), JTAG debugger, flash programmer, drivers for Xilinx IPs and bare-metal board support packages, middleware libraries for application-specific functions, and an IDE for C/C++ bare-metal and Linux application development and debugging. Based upon the open source Eclipse platform, SDK incorporates the C/C++ Development Toolkit (CDT). Features include:
•C/C++ code editor and compilation environment
•Project management
•Application build configuration and automatic makefile generation
•Error navigation
•Integrated environment for debugging and profiling embedded targets
•Additional functionality available using third-party plug-ins, including source code version control
SDK Availability
SDK is available as a download with the Vivado Design Suite, and as a standalone application. SDK also includes an application template for creating a First Stage Bootloader (FSBL), as well as a graphical interface for building a boot image.
SDK contains a complete help system that describes concepts, tasks, and reference information. See the Xilinx Software Development Kit Help (UG782) [Ref 14], for more information. 4
Vivado
ICTP

82. Build Software Application in SDK
Create software platform
System software, board support package
LibGen program
Create software application
Optionally, create linker script
Build project
Compile, assemble, link output file <app_project>.elf
Vivado
ICTP

83. Software Management Settings
Software is managed in three major areas
Compiler/Linker Options
Application program
Software Platform Settings
Board support package
Linker Script Generation
Assigning software to memory resources
Vivado
ICTP

84. Integrated Xilinx Tools in the SDK
Xilinx additions to the Eclipse IDE
BSP Settings
Software Repositories
Generate Linker Script
Program the programmable logic
Bitstream must be available
Create Zynq Boot Image
Program Flash Memory
Launch XMD Console
Launch Shell
Configure JTAG Settings
SysGen Co-Debug Settings
Vivado
ICTP

85. Apendix
Vivado
ICTP

86. Clocking Resources: MMCM and PLL
Up to 24 CMTs per device
One MMCM and one PLL per CMT
Two software primitives (instantiation)
*_BASE has only the basic ports
*_ADV provides access to all ports
PLL is primarily intended for use with the I/O phaser for high-speed memory controllers
The MMCM is the primary clock resource for user clocks
Vivado
ICTP

87. Inference Clock networks are represented by nets in your RTL design
The mapping of an RTL net to a clock network is managed by using the appropriate clock buffer to generate that net
Certain resources can be inferred
A primary input net (with or without an IBUF instantiated) will be mapped to a global clock if it drives the clock inputs of clocked resources
The BUFG will be inferred
BUFH drivers will be inferred whenever a global clock (driven by a BUFG) is required in a clock region
BUFHs for each region required will be inferred
BUFIO, BUFR, and BUFMR cannot be inferred
Instantiating these buffers tells the tools that you want to use the corresponding clock networks
PLLs and MMCMs cannot be inferred
Vivado
ICTP

88. Instantiation
All clocking resources can be directly instantiated in your RTL code
Simulation models exist for all resources
Refer to the Library Guide for HDL Designs
Use the Language Templates ( ) tab
PLLs and MMCMs have many inputs and outputs, as well as many attributes
Optimal dividers for obtaining the desired characteristics may be hard to derive
The Clocking Wizard via the IP Catalog
Only *_ADV available
Vivado
ICTP

89. Invoking Clocking Wizard
Click on the IP Catalog
Expand FPGA Features and Design > Clocking
Double-click on Clocking Wizard
The Clocking Wizard walks you through the generation of complete clocking subsystems
Vivado
ICTP

90. The Clocking Wizard: Clocking Options
Select Primitives to be used
MMCME2_ADV
PLLE2_ADV
Specify the primary input frequency and source type
Optionally, select and specify secondary input clock
Select clocking features
Frequency synthesis
Phase alignment
Dynamic phase shift …
Vivado
ICTP

91. The Clocking Wizard: Output Clocks
Select the desired number of output clocks
Set the desired output frequencies
Select optional ports
Vivado
ICTP

92. The Clocking Wizard: Port Renaming
Change input/output port names
Change optional port names
Vivado
ICTP

93. The Clocking Wizard: Summary
Shows the input, output frequencies
Other attributes depending on the selections made
The Resource tab on the left provides summary of type and number of resources used
Vivado
ICTP

94. Reset and Clock Topology
ICTP
Vivado

95. Enabling Clock for PL
RECOMMENDED: For designs with a Zynq-7000 processor that contain custom logic in the PL fabric
(but without MIG IP), it is recommended that the clocking and reset for the PL portion of the design be sourced from the PS. Any one of the PL Fabric Clocks-FCLK_CLK0, FCLK_CLK1, FCLK_CLK2 and
FCLK_CLK3-can be used for the clock source. The associated resets for each of these
clocks-FCLK_RESET0_N, FCLK_RESET1_N, FCLK_RESET2_N,and FCLK_RESET3_N-can be used for
resetting the PL.
Double-click the ZYNQ7 Processing System to re-customize the IP.
In the Re-customize IP dialog box, click Clock Configuration in the Page Navigator and
then expand PL Fabric Clocks.
Vivado
ICTP

96. Vivado
ICTP

97. SDK Compilers
ICTP
Vivado

98. GNU Tools: GCC GCC translates C source code into assembly language
GCC also functions as the user interface, passing options to the GNU assembler and to the GNU linker, calling the assembler and the linker with the appropriate parameters
Supported cross-compilers
ARM processor compiler
GNU GCC (arm-xilinx-eabi-gcc)
GNU Linux GCC (arm-xilinx-linux-eabi-gcc)
Vivado
ICTP

99. GNU Tools: AS Input: assembly language files Output: object code
File extension: .s
Output: object code
File extension: .o
Contains
Assembled piece of code
Constant data
External references
Debugging information
Typically, the compiler automatically calls the assembler
Use the -Wa switch if the source files are assembly only and use gcc
Vivado
ICTP

100. GNU Tools: Linker (LD) Inputs Outputs Several object files
Archived object files (library)
Linker script (*.ld)
Outputs
Executable image (ELF)
Map file
Vivado
ICTP

101. Timing Reports
ICTP
Vivado

102. Report Timing Summary Tcl command: report_timing_summary Vivado IDE
report_timing_summary -delay_type max -report_unconstrained -check_timing_verbose -max_paths 10 -input_pins -name timing_1
Vivado IDE
Options tab
Maximum number of paths
Advanced tab
Write to a file
Timer Settings
Interconnect delay can be ignored
Flight delays can be disabled
Vivado
ICTP

103. Report Timing Summary Design Timing Summary Clock Summary Check Timing
WNS, TNS, total number of endpoints are of interest
Clock Summary
Primary and derived clocks
Check Timing
Number of unconstrained internal endpoints
Vivado
ICTP