Stats

  • Locked Locked
  • Replies 1
  • Subscribers 91
  • Views 13228
  • 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

RC TNS optimization is not enough

Ran Fisher

I'm synthesizing with "tns_opto" attribute set to true. I still don't like the results I'm getting. I have many paths with the same timing violation. The first one I see isa real one I expected, the second one is not real and I have proved it.

 How did I prove it? I created a special path group for this path and did an incremental synthesis. The overall worst path was improved by 5ps, and the path I put in a special group was improved by 70ps. My frequency target is more than 1GHz, so these small numbers are significant.

 I'd like to have synthesis results where the really bad paths are distinguishable.

I think the problem is that "tns_opto" actually works on endpoints only, and the two paths in question indeed share the same endpoint. I'd like to improve the other paths because I think I can do some special work in P&R (maybe useful skew on the start point), or special routing etc.

Encounter supports "critical range", like DC does. "tns_opto" is not exactly the same. Has anybody ever solved this?

Parents

  •  Hey Ran,

     I'm not sure I understood how you conclude that the path that improved by 70s is a false one but in any case, if you are sure that a path that is reported as a violator is not a real problem in your design then you should definately do a 'set_false_path' on it. This will prevent the tool from trying to optimize it.

     Regarding tns_opto, maybe you could try to be more specific when you group the paths. I mean something like this:

    group_path -name <name_of_group> -from <startpoint> -to <endpoint> -critical_range <usually about 10-20% of target max delay> -weight 5

     If you make the critical_range value rather large the tool will try to optimize more paths (at the expense of runtime). After doing an incremental compile you should see that all paths in the group improve their timing.

     

    Hope this helps,

    A.

     

     

       

Reply

  •  Hey Ran,

     I'm not sure I understood how you conclude that the path that improved by 70s is a false one but in any case, if you are sure that a path that is reported as a violator is not a real problem in your design then you should definately do a 'set_false_path' on it. This will prevent the tool from trying to optimize it.

     Regarding tns_opto, maybe you could try to be more specific when you group the paths. I mean something like this:

    group_path -name <name_of_group> -from <startpoint> -to <endpoint> -critical_range <usually about 10-20% of target max delay> -weight 5

     If you make the critical_range value rather large the tool will try to optimize more paths (at the expense of runtime). After doing an incremental compile you should see that all paths in the group improve their timing.

     

    Hope this helps,

    A.

     

     

       

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.