Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
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.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
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..
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
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
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
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
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.0pfYou 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.clockSpecckSynthesis -macromodel CLK2.macroModelcleanupSpecifyClockTreespecifyClockTree -clkfile CLK2.macroModelspecifyClockTree -clkfile CLK1.clockSpecckSynthesisI 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
Bob -Thanks a bunch, this helps.Regards,Sanjay
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
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
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
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.
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_propertyPin Properties:latency_rise_max Returns the maximum rise insertion delay specified by an[i]explicit set_clock_latency[/i] at the pin.Return type: floatThis 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