• 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. Digital Implementation
  3. OCV mode optimization in encounter

Stats

  • Locked Locked
  • Replies 4
  • Subscribers 91
  • Views 15438
  • 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

OCV mode optimization in encounter

MadhuNS
MadhuNS over 16 years ago

Hi All,

Its been a general practise with our BE folks to use BCWC mode with some derate and dubb it as "equivalent" to OCV mode.

Its been a nighmarish to close design via ECO since timing engines using true OCV modes show much skewed timing when compared with encounters native timer.

Is there an OCV mode in encounter ? Since I'am novice wrt encounter grapevine says that since two libraries are required for OCV mode its not recommended,

which brings me to the next point has any one figured out a way to derate ECSM/NLDM library and use the derated library as the second library required by OCV.

  • Cancel
Parents
  • MadhuNS
    MadhuNS over 16 years ago

    Thx for the reply Bob, Kari

    I understand that encounter has MMMC flows mode is supported by derated commands. Going into a more intricate level my timing analyzer works in this way for OCV:

    Uses only 1 library and uses early and late derates .( as does encounter) The other thing it does is the following : Lets say we are doing a SETUP analysis with worst case libraries : When ever the tool finds multi input gates it propogates max slews for delay calculation in the launch path and min slews for delay calculation in the capture path , thus adding an extra element of pessimism . Would encounter do the same when the derates have been specified ? Consider that fact that in most designs clock tree is  not comprised of sime buffers or invertors but a lot of combo logic as well hence the difference turns out be significant. 

    The goal here is to understand if by some black magic I could create derated libraries and do the setting

    setAnalysisMode -analysisType onChipVariation

    Would there be better correlation in timing as seen from encounter and seen by my STA tool ?

    Since I mention the word correlation ,  I would mention that we are looking into RC correlation by running ostrict hence I would request the discussion to be specific to OCV mode optimization of encounter.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • MadhuNS
    MadhuNS over 16 years ago

    Thx for the reply Bob, Kari

    I understand that encounter has MMMC flows mode is supported by derated commands. Going into a more intricate level my timing analyzer works in this way for OCV:

    Uses only 1 library and uses early and late derates .( as does encounter) The other thing it does is the following : Lets say we are doing a SETUP analysis with worst case libraries : When ever the tool finds multi input gates it propogates max slews for delay calculation in the launch path and min slews for delay calculation in the capture path , thus adding an extra element of pessimism . Would encounter do the same when the derates have been specified ? Consider that fact that in most designs clock tree is  not comprised of sime buffers or invertors but a lot of combo logic as well hence the difference turns out be significant. 

    The goal here is to understand if by some black magic I could create derated libraries and do the setting

    setAnalysisMode -analysisType onChipVariation

    Would there be better correlation in timing as seen from encounter and seen by my STA tool ?

    Since I mention the word correlation ,  I would mention that we are looking into RC correlation by running ostrict hence I would request the discussion to be specific to OCV mode optimization of encounter.

    • 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