cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
vazquez
Participant
Participant
4,614 Views
Registered: ‎10-10-2007

Vivado 2017.1 Setting Toplevel generics VHDL

Hi,

 

when trying to set toplevel generics (in Vivado/Settings/Project Settings/General/Generics) which are different

from the defaults of those, Vivado 2017.1 does not seem to check the changed values. As a consequence

trying to select different xci files by the "changed" generic leads to an error, Vivado excludes the xci from the hierarchy.

 

The same problem has been described in

https://forums.xilinx.com/t5/Design-Entry/2017-1-automatic-compile-order-VHDL-gneric-IP-packer/td-p/761914

 

Could you please shed some light on that important issue?

 

Rgds

0 Kudos
5 Replies
prathikm
Moderator
Moderator
4,575 Views
Registered: ‎09-15-2016

Hi @vazquez,

 

I believe this is something similar to this example like, say: a design having generic WIDTH : integer <some value> declared in top level which is passed to the sub-module. Sub-module has an if-generate statement which uses WIDTH generic and decide whether to generate the IP or not. In 2017.1, synthesis is treating IP (not able to bind generic) as a black_box and hence opt_design fails.

But 2016.4 takes the correct value of WIDTH from top module to synthesize the design and implementation passes without any issues.

 

This is a bug reported in 2017.1 and a CR-974005 (active) has been filed for it. 

 

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
vazquez
Participant
Participant
4,559 Views
Registered: ‎10-10-2007

Thank you very much.

 

Rgds

0 Kudos
patocarr
Teacher
Teacher
4,538 Views
Registered: ‎01-28-2008

@prathikm

 

  Bumping this thread to indicate that not only top level generics display the issue, but all generics at any hierarchy level. This is a serious flaw in 2017.1.

 

  Any idea how to check the CR-974005 bug fix status?

 

Thanks,

-Pat

 

Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog

0 Kudos
nupurs
Moderator
Moderator
4,489 Views
Registered: ‎06-24-2015

@patocarr,

 

The issue shall be fixed in next two releases.

Till then, you can use the workaround of using manual compile order.

Thanks,
Nupur
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (click on the 'thumbs-up' button).
0 Kudos
patocarr
Teacher
Teacher
4,394 Views
Registered: ‎01-28-2008

Thanks for the suggestion, @nupurs

 

Unfortunately, the manual compile order doesn't have any effect on this issue in my testing. The generics are just not replaced as they traverse the hierarchy; only the default value is applied, and optional blocks (ie. generate if) are not evaluated.

 

Thanks again,

-Pat

 

Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog

0 Kudos