Understanding Clock Net Markings in SoC-Encounter

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.