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!

Showing results for 
Search instead for 
Did you mean: 
Visitor jpn123
Registered: ‎05-30-2018

Vivado IP Containers and Unmanaged IP

We use some unmanaged IPs in Vivado (specifically the output of the GTH Transceiver Wizard). So, we generate the output products, then change some of the HDL and then manually synthesize the outputs (as described in https://www.xilinx.com/support/answers/57546.html). The DCP that is generated is then checked into version control and reused.


However, this approach only worked prior to Vivado 2017.1 in which constraints were stored as part of DCPs. In newer versions of Vivado the xci/xicx (IP container) flow is recommended instead of the DCP flow because the IP's constraints aren't stored in the DCP anymore. See https://forums.xilinx.com/t5/Adaptable-Advantage-Blog/Support-for-IP-using-quot-Standalone-quot-dcp-Instead-of-xci/ba-p/793092

For our new products we've adopted this approach and it works well for cases where we don't need to manage the IP outputs.

However, for this specific IP we need to modify the outputs. The problem now is to figure out what the best way is to store the OOC synthesis output for the IP. Since we get a DCP from the unmanaged files, we can use it but the constraints will be a problem. The other approach of using an IP container does not work since Vivado does not allow you to use an IP container in this case.

I'm thinking to still use the generated DCP, but also check in the xcvr.xdc file (not the xcvr_ooc.xdc file).

Any ideas/recommendations would be appreciated.



I've since realized that the xcvr.xdc generated out of the box will need to be modified as it is too generic. For example:

# Channel primitive location constraint
set_property LOC GTHE4_CHANNEL_X0Y1 [get_cells -hierarchical -filter {NAME =~ *gen_channel_container[0].*gen_gthe4_channel_inst[1].GTHE4_CHANNEL_PRIM_INST}]

The above will match other transceivers in the design as well, as the context in which the xdc file is applied is now on a global design level, not just on an IP level anymore.

0 Kudos
1 Reply
Scholar markcurry
Registered: ‎09-16-2009

Re: Vivado IP Containers and Unmanaged IP

Note that the following is completely unsupported by Xilinx - they don't even like to admit it exists, (even though it's the industry standard for digitial design)

We don't use XCI nor XCIX, nor DCPs to manage ANY of our Xilinx IP.  We use a "Just The RTL" flow and only checkin the underlying RTL from the various Xilinx tools for their IP.  Then just treat it like any other RTL code, and synthesize it along with the rest of the design.

The trick to make this work is to never use OOC flows - always choose Global flows when generating Xilinx IP - so that you get the the (parameterized) RTL output instead of a pre-contextualized netlists 

It sounds like you're already comfortable delving in the Xiinx IP HDL to do what you need to do.  That's the hard part - you've done 95% of the work.  Now just throw out the cruft, and you'll be good to go.

As a side benefit this make Vivado upgrades so much easier too.  Just point to the new version of Vivado and build again.  No "upgrade IP" or other steps to get in your way - the tool only sees (your revision controlled) RTL, and builds the same thing.  No restrictions either on re-configuring either - it's just a parameter update.  (The currently recommend Xilinx IP flows lock down your configuration if you want to keep the same IP version through different Vivado releases - there's no such restriction in a "Just The RTL" flow.)




0 Kudos