• 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. Digital Implementation
  3. Can CTS stop tracing on hierarchical module ports?

Stats

  • Locked Locked
  • Replies 20
  • Subscribers 90
  • Views 19610
  • 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

Can CTS stop tracing on hierarchical module ports?

archive
archive over 17 years ago

Dear community,

my clock signal is connected to the clock network on the one hand. On the other hand it is connected to a module's input. Within this module the signal is always used as a data signal (chip is switched to different mode of operation for this).

This module contains logic, therefore CTS traces through the input ports. AFAIK tracing can only stop at top level ports or leaf cell pins.

Is there any way to make CTS stop tracing at the module's input port (like ExcludedPin/ExcludedPort - which don't work)?

Many thanks in advance for your suggestions!


Originally posted in cdnusers.org by agruebl
  • Cancel
  • archive
    archive over 17 years ago

    Bob:

    I just attended the SOC-E 71 Release seminar. It is great that you give a living example of how to use dbGet.
    Many Thanks!

    Best Regard


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

    ...and here's my solution. I've done it with Sy****ys-TCL and this code is called directly after Synthesis. A .ctsh file with a "special" format containing the hierarchical port definitions is parsed and the output is written to the .ctsh file used by CTS.

    set repl_trigger "REPLACE_"
    set rootpin      "AutoCTSRootPin"
    set infile [open $CTSINFILE]
    set outfile [open $CTSOUTFILE w]
    set data [read $infile]
    set lines [split $data \n]
    set replace false

    foreach port $lines {       
    # parse input lines
        set pstart [string range $port 0 7]
        if {$pstart == $repl_trigger} {       
    # the port definitions following this line will be replaced
            set replace true
            set out [string range $port 8 end]
            set outtype $out
            if {$out != $rootpin} {       
    # the RootPin needs to be defined in the same line as the according statement...
                puts $outfile $out
            }
        } elseif {$replace == true && [string index $port 0] == "+"} { 
    # replace port name with pin name(s)
            set aport [string range $port 3 end]
            if {[string index $port 1] == "i"} {       
    # replace input leaf pin names
                set inpins [get_pins -filter "@pin_direction == in" -hierarchical [all_connected [get_nets $aport]]]
                set prefix "+ "
            } else {       
    # replace output pin names
                set inpins [get_pins -filter "@pin_direction == out" -hierarchical [all_connected [get_nets $aport]]]
                if {$outtype == $rootpin} {
                    set prefix "$rootpin\t\t"
                } else {
                    set prefix "+ "
                }
            }
            if {[get_object_name [get_nets $aport]] != ""} {
                foreach_in_collection pin $inpins {
                    set out "$prefix[get_object_name $pin]"
                    puts $outfile $out
                }
            }
        } else {       
    # line not relevent - forward to output
            set replace false
            puts $outfile $port
        }
    }

    As all regular code in the input .ctsh file is forwarded to the output file, hier. port definitions and correct pin definitions can be mixed. :-)


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

    Thanks for all

    This info gave me a lot of new things about CTS


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

    hi eminemshow
    please can you tell me the difference between clock buffers and normal buffers


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

    Posted By mahecadence on 11/20/2007 4:00 AM
    hi eminemshow
    please can you tell me the difference between clock buffers and normal buffers
    I think the main difference is that clock buffer & inverter have nearly equal rising & falling delay.


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

    Thanks


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

    Many Thanks


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

    Many Thanks to


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

    many thanks eminemshow, can you explain me this by an examle


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

    without equal rise/fall delay, the duty cycle (started with 50/50) will get distorted going thru the unbalance buffer. It should bot affect the flops operation which trigger off the rising edge but some ram designs trigger off the falling edge. Inverter can slef-correct the unbalance rise/fall due to it inverted nature. So inverter is a better choice to use in a clock tree to prevent duty cycle distortion.

    li siang


    Originally posted in cdnusers.org by lisiang
    • 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