cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Scholar
Scholar
4,237 Views
Registered: ‎04-04-2014

[Project 1-841] Critical Warning. using IP DCP files directly as a source strongly not recommended now?

Hi,

 

i have just upgraded from Vivado 2014.2 to 2017.1 and am in the process of migrating my project and all it's associated IP into the new version. 

 

I have all my IP in a separate Managed IP repository where I generate DCP OOC for each IP and import these directly into my main project as a source. I had thought that I had followed the recommended design flow from 2014.2 and this make sense as it massively speeds up my synthesis runs.

 

However now, in 2017.1 it flags this up as a critical warning:

"Project 1-841] The design checkpoint file "XX" was generated for an IP by an out of context synthesis run and should not be directly used in a Vivado flow. It is strongly recommended that the original IP source file (xci) is used."

 

Now, the latest UG896 suggests two possible flows( page 46-47), global synthesis and OOC Flow. I am using OOC flow and here is says :

"RECOMMENDED: Using the OOC flow when generating IP is recommended and is also the default behavior in the Vivado Design Suite. The OOC flow speeds up run time for the complete project, and lets you avoid re-synthesizing IP when doing project runs. "

 

So, it would seem my approach is not only perfectly sensible but also recommended and the default behaviour for Vivado Design Suite. Yet, this generates a critical warning???

 

Come on guys. I really don't want critical warnings for this every time I run a synthesis run. This seems ridiculous. Can we get this changed?

 

Thanks

Tags (1)
7 Replies
Highlighted
Moderator
Moderator
4,221 Views
Registered: ‎09-15-2016

Hi @mistercoffee,

 

Add .dcp or add .xci, which one is better? As the critical warning is suggesting, also in-sync with UG896 page. no. 47 that it is always recommended to reference the IP using the XCI file. While the DCP does contain constraints, it does not provide other output products that an IP could deliver and that could be needed, such as ELF or COE files, and Tcl scripts. 

 

Regards,
Prathik
-----------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helps to resolve your query.
Helpful answer -> Give Kudos
-----------------------------------------------------------------------------------------------

 

 

0 Kudos
Highlighted
Scholar
Scholar
4,212 Views
Registered: ‎04-04-2014


@prathikm wrote:

Hi @mistercoffee,

 

Add .dcp or add .xci, which one is better? As the critical warning is suggesting, also in-sync with UG896 page. no. 47 that it is always recommended to reference the IP using the XCI file. While the DCP does contain constraints, it does not provide other output products that an IP could deliver and that could be needed, such as ELF or COE files, and Tcl scripts. 

 

Regards,
Prathik
-----------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helps to resolve your query.
Helpful answer -> Give Kudos
-----------------------------------------------------------------------------------------------

 

 


Yes, I see that. But is a critical warning really necessary for following one of two recommended design flows, even if out of the two it is not the preferred option, especially as the preferred option didn't used to be an option in earlier versions of the tool. I'm not going to change my whole IP design flow for this, there aren't any files missing from my DCPs that will affect my design, but now I have to contend with a list of critical warnings every time I do a build. It's just silly.

0 Kudos
Highlighted
Moderator
Moderator
3,999 Views
Registered: ‎04-24-2013

Hi Mistercoffee,

 

The issue is the constraints that are applied to the DCP during an OOC run will be different to the constraints applied to the boundary of an IP in a real design. When you write the DCP the constraints applied to it are only those that were needed for the DCP and are not the full set supplied with the IP e.g. you may have constraints that are needed at the top level not being included.

 

Best Regards
Aidan

 

------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if this answered your question
Give Kudos to a post which you think is helpful and may help other users
------------------------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Scholar
Scholar
3,992 Views
Registered: ‎04-04-2014


@amaccre wrote:

Hi Mistercoffee,

 

The issue is the constraints that are applied to the DCP during an OOC run will be different to the constraints applied to the boundary of an IP in a real design. When you write the DCP the constraints applied to it are only those that were needed for the DCP and are not the full set supplied with the IP e.g. you may have constraints that are needed at the top level not being included.

 

Best Regards
Aidan

 


Yes indeed that is the case with the current version of the tool. The older versions (at least the 2014.2 I sued prior to 2017.1) did include all the necessary constraints within the DCP. This has changed and as a result my whole IP flow needs to change too.

0 Kudos
Highlighted
Visitor
Visitor
3,327 Views
Registered: ‎11-30-2016

Any solution to this instead of changing all of my IP flow?

0 Kudos
Highlighted
Scholar
Scholar
3,304 Views
Registered: ‎04-04-2014


@zyxer wrote:

Any solution to this instead of changing all of my IP flow?


|'m afraid not, I have had to change my entire IP flow. Even if you decided to ignore the DCP import warning you will likely see problems at some point because the DCP no longer contains the necessary constraints. You have to import the xci/xcix to get the constraints too but you can have these pre-synthesized to speed up builds.

 

It does work but it is a real pain for those who have to change their flow and I would argue that the documentation needs to change because the DCP flow is still labelled as the default flow, which is clearly ridiculous. You shouldn't deprecate the default flow.

Highlighted
Explorer
Explorer
3,112 Views
Registered: ‎02-13-2012

I also have been dealing with this since switching from Vivado 2016.3 to 2017.2.  We also have an IP repository and build the IP OOC.  Likewise our concern was the possibility of the tool resynthesizing the IP each time.  Fortunately that actually does not occur.  After importing the XCI, the tool recognizes that the generated products are also present in the repository and does not create extra work for itself unless something is out of date.

 

But there is another use scenario where the tool won't accept the XCIs.  If you create a "post synthesis" project, then you get the error message that says that "name" XCI cannot be added because this is not an RTL project.  So the only option is to add DCP files instead.  And then have to suffer with the [Project 1-841] Critical Warnings.

 

Would it be possible for Vivado to recognize the project type and suppress that warning when it won't allow adding XCI's in the first place?

0 Kudos