Stats

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

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

  • Hi Sporadic Crash,

    long time no post. My understanding is that ungrouping synthetic operators is not such a hot idea. Basically, the way it was explained to me is that RC will loose its ability to re-architect the DP components and also you will miss out on things like speculation and op-merging. Not sure what version of RC you are using but since 7.1 if I am not mistaken, there is also the attributes dp_postmap_upsize and downsize. This allows RC to even change DP architecture later during incremental. Seems to cost me some runtime but the results have been pretty good. I also know that there is the ability to do auto_ungrouping in 7.2 but have not played much with it. I would be curious to hear if you have.

    good luck,
    gh-


    Originally posted in cdnusers.org by grasshopper

  • 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

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.