• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Logic Design
  3. Question about Hierarchical Comparison Flow

Stats

  • Locked Locked
  • Replies 1
  • Subscribers 61
  • Views 14625
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Question about Hierarchical Comparison Flow

archive
archive over 19 years ago

Hi, all.

The problem is:
I attempted to use command
WRIte HIer_compare Dofile
for comparison of two hierarchical
designs: rtl and back annotation rtl after synthesis the first one (hierarchy was keeped).
Conformal wrote out a hierarchical dofile script but without starting from the lower level module of hierarchy and progressing to the top root module.
Given script verifies only the two top modules of hierarchical designs.
And several warnings appears at running this script, so as:
// Warning: Child module 'sub_module_name' used in Golden module 'top_module_name' 2 times, but in Revised module 'sub_module_name' 1 times (non-balanced). Skip 'sub_module_name'

And after that appears in Conformal konsole:
"? modules are not output for hierarchical compare due to non-balanced instantiations"
"1 modules are output for hierarchical compare"
And this module is the top.

But I know that the hierarchies are equal
and built, but the names of several corresponding instantiations slightly differs (for example sub_module_name for Golden and sub_module_name_1 for Revised)

And this module is the top.


So my question is:
How compare two hierarchical designs by matching their instance-names, but not modules? Or what have I do if their names slightly differs? How can I balance instantiations?
Please give me an advise.

Thanks.

With best regards, Valery Kartashev.


Originally posted in cdnusers.org by valour
  • Cancel
Parents
  • archive
    archive over 19 years ago

    Hi Valery,

    When LEC runs hierarchical compare, it needs to be able to match the modules by name. So for this case, you need to use "add renaming rule" for the modules. For example: add re r mod1 "%s_1" "@1" -module -revised
    This wil rename the revised module name from sub_module_name_1 to sub_module_name to match the module name on the golden side. Lastly, if there is uniquification done on the gate netlist, you need to reflect this in LEC. The command is "uniquify -all"
    If the module name on the revised side is due to uniquification, then just use "uniquify -all" first before doing "write hier dofile". If the module names were changed by synthesis, then you need to use the add renaming rule.
    So give these two options a try and see if the write hier dofile will resolve the unbalanced instantiations.

    Regards,
    Yong Kim


    Originally posted in cdnusers.org by yonghk
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • archive
    archive over 19 years ago

    Hi Valery,

    When LEC runs hierarchical compare, it needs to be able to match the modules by name. So for this case, you need to use "add renaming rule" for the modules. For example: add re r mod1 "%s_1" "@1" -module -revised
    This wil rename the revised module name from sub_module_name_1 to sub_module_name to match the module name on the golden side. Lastly, if there is uniquification done on the gate netlist, you need to reflect this in LEC. The command is "uniquify -all"
    If the module name on the revised side is due to uniquification, then just use "uniquify -all" first before doing "write hier dofile". If the module names were changed by synthesis, then you need to use the add renaming rule.
    So give these two options a try and see if the write hier dofile will resolve the unbalanced instantiations.

    Regards,
    Yong Kim


    Originally posted in cdnusers.org by yonghk
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information