Stats

  • Locked Locked
  • Replies 4
  • Subscribers 90
  • Views 14737
  • 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 ClkGroups are identified from sdc during cts spec file creation?

Rajesh Vembu

Automatic clock tree specification file generation using encounter could result in some ClkGroup definitions.

It would be great if someone can throw some light on how ClkGroups are identified by tool. Are there any specific sdc constructs that influences the grouping??

Parents

  • Hi Rajesh,

    I did some research into this issue.  Here's what I found:

    • createClockTreeSpec (the TCL command that drives automatic clock tree spec file generation) doesn't have a productized ability to derive ClkGroups as of 9.1.USR2.
    • It write blank statements as a place-holder for users to fill in on their own:
      #-- Clock Group --
      #ClkGroup
      #+ <clockName>
    • Conceptually, a way this capability could sensibly work is that any 2 AutoCTSRootPins that drive registers that "talk" to one another should be grouped together because they could potentially cause a timing violating if their clock latencies weren't balanced with respect to one another.
    • A command that might be helpful in determining which clock networks talk to one another:
      check_timing -check_only clock_crossing -verbose
      It outputs data like this:
           +------------------+
           |   TIMING CHECK   |
           |  CROSSING CLOCKS |
           |------------------|
           |  From | Crossing |
           | Clock |  Clocks  |
           |-------+----------|
           |  clka | clkb     |
           +------------------+
    • I would imagine this computation could take quite some time on large designs, so perhaps that's why automatic clock group creation isn't productized- at least not yet.
    Hope this helps,
    Bob


Reply

  • Hi Rajesh,

    I did some research into this issue.  Here's what I found:

    • createClockTreeSpec (the TCL command that drives automatic clock tree spec file generation) doesn't have a productized ability to derive ClkGroups as of 9.1.USR2.
    • It write blank statements as a place-holder for users to fill in on their own:
      #-- Clock Group --
      #ClkGroup
      #+ <clockName>
    • Conceptually, a way this capability could sensibly work is that any 2 AutoCTSRootPins that drive registers that "talk" to one another should be grouped together because they could potentially cause a timing violating if their clock latencies weren't balanced with respect to one another.
    • A command that might be helpful in determining which clock networks talk to one another:
      check_timing -check_only clock_crossing -verbose
      It outputs data like this:
           +------------------+
           |   TIMING CHECK   |
           |  CROSSING CLOCKS |
           |------------------|
           |  From | Crossing |
           | Clock |  Clocks  |
           |-------+----------|
           |  clka | clkb     |
           +------------------+
    • I would imagine this computation could take quite some time on large designs, so perhaps that's why automatic clock group creation isn't productized- at least not yet.
    Hope this helps,
    Bob


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.