Stats

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

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
Parents

  • ...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
Reply

  • ...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
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.