Home > Community > Forums > Digital Implementation > How to report latency at a sink pin in encounter

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 How to report latency at a sink pin in encounter 

Last post Thu, Jan 31 2008 8:05 PM by archive. 12 replies.
Started by archive 31 Jan 2008 08:05 PM. Topic has 12 replies and 3135 views
Page 1 of 1 (13 items)
Sort Posts:
  • Thu, Jan 31 2008 8:05 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    How to report latency at a sink pin in encounter Reply

    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
    • Post Points: 0
  • Wed, Feb 6 2008 12:31 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    latency_max_rise *should* be reporting the value you're looking for. It sounds like a bug to me.

    Are you trying to get the latency preCTS or postCTS? If preCTS, is the latency on the CK pin you're querying asserted on the pin itself? Somewhere upstream from the pin? Or on the clock that is connected to the pin?

    Thanks,
    Bob


    Originally posted in cdnusers.org by BobD
    • Post Points: 0
  • Wed, Feb 6 2008 1:10 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    Bob -

    Along the same lines, how do you declare a pin to be a sync pin and also a latency number for that pin? I knew how to do it in the synopsys tools.

    Thanks,

    Sanjay


    Originally posted in cdnusers.org by ssunder@sioptical.com
    • Post Points: 0
  • Wed, Feb 6 2008 1:37 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    Hi Sanjay,

    I'm not sure what you mean by "how do you declare a pin to be a sync pin". I'm not sure if you're asking this from a clock tree synthesis (CTS) perspective -or- from a static timing analysis (STA) perspective. Could you clarify? If you could provide the syntax you use in Synopsys we could probably map it to an equivalent notion in Encounter.

    For setting a clock latency on a pin, we'd use the same convention as the Synopsys tools: "set_clock_latency":
    Usage: set_clock_latency [-source [-early | -late]]
    [-rise | -fall] [-min | -max]


    Thanks,
    Bob


    Originally posted in cdnusers.org by BobD
    • Post Points: 0
  • Wed, Feb 6 2008 2:19 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    Bob -

    This is from CTS point of view.

    Lets say I have two clocks -

    create_clock -name CLK1 ....
    create_generated_clock -name CLK2 -source CLK1 ....

    Lets say I change create_generated_clock to create_clock and I do CTS on CLK2 first.

    Now I want to do CTS on CLK1 but I want to do it such that it balances CLK1 to CLK2. In synopsys I could declare the start point of CLK2 as a sync pin with the following command -
    dbDefineSyncPin

    That way the tool could balance CLK1 to CLK2 knowing the latency of CLK2.

    I am investigating two step CTS as opposed to 1 step CTS with through pins because I want to control rise and fall times with a lot more control.

    Let me know if there are other ways to do this. Incidentally there are other such several questions that I have that are related to this semi manual CTS process.

    Regards,

    Sanjay


    Originally posted in cdnusers.org by ssunder@sioptical.com
    • Post Points: 0
  • Wed, Feb 6 2008 4:20 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    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
    • Post Points: 0
  • Wed, Feb 6 2008 5:32 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    Bob -

    Thanks a bunch, this helps.

    Regards,

    Sanjay


    Originally posted in cdnusers.org by ssunder@sioptical.com
    • Post Points: 0
  • Wed, Feb 6 2008 7:26 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    Hi Friends ,

    For the same Issue I will use PreservePin in Clocktree specification file , Intrude of Macromodel .

    Give the CLK2 pin as PreservePin in ctstch file and try. you will balance the same.
    reason

    - Macromodel delays are hard and can not see the impact of others , not more realistic.
    - try Generating macromodels in combination logic pins or buffer , you will fail in encounter .
    - In most of the cases it will  work fine at Boundary pins .

    Let me know Bob-san comments .

    Cheers,
    -Mohan


    Originally posted in cdnusers.org by mohanch007
    • Post Points: 0
  • Thu, Feb 7 2008 5:33 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    Hi Mohan,

    Absolutely- the approach you describe is what I would recommend as a first course of action for its simplicity. In Sanjay's case, he was looking to have different characteristics for the clock network downstream from CLK2 than the rest of the clock network. In cases like this, it seems the bottoms-up MacroModel approach is the way to go.

    I'm interested in your comment that generating macromodels for combinational logic pins or buffers. In what way do you see a failure when trying this? In Sanjay's case, I'd guess the create_generated_clock statement is applied to a sequential element but if there's a failure occurring when macromodels are attempted to be generated for a combinational element it would be good to know about that so the software could be improved.

    Thanks,
    Bob


    Originally posted in cdnusers.org by BobD
    • Post Points: 0
  • Thu, Feb 7 2008 6:37 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    Bob/Mohan -

    Here is the background for my case. For noise reasons we need to slow down the transition times on our clock trees.
    BUFMAXTRAN and SINKMAXTRAN dont seem to work all that well. So our AE has gotten me some "hidden variables". These are not working all that well either. At a given time, it appears that you can either get skew, transition times or balanced clocks, but not all of them at the same time. The problem currently is how to get controllable (large 1ns or greater) rise times and have decent skew. Some amount of skew can be recovered by inserting buffers in the datapath. I have tried all kinds of experiments and I have not found an optimal solution.

    Regards,

    Sanjay


    Originally posted in cdnusers.org by ssunder@sioptical.com
    • Post Points: 0
  • Fri, Feb 8 2008 10:57 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    I guess the discussion is going away from the main topic...
    Bob,I am doing the analysis postCTS stage.
    Well latency_max_rise switch in get_property gives a NA result.It does not flag an error neither it shows a value.I tried running the same in different versions of encounter but no change in result.


    Originally posted in cdnusers.org by abhiroy03
    • Post Points: 0
  • Tue, Feb 12 2008 12:54 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    I do postCTS timing analysis
    and I get this issue too.  there is no error or warnings, But the rerurned value seems quiet odds. 

    I am wondering it a bug or feature?



    Posted By BobD on 2/06/2008 12:31 PM
    latency_max_rise *should* be reporting the value you're looking for. It sounds like a bug to me.

    Are you trying to get the latency preCTS or postCTS? If preCTS, is the latency on the CK pin you're querying asserted on the pin itself? Somewhere upstream from the pin? Or on the clock that is connected to the pin?

    Thanks,
    Bob



    Originally posted in cdnusers.org by aidans
    • Post Points: 0
  • Wed, Feb 13 2008 6:55 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: How to report latency at a sink pin in encounter Reply

    Hi abhiroy03 and aidans,

    I did some research on this topic, and it appears that our expectation of what latency_rise_max should return isn't aligned with what latency_rise_max was designed to return. From the "Advanced Timing TCL Scripting Commands" section of the FE Text Command Reference document it says:

    encounter> man get_property
    Pin Properties:
    latency_rise_max Returns the maximum rise insertion delay specified by an
    [i]explicit set_clock_latency[/i] at the pin.
    Return type: float

    This hints that latency_rise_max only tells us if set_clock_latency has been applied directly to the clock pin in question. Of course, it is possible for a CK pin to have a latency other than 0 by applying it to the master clock associated with the CK pin, or even an pin "upstream" in the clock tree from the CK pin (say for example you've SDC-asserted a set_clock_latency an integrated clock gating cell).

    I hope this clarifies the intended use model for the latency_rise_max field.

    From this, it seems that arrival_max_rise is the best way to gain insight into the cumulative arrival time at the CK pin. I understand that the values you're seeing for arrival_max_rise aren't making sense with respect to what you see in the timing report. I did some tests here on a small/simple design and I see it working as I'd expect it to, but I seem to recall in the past that under more complex scenarios it was indeed hard to discern how the values were being calculated. Maybe we can turn our collective attention to trying to understand why arrival_max_rise isn't returning the values we'd expect it to?

    Thanks,
    Bob


    Originally posted in cdnusers.org by BobD
    • Post Points: 0
Page 1 of 1 (13 items)
Sort Posts:
Started by archive at 31 Jan 2008 08:05 PM. Topic has 12 replies.