• 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. How to report latency at a sink pin in encounter

Stats

  • Locked Locked
  • Replies 12
  • Subscribers 90
  • Views 19354
  • 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

How to report latency at a sink pin in encounter

archive
archive over 17 years ago

I want to know how to report latency of a sink pin in encounter.
Suppose I have a pin "a/b/c/d/CK" .How to report the latency.

I tried the following command.
get_property [get_pins a/b/c/d/CK] arrival_rise_max..But the value it reports is quite different from the value I see at the same pin after timedesign and report_timing.Is there a more reliable command.
Most of the switches in get_property are not working like latency_max_rise etc..


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

    Hi Sanjay,

    Thanks a lot for clarifying. What you're trying to do makes sense to me now. Encounter does support what you're seeking to do. There are a couple of key building blocks you'll need.

    First is a "MacroModel". A MacroModel is a mechanism the tool uses to model the insertion delay and load downstream from a sync point in the clock tree. When building CLK2 you'll want to create a MacroModel that describes the insertion delay downstream from the input pin of the instance CLK2 is built from. If CLK2 had an insertion delay of 0.5ns, it would look something like this:

    MacroModel pin a/b/c/d/CK 0.5000ns 0.5000ns 0.5000ns 0.5000ns 0.0pf

    You can get the tool to generate a MacroModel for you when you're calling ckSynthesis on CLK2 with "ckSynthesis -macromodel . The last field is the load of the pin. I'd recommend making that 0.0pf in your scenario because the input pin cap of the instance you're building CLK2 from has a .lib to model its input pin cap (I presume) and any capacitance you have in this field is additive with what is modeled in a .lib. The reason it may be created as something other than 0.0pf is because MacroModels were originally created to model completed clock trees for partitions, in which case the input pin cap might not be captured in a .lib for the partition depending on the stage of implementation the design is in.

    Okay, once you have the MacroModel for CLK2 you're ready to work on CLK1. You can tell CTS to stop on a/b/c/d/CK with the "LeafPin" construct in you clock tree spec file. When you want to specify the clock tree for CLK1 you want to inform it of the presence of the MacroModel file. You can do this by sequential calls to specifyClockTree like this:

    specifyClockTree -clkfile CLK2.clockSpec
    ckSynthesis -macromodel CLK2.macroModel
    cleanupSpecifyClockTree
    specifyClockTree -clkfile CLK2.macroModel
    specifyClockTree -clkfile CLK1.clockSpec
    ckSynthesis

    I hope this gives you a good starting point. You can find more information on this in the SoC-E User's Guide in the Clock Tree Synthesis section.

    Regards,
    Bob


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

    Hi Sanjay,

    Thanks a lot for clarifying. What you're trying to do makes sense to me now. Encounter does support what you're seeking to do. There are a couple of key building blocks you'll need.

    First is a "MacroModel". A MacroModel is a mechanism the tool uses to model the insertion delay and load downstream from a sync point in the clock tree. When building CLK2 you'll want to create a MacroModel that describes the insertion delay downstream from the input pin of the instance CLK2 is built from. If CLK2 had an insertion delay of 0.5ns, it would look something like this:

    MacroModel pin a/b/c/d/CK 0.5000ns 0.5000ns 0.5000ns 0.5000ns 0.0pf

    You can get the tool to generate a MacroModel for you when you're calling ckSynthesis on CLK2 with "ckSynthesis -macromodel . The last field is the load of the pin. I'd recommend making that 0.0pf in your scenario because the input pin cap of the instance you're building CLK2 from has a .lib to model its input pin cap (I presume) and any capacitance you have in this field is additive with what is modeled in a .lib. The reason it may be created as something other than 0.0pf is because MacroModels were originally created to model completed clock trees for partitions, in which case the input pin cap might not be captured in a .lib for the partition depending on the stage of implementation the design is in.

    Okay, once you have the MacroModel for CLK2 you're ready to work on CLK1. You can tell CTS to stop on a/b/c/d/CK with the "LeafPin" construct in you clock tree spec file. When you want to specify the clock tree for CLK1 you want to inform it of the presence of the MacroModel file. You can do this by sequential calls to specifyClockTree like this:

    specifyClockTree -clkfile CLK2.clockSpec
    ckSynthesis -macromodel CLK2.macroModel
    cleanupSpecifyClockTree
    specifyClockTree -clkfile CLK2.macroModel
    specifyClockTree -clkfile CLK1.clockSpec
    ckSynthesis

    I hope this gives you a good starting point. You can find more information on this in the SoC-E User's Guide in the Clock Tree Synthesis section.

    Regards,
    Bob


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