• 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. flattening synthetic operators

Stats

  • Locked Locked
  • Replies 2
  • Subscribers 61
  • Views 13437
  • 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

flattening synthetic operators

archive
archive over 17 years ago

Hi, I have seen that flattening synthetic operators right after elaboration time, before any synthesis gives more efficient implementation (smaller area, faster circuit and less CPU runtime).

I want to know whether flattening operators before any synthesis has a disadvantage?


Originally posted in cdnusers.org by sporadic crash
  • Cancel
Parents
  • archive
    archive over 17 years ago

    Hi Grasshopper, I was quite busy with some other things. I am also using the latest 7.2-xxx versions here in house.

    I have more findings in this subject. Flatting helps if not all ports of inferred synthetic operator are used. This is reasonable, in that case RC can optimize out the parts of the operator which are connected to unused ports.

    Otherwise, it is better to keep the synthetic operators until the end of synthesis as you said. Sharing, CSA speculation or other transformations want to see unflattened synthetic operators, ie. keep them "virgin" until the end. The attributes you mentioned increase CPU runtime, which is also addressed in manuals.

    But synthetic operators must be flattened in the final stage, because in most case not all the bits in an arithmetic operation are used. Flattening and 2nd incremental synthesis saves silicon.

    It is also better to keep the synthetic operators unflattened even if retiming is enabled. In this case RTL Compiler is so intelligent that it moves FFs into the synthetic operators "thru the membrane", without destroying their structure. I must make experiments to see whether the attributes you mention really downsize/upsize datapaths with such structures. This is of course time-consuming to test..

    But I must admit, RTL Compiler is a very intelligent tool. This is not an ad. As a user I am really impressed of the performance of the tool.


    Originally posted in cdnusers.org by sporadic crash
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • archive
    archive over 17 years ago

    Hi Grasshopper, I was quite busy with some other things. I am also using the latest 7.2-xxx versions here in house.

    I have more findings in this subject. Flatting helps if not all ports of inferred synthetic operator are used. This is reasonable, in that case RC can optimize out the parts of the operator which are connected to unused ports.

    Otherwise, it is better to keep the synthetic operators until the end of synthesis as you said. Sharing, CSA speculation or other transformations want to see unflattened synthetic operators, ie. keep them "virgin" until the end. The attributes you mentioned increase CPU runtime, which is also addressed in manuals.

    But synthetic operators must be flattened in the final stage, because in most case not all the bits in an arithmetic operation are used. Flattening and 2nd incremental synthesis saves silicon.

    It is also better to keep the synthetic operators unflattened even if retiming is enabled. In this case RTL Compiler is so intelligent that it moves FFs into the synthetic operators "thru the membrane", without destroying their structure. I must make experiments to see whether the attributes you mention really downsize/upsize datapaths with such structures. This is of course time-consuming to test..

    But I must admit, RTL Compiler is a very intelligent tool. This is not an ad. As a user I am really impressed of the performance of the tool.


    Originally posted in cdnusers.org by sporadic crash
    • 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