• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Logic Design
  3. constraining between ports and clock domain

Stats

  • Locked Locked
  • Replies 19
  • Subscribers 61
  • Views 22036
  • 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

constraining between ports and clock domain

archive
archive over 18 years ago

I have a clock named "clk_design". How can I constrain all paths between input ports and this clock?

I have applied following:

define_cost_group input_to_clk_design
path_group -from /designs/*/ports_in/* -to clk_design -group input_to_clk_design -name input_to_clk_design_path

But when I apply report timing -cost_group input_to_clk_design, report tells me that no path group has been found.

Any ideas? What shall i give as -to option for path_group?



Originally posted in cdnusers.org by sporadic crash
  • Cancel
  • archive
    archive over 18 years ago

    dc::set_input_delay should work, how do you apply it?


    Originally posted in cdnusers.org by synthman
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    set_input_delay $delay -clock clk_designl $inputs

    it is called from an SDC file. I have written in the previous posting to imply that I have used an SDC style, not RC style.

    Am I missing anything here?


    Originally posted in cdnusers.org by sporadic crash
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    In your previous email you wrote

    1. create_clock
    2. define_cost_group
    3. path_group

    You need to read the sdc between 1 and 2. not before 1 or after 3.

    Eric.


    Originally posted in cdnusers.org by evenditti
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    1. create_clock is in an SDC file, called by another TCL script, using "read_sdc".
    2. and 3. are in the TCL script, after the read_sdc call.

    after external_delay, I have applied dc::set_input_delay again, RC tells me that external_delay is removed.
    Are both commands equivalent, ie. "dc::set_input_delay" and "external_delay"?



    Originally posted in cdnusers.org by sporadic crash
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    external_delay is equivalent to both dc::set_input_delay and dc::set_output_delay. Your command sequence looks correct, not sure what the problem is without seeing all the data. If you have access to Cadence Support, send in the data.


    Originally posted in cdnusers.org by synthman
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    Hi Eric, I have read all the postings and have read your last sentence in one of your previous postings again: "...for example if you input delay use clk_design and you have a path_group -from clk_design -to clk_design you will also have your input to clk_design in that group." That means RC covers this path. I am not at my desk now, but will check it as soon as possible. Then that means when I define cost_group for a clock domain, then I do not need to define -from "external_port" to a clock domain. I am using this tool for my first time, but it is pretty similar to Xilinx constraint mechanism. However RC is more "intelligent" about assigning clock domains. I will return you when I get news things.


    Originally posted in cdnusers.org by sporadic crash
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    Hi,
    You can try the following:

    include load_etc.tcl
    define_cost_group -name I2C -design $DESIGN
    path_group -from [all::all_inps] -to [all::all_seqs] -group I2C -name I2C
    foreach cg [find / -cost_group *] {
    report timing -cost_group $cg >> $RPT_NAME
    }

    It creates path group from all inputs to registers, sampling the data from the inputs.
    The clock and input delays should be defined before.


    Originally posted in cdnusers.org by Stalker
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    I think

    path_group -from [all::all_inps] -to [all::all_seqs] -group I2C -name I2C

    is an overkill in a multi-milliongate design, because RTL Compiler by default definition will try to analye "all flipflops" in the design, which costs a lot of runtime.

    IMHO, the clock domains must be grouped separately.


    Originally posted in cdnusers.org by sporadic crash
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    Hi,

    I have found the reason, why I don't see that any path found for the port I have selected.

    It has to do with that I have unknowingly set a "default" input delay just before the corresponding set_input_delay, which takes the port to another clock domain.

    Therefore the second dc::set_input_delay does not take the port to another clock domain, unless the previous is removed. Therefore RTL Compiler does not find a path between the port and the clock domain I wanted, unless there is no "dc::set_input_delay" defined for the clock domain.

    Thanks folks. your messages helped me a lot. Especially Eric's email.


    Originally posted in cdnusers.org by sporadic crash
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
<

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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information