We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Terminology for IP Flow

by Xilinx Employee on ‎10-26-2016 04:54 PM (1,463 Views)

The Xilinx IP based flow uses terminology that is different from the terms used by typical RTL based designers.


As a result, we need to define certain terminology which might be unique to our IP Flow.


This blog article will attempt to demystify the terminology for flows related to IP.


Xilinx’s Vivado Design Suite comes with an IP Catalog. This catalog contains several IP cores, and you can also add your own IP cores to this catalog.


For the purpose of this article, we will assume that there are only Xilinx provided IP cores in the catalog.


Any given “IP” mentioned in the catalog is actually a “generic” version – which can be customized.

For example, if you select a Counter, the Counter can be customized for the following behavior:


  • Data width
  • Whether it is Loadable or not
  • Whether it is UP/DOWN
  • Several other options


The “IP” in the catalog is a generic template. At this stage, this is *not* really an IP that you can use directly.


You now need to customize the Counter for the specific behavior that you need (For example, an 8-bit Up-Counter with parallel load capability).


This customization is stored in a .xci file. The .xci file contains the specific configuration that you have chosen. This represents the actual IP, where the behavior is now known exactly.


Effectively you can have many different variations of the counter IP core, all coming from the same generic template in the IP Catalog. Each of these variations will have its own .xci file.


At the time of customization, you will also need to provide a “component name”. For your design, this is the effective name of the IP that you will use for instantiation.


The XCI file defines the exact configuration and hence the behavior of the specific IP (aka: component).


However, for the specific counter to be realized, we will need a set of HDL files (for synthesis and simulation) and constraints.

This process is called: “Generate Output Products”. These output products are all of the files that are needed for the Vivado tool to simulate, synthesize etc.



It is worth noting that “Customization” and “Generation” can be done using two different versions of Vivado.


“Generation” can even be done in one version, and then the generated files (HDLs, Constraints etc.) can be used in a different version of Vivado.


Let us consider 2 different scenarios.


Scenario 1)


I use Vivado version V1 to customize my counter, and get a .xci file which specifies a fixed width and functionality (UP/DOWN, Loadable, etc.).

I then load this .xci file in a later version of Vivado (V2), and use this later version of Vivado to generate all of the output products.


Scenario 2)


I use Vivado version V1 to customize my counter, and then use this same version to generate all of the output products.


Conceptually, the output products (HDL, Constraints etc.) in the two scenarios should be the same. However in practice they could be different.


This is because in Scenario 1, any bug-fixes/enhancements in the next version of Vivado related to the HDL/Constraints would make it into the generated products.


However, in Scenario 2, the output products were already generated in the previous version of Vivado.


Now, let us assume, you have already verified your design with a specific version of the IP. As you move to the next version of Vivado, the IP might undergo some changes.


However, you do not want to have any uncertainty about potential changes to HDLs and Constraints that you have already verified. In such cases, you would want to stay with the HDLs and Constraints which are already generated and which you have verified.


In other words, you want to move to a newer version of Vivado for the rest of the flow, but you do not want your IP HDLs to change.


This is when you would use Scenario 2.


This concept is also called “Locked IP”. Here, as you change the Vivado version, the HDLs and the Constraints describing the IP are unchanged.


On the other hand, if you decide to generate the HDLs and Constraints using the latest version of Vivado, you are using an “Upgrade IP” flow.


It is possible that in the upgraded version of the IP, some additional pins might have been added, or that some additional degree of customization has been added.


In general, the Vivado “Upgrade” flow will try to enter the values for these additional features in such a way that it retains the functionality of the previous version.


The “Upgrade” will thus let you obtain the newest HDL and constraints, while leaving the IP customization unchanged.


While generating, you can also synthesize the HDLs. This is called “Out-of-Context” synthesis, where the IP component is synthesized stand-alone, without looking at the rest of the design.


The synthesized version of the IP component is stored in a Design CheckPoint (.dcp).


If you decide to generate the IP with OOC (Out-of-Context) synthesis, then even when you move to a newer version of Vivado, the synthesis is still based on the older version which was used during OOC synthesis.


Effectively, you can do a mix-and-match of various versions at each step:


  1. Customize an IP from the catalog for a specific configuration. The customization is stored in an XCI file.
  2. Generate the HDL and constraints corresponding to the specific configuration. The main input is the XCI file, which might have been generated just now, or earlier using a prior version of Vivado.
  3. Synthesize these HDLs (either just the IP, or the whole design with the IP included). If the IP is synthesized by itself, the synthesized view is stored in a DCP file. The Vivado version for synthesis could be the same as or newer than the version used for generation of output products. However, for OOC synthesis, “generation” also includes Synthesis. As a result, in OOC synthesis the Vivado version for synthesis is the same as the version that was used for generating HDLs and constraints.
  4. Now go through the rest of the implementation flow. By this stage, you are in the mainstream flow.

You can decide to do all of the steps in a single version of Vivado, or, you can go with one version of Vivado for as many steps as you want, then start from the subsequent steps with the next version of Vivado.




About the Author
  • Avinash Thakare joined Xilinx in 2009. He graduated in Electronics Engineering in year 2000; and since then have been working in FPGA and EDA domain. Most of his work experience in FPGA based design and development
  • Sanjay is Senior Director, Software Validation, at Xilinx, where he and his team validate the company’s Vivado and SDx tool chains. For more than 20 years, Sanjay has worked in EDA and VLSI in India as well as in Silicon Valley in the United States. He has worked extensively on library characterization and modeling, HDLs (focusing more on Verilog than VHDL), simulation, synthesis, static timing analysis, power, clock domain crossing and synchronization, and rule checker-based verification. Sanjay has been learning Vivado in recent years. He has published three books as co-author and editor: Principles of VLSI RTL Design – A Practical Guide, Constraining Designs for Synthesis and Timing Analysis – Using Synopsys Design Constraints, and Designing with Xilinx FPGAs – Using Vivado. In addition, Sanjay has written numerous articles and papers for trade journals and conferences. He holds three patents related to clock gating and isolation cells. A resident of Hyderabad in India, Sanjay is a graduate of the India Institute of Technology Kharagpur in electronics and electrical communications engineering.