Stats

  • Locked Locked
  • Replies 4
  • Subscribers 90
  • Views 14731
  • 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 Bob,

    Thanks for the information.

    The intent of this discussion is to understand how the "createClockTreeSpec -clkGroup" works and if it can be controlled using any of the sdc constructs, so that we can capture the design intent correctly.

    Currently we use "createClockTreeSpec -clkGroup" option to automatically detect the "ClkGroups" and it does return the list of "ClkGroups". However, i'm not sure how it works.

    If we specify a "false_path" between "CLKA and CLKB", it still groups them in ClkGroup since the automatic cts spec file creation does not honor "set_false_path" constructs.

    We tried using "set_clock_groups -asynchronous" sdc construct, to disable grouping of some clocks, however even this is not honored by auto cts spec file creator. A CCR for the same has been filed (CCR 796164).

    I believe that the cts spec file contents should reflect the timing intent captured by sdc, as closely as possible. If the design intent is not to analyze the timing paths between 2 clocks, then there is no need to "group" them as well.

    This is more so in the case where we want to build the "generated" clocks separately.

    Please do let me know if you get some information regarding the same.

     

    Regards

    Rajesh

Reply

  • Hi Bob,

    Thanks for the information.

    The intent of this discussion is to understand how the "createClockTreeSpec -clkGroup" works and if it can be controlled using any of the sdc constructs, so that we can capture the design intent correctly.

    Currently we use "createClockTreeSpec -clkGroup" option to automatically detect the "ClkGroups" and it does return the list of "ClkGroups". However, i'm not sure how it works.

    If we specify a "false_path" between "CLKA and CLKB", it still groups them in ClkGroup since the automatic cts spec file creation does not honor "set_false_path" constructs.

    We tried using "set_clock_groups -asynchronous" sdc construct, to disable grouping of some clocks, however even this is not honored by auto cts spec file creator. A CCR for the same has been filed (CCR 796164).

    I believe that the cts spec file contents should reflect the timing intent captured by sdc, as closely as possible. If the design intent is not to analyze the timing paths between 2 clocks, then there is no need to "group" them as well.

    This is more so in the case where we want to build the "generated" clocks separately.

    Please do let me know if you get some information regarding the same.

     

    Regards

    Rajesh

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.