UPGRADE YOUR BROWSER

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,736 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.

 

blogimage.JPG
 

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.

 

Thanks,

Sanjay

Comments
by Visitor talis9
on ‎02-19-2017 01:41 AM

Of many issues, one with Vivado is how to generate HOST independent kernels ( As for the Malibu environment, Vivado appears inextricably bound to a HOST  referred (storage)  IP file system .. Here a scenario on MATLAB which appears similarly bound :

 

of course simulation must begin on the HOST, via a file based IP kernel timing to build up the algorithm.

what is missing AFTER the fabric is complete is a code trimming phase of retiming with FPGA in the loop.

MATLAB is a HOSTED toolset , i am wondering if logic can be fully customized using VHDL & MATLAB using the FrameWork Logic toolset. Normally, MATLAB is a HOST file based or HOST i/O “engine”
where “engine” is the software environment and computation libraries that MATLAB provides.

As they are HOST oriented resource consuming memory structures ( malloc ) & must interoperate with OS kernel supervision , shared with the PC it becomes impossible to isolate FPGA design from these HOST ops. &  IP Kernel files

This hardly explains dependency : BSP is written by the board vendor, so has nothing to do with MATLAB (unless it conforms to a MATLAB SDK standard for i/O)  DMA engine / FILE handles / etc

MATLAB BSP supports real-time hardware-in-the loop development using the graphical, block diagram Simulink environment with Xilinx System Generator.

Theres no reference to the overheads involved or dependencies created by either FrameWork or Xilinx SG

Why are these issues sidestepped .. is it the “abstraction training” that draws blanks or other reluctance?

IP Catalog is understandably file based, as synthesis prod stored in a DCP  FILE.  , then versions of each stored as XCI file.

 

IF u want to describe IP FLOW then DEFINE  each  name u use .. FULLY ,  Where is a link to complete comprehension ?

 

This is  a mess of an explanation.  IN my mind the synthesis is the actual FPGA fabric component.  SO are we talking about these files as  SIMULATION FILES ( which are run on the HOST )  or a file to be targeted to FPGA ?

 

When referring to DCP file  or  XCI  file   a hyperlink explaining  what relationship to FPGA fabric  they  have, is helpful.

 

The worst thing about documentation is abstraction that the young guns believe is the end or be all ..

by Visitor talis9
on ‎02-19-2017 01:47 AM

Of many issues, one with Vivado is how to generate HOST independent kernels ( As for the Malibu environment, Vivado appears inextricably bound to a HOST  referred (storage)  IP file system .. Here a scenario on MATLAB which appears similarly bound :

 

of course simulation must begin on the HOST, via a file based IP kernel timing to build up the algorithm.

what is missing AFTER the fabric is complete is a code trimming phase of retiming with FPGA in the loop.

MATLAB is a HOSTED toolset , i am wondering if logic can be fully customized using VHDL & MATLAB using the FrameWork Logic toolset. Normally, MATLAB is a HOST file based or HOST i/O “engine”
where “engine” is the software environment and computation libraries that MATLAB provides.

As they are HOST oriented resource consuming memory structures ( malloc ) & must interoperate with OS kernel supervision , shared with the PC it becomes impossible to isolate FPGA design from these HOST ops. &  IP Kernel files

This hardly explains dependency : BSP is written by the board vendor, so has nothing to do with MATLAB (unless it conforms to a MATLAB SDK standard for i/O)  DMA engine / FILE handles / etc

MATLAB BSP supports real-time hardware-in-the loop development using the graphical, block diagram Simulink environment with Xilinx System Generator.

Theres no reference to the overheads involved or dependencies created by either FrameWork or Xilinx SG

Why are these issues sidestepped .. is it the “abstraction training” that draws blanks or other reluctance?

IP Catalog is understandably file based, as synthesis prod stored in a DCP  FILE.  , then versions of each stored as XCI file.

 

IF u want to describe IP FLOW then DEFINE  each  name u use .. FULLY , Where is a link to complete comprehension ?

 

This is  a mess of an explanation.  IN my mind the synthesis is the actual FPGA fabric component.  SO are we talking about these files as  SIMULATION FILES ( which are run on the HOST )  or a file to be targeted to FPGA ?

 

Hyperlink terms like  DCP   and   XCI  file to a complete relation of that file to FPGA fabric ..  Im not here to play in  Kernel Files unless i know they are being targeted to FPGA fabric , and exacty how the interim FILES are treated , what overhead must accompany each IP that is created ( obviousy that varies , from Fortran95 Float .. to mem allocation )

 

i have posted, yet the page simply returns as original WITHOUT confirmation of post ..  another oversight @@

by Xilinx Employee
on ‎09-05-2017 11:08 PM

Sorry, that you found this explanation to be a mess.

if/when I find a better way to explain this, I would be glad to update this post.

 

I can understand that some of these terms are confusing. And, thats why, I made an attempt to explain.

Looks like, that did not help you much :(

About the Author
  • Balachander Krishnamurthy is a Sr. Product Marketing Manager for SDSoC. His responsibilities include product planning, inbound and outbound marketing for Xilinx’s Vivado SDx Design Software. Bala holds a Master's degree in Electrical Engineering from San Jose State University. He has worked at Sun Microsystems and Altera for several years in multiple roles in verification, RTL design, first silicon and board bring-up and as an ASIC Product Manager. He has more than 17 years’ experience in the GPU, CPU, ASIC and FPGA industries. His current focus is FPGA methodology for synthesis, implementation and timing closure.
  • 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.