cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
733 Views
Registered: ‎02-20-2018

Vivado 2018.3 DRC INBB-3 with VHD Modules

Jump to solution

My team recently upgraded from Vivado 2015.4.2 to 2018.3 and we are now running into an issue that was previously unseen.

We have several projects that all use much of the same VHDL files with different generics set to include or exclude various files, etc. Some projects are working fine and I can synthesize and generate bitstreams with no issues.

Other projects appear to synthesize, but something is not right. The synthesis takes much less time than expected and when implementation starts it fails after only a minute or so during opt_design.  The error that it gives is this:

ERROR: [DRC INBB-3] Black Box Instances: Cell 'Inst_Project_Main/Inst_DDS_0' of type 'ad9915_controller' has undefined contents and is considered a black box. The contents of this cell must be defined for opt_design to complete successfully.
ERROR: [DRC INBB-3] Black Box Instances: Cell 'Inst_Project_Main/Inst_Receiver' of type 'receiver' has undefined contents and is considered a black box. The contents of this cell must be defined for opt_design to complete successfully.

So far I have tried several things based on other forums posts I have found, but none have had any affect.

- I made sure the upper/lower case of the name of the entity matched

- I made sure the generic/port mapping matches and I am not forgetting any ports. Some of the output ports are left 'open' though.

- I have tried component instantation for the 'receiver' module, but that did not help either.

 

One of the main differences I have seen in the other forum posts is that they are all having this problem with IP instantation, but I am directly instantating other VHDL entities - not IPs.

Some perhaps helpful background on these projects. We use project-mode with some custom TCL scripts to assemble the project files and included constraints, etc. The scripts have not changed much since our move from 2015 to 2018. We use if/generate statements in lots of places based on constants set in packages to allow for more code reuse across multiple projects. We have some custom buttons defined with TCL scripts to do things like capture a timestamp of synthesis and copy the resulting bitstream to a new location - so we are not using the "Generate Bitstream" on the lefthand Flow Navigator panel.

Any help is greatly appreciated!

 

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Visitor
Visitor
653 Views
Registered: ‎02-20-2018

An update:

I think the issue deals with the IPs used in the project.

The working project is the first project I built in 2018.3 and therefore I had to upgrade/regenerate all of the IP Cores in order to generate the bitstream.

When I opened the other project (that doesn't build), it already had those same IP Cores regenerated (there was a project specific core I had to regenerate, but only 1) and I therefore did not regenerate the cores.

I just regenerated all of the IP Cores in the failing project and it is now synthesizing seemingly well according to the log.

Is this expected behavior? I have several projects that all use this same set of IP Cores, so I'll have to just regenerate the cores for each project I guess? This is not my preferred solution since it takes about an hour to do this - but if it's the only way then that's ok.

 

UPDATE: The project that was failing successfully generated the bitstream.

View solution in original post

0 Kudos
5 Replies
Highlighted
Visitor
Visitor
704 Views
Registered: ‎02-20-2018

An interesting note I noticed when comparing two projects side-by-side in Vivado.  One project built fine, and the other project failed as described.  Both use the same source files with the exception of some packages to set constants (some of which are used in if/generate statements).

None of the different constants between the projects deal with the instantiation or setting of generics in the ad9915_controller module I referenced in my previous post.

The project that built successfully shows a seemingly random instance of the ad9915_controller in the hiearchy tab in the Vivado GUI.  It is all the way at the bottom of the hierarchy (but still at the level I expect the module to be at) and is greyed out with small box and question mark (as if it is a missing source). The hierachy location where I expect it to be located looks normal though and makes no reference to it being missing. What's weird to me is that this is the project that successfully builds.

The failing project shows only the seemingly good instantation of this module in the hierarchy and does not contain this extra "missing" version of it.

0 Kudos
Highlighted
Moderator
Moderator
678 Views
Registered: ‎01-16-2013

@goodlinr 

 

Can you share the snapshots or sample project which gives more details of the issue?

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
664 Views
Registered: ‎02-20-2018

I'd be happy to share what information about the projects that I can, but can you give me some guidance on what aspects of the projects would be helpful? Are there specific reports I can generate?

0 Kudos
Highlighted
Visitor
Visitor
659 Views
Registered: ‎02-20-2018

Follow up to your request for a "snapshot".

I did not realize that a snapshot is a term for a zip file of the project and all it's files.  I won't be able to post a "snapshot" in that regard, so are there any specific reports to look at? Or properties to inspect in specific project files?

Thanks!

0 Kudos
Highlighted
Visitor
Visitor
654 Views
Registered: ‎02-20-2018

An update:

I think the issue deals with the IPs used in the project.

The working project is the first project I built in 2018.3 and therefore I had to upgrade/regenerate all of the IP Cores in order to generate the bitstream.

When I opened the other project (that doesn't build), it already had those same IP Cores regenerated (there was a project specific core I had to regenerate, but only 1) and I therefore did not regenerate the cores.

I just regenerated all of the IP Cores in the failing project and it is now synthesizing seemingly well according to the log.

Is this expected behavior? I have several projects that all use this same set of IP Cores, so I'll have to just regenerate the cores for each project I guess? This is not my preferred solution since it takes about an hour to do this - but if it's the only way then that's ok.

 

UPDATE: The project that was failing successfully generated the bitstream.

View solution in original post

0 Kudos