Home > Community > Blogs > Digital Implementation > understanding clock net markings in soc encounter
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Digital Implementation blog (individual posts).
 

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: *

Understanding Clock Net Markings in SoC-Encounter

Comments(7)Filed under: CTE-TCL, clocks, dbGet, Digital Implementation forums, encounter, saveClockNets

I'm happy to report that the Digital Implementation Forums are picking up momentum now that the old cdnusers.org has been retired.  It is great to see old friends and new ones on the new Cadence.com engaging in some really useful discussions.  We had a couple of posts in particular that are frequent points of discussion and I thought I'd highlight one in the blog here this week.

Forum user Vicky writes (http://www.cadence.com/community/forums/T/10364.aspx):

"I would like to know what is the easiest way to get all the clock nets in the design using encounter. I do know that we can do it using saveClockNets which needs a clock tree spec file to be read in. I would like to  know if there is a much simpler way to do it may be using some get_nets command."

My response was:

"This area is often confusing since there are lots of different types of ways/things that people might consider "clocks or not clocks". They are:

1) A net was found to be clock from a timing perspective. The timing constraints are loaded which includes "create_clock" statements, timing analysis is performed, the create_clock statements propagate from net to net and then some objects along that tracing are considered "clock" or not.

2) A marking in the .lib declares a lib_cell pin be a clock or not.

3) A net in the design was found to be part of a clock tree that's been physically built and has a DEF marking on the nets declaring them to be "clock".

Hopefully we now have a baseline for discussing whether things are clocks or not.  It sounds like what you're looking for (since you say that you don't want to load a clock tree spec file) is a list of nets that are considered "clock" from a timing perspective (ie, case "1" above).  The easiest way I can recommend to get this list of nets is using dbGet.

First, time the design so that the nets are marked in the db as clock or not clock:
encounter> timeDesign -prePlace

Then, use dbGet as follows:
encounter> dbGet [dbGet -p top.nets.isClock 1].name   
DTMF_INST/m_spi_clk DTMF_INST/m_clk DTMF_INST/m_rcc_clk DTMF_INST/m_digit_clk DTMF_INST/TDSP_DS_CS_INST/n_28 DTMF_INST/TDSP_DS_CS_INST/n_30

Some other things to consider:

1) We do have a "get_nets" command within SoC-E, *but* it doesn't offer an "is_clock" marking on nets.

2) The "is_clock" marking that we see on pins (ie, "get_property [get_pins i0/CK] is_clock") is a .lib marking (ie, of type "2" above), *not* the affect of SDCs that have influenced whether things are clock or not."


I like questions like this for 3 reasons:

  1. The fundamental question isn't tool specific.  Regardless of the tool we're using, we need to understand the difference between CTS clocks, timing clocks, and .lib markings on clock pins.
  2. There are multiple ways to get this information out of the tool. dbGet is just one way, but there are other ways to get at this information.  However, understanding how to leverage db access routines in any tool can make your user experience much more pleasant because once you're able to navigate the db you're no longer limited by the natively defined super commands that might not do everything you want to do in the system.
  3. We discovered that "is_clock" is not a property currently exposed by "get_nets".  Sometimes, it is as important to know what the system can't or doesn't do as it is what it can do.  (as an aside, it seems to me that get_nets should expose an "is_clock" property and consequently I filed an enhancement request with R&D requesting this functionality)

Thanks for the post, Vicky!  I hope my response helped and I think your question raises awareness of an area of the tool that has caused confusion for others in the past.

Question of the Day:

Is there a forum post you've found particularly helpful that you'd like to highlight?  If so, please leave a comment below.

Comments(7)

By eminemshow on August 26, 2008
Great Post´╝î Bob!  The way I often used to get all the clock nets is 'always making a timing graph building, using timeDesign command', then using db commands to get the clock nets since we are using SOCE 52. Hoho, seems that we are using the same method.

By BobD on August 27, 2008
Thanks for your comment, eminemshow.  It sounds like our approaches were very similar indeed.  It makes me wonder if there is a general need for enhancement of the tool in this area, since several users are requesting the ability to output the clock nets from a timing perspective?  If you or other users could describe design scenarios where the list of timing clock nets are needed (as opposed to the CTS clock nets output by "saveClockNets"), it would be helpful in guiding how to craft a more generic solution for this situation.

By Rajesh Vembu on October 16, 2008
Bob, very informative post.  

One of the scenarios i can think of is : in a design with reconvergent clocks, passing through muxes, it is hard to ascertain if the output of the mux is excluded from IPO. In these cases, having a list of "timing clock" nets would help us identify/verify if these nets are optimized or not.

Currently, we have a utility which identifies these nets and are passed as a list of nets to be "excluded" from IPO. I hope the latest version of encounter do handle these cases. Having said that, it would be good to have it verified in a more efficient manner and a "is_clock" attribute on a net would be a good feature to have.


By BobD on October 17, 2008
Hi Rajesh!  That is a very good example- thanks for sharing it.  I will take your suggestion and follow-up with R&D to discuss enhancing the tool in this area.  I'll post another comment here when I have more information.

By Rajesh Vembu on March 30, 2009
Hey Bob, any updates on this?

By BobD on April 15, 2009
Thanks for the reminder, Rajesh.  We're still discussing some of the details on the way this should be implemented.  I'll follow-up again once I have more details.

By Vivek Bhardwaj on April 23, 2009
Recently a customer posed an interesting situation to me. They are using showPtnWireX -excludeClock which required clock net marking. However, this could only be triggered by a report_timing/timeDesign or through delay calculation. None of it is required at this point in customer's flow.If the RC's are not extracted  the following is a simple workaround :)-
catch {delayCal}   => this triggered inexpensive clock marking.

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
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.