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!

AR# 69320

2017.x Vivado - Design fails in opt_design with a black-box error for a module implemented in a conditional statement (using generic or parameter value)

Description

I am synthesizing and implementing my design in Vivado 2017.1 and it fails in opt_design.

It is reporting black boxes for the modules that seem to have been moved out of the hierarchy.

This same design synthesizes and implements without issues in Vivado 2016.4.


The problem appears to be related to conditional statements. I have modules that are actively used based on the value of a generic or parameter.

For example, if the generic is true, the code will generate module A and if false, it will generate module B and "true" is the default value of the generic.

The design appears to implement without issue if the default value of the generic is used. 

However, if a non-default value is used, I see a black box error for the module that should be generated (Module B in this example).

Solution

In Vivado 2017.1, the hierarchy parser was enhanced to evaluate conditional statements when building the hierarchy view and determining the compile order and which files should be sent to synthesis.

Unfortunately, the code is only using the default value of generics and parameters based on the current level of hierarchy.

Therefore if the use of a module is dependent on a non-default value, it will be filtered out of the compile list and not sent to synthesis even if the generic value is correctly being sent from a higher level module.

Synthesis will black-box the module and later implementation fails as the black-box cannot be resolved.

If the HDL does not specify a default value for the generic and the value of the generic was not passed from the higher level module, no module will be generated, as there is no default value.


In most cases, you can work around this issue by setting the "Hierarchy Update" option to "Automatic Update, Manual Compile Order".

To do this in a Tcl script use the following command:

set_property source_mgmt_mode DisplayOnly [current_project]

With this option, the hierarchy in the Vivado Hierarchy Source View will still be displayed based on the default value of generics and parameters, but all source files will be sent to synthesis where the synthesis compile will correctly determine the generic or parameter value and compile the required files.

There are three different ways to pass a generic / parameter value to the HDL that will all see this problem

  • The generic / parameter value is set from a higher level (for example, top level) module.
    In Vivado 2017.2 the hierarchy parser has been fixed to properly evaluate the value of a generic or parameters in a conditional statement based on the value being passed from the highest level the generic or parameter is found.

  • The generic / parameter value is set in the Project Settings under language options.
    These values are not being evaluated by the hierarchy parser.
    This is fixed in Vivado 2017.3. Until then the "Automatic update, Manual Compile Order" option should be used.

  • The generic / parameter value is set by sending the value to synthesis through the "More Options" synthesis option.
    This method is not supported as there is no mechanism for the Vivado hierarchy parser to know that a generic is being passed to synthesis.
    The "Automatic update, Manual Compile Order" option should be used in this case if the project cannot be changed to pass the values through the project language option.
AR# 69320
Date 11/21/2017
Status Active
Type General Article
Tools
  • Vivado Design Suite - 2017.1
Page Bookmarked