What is the order of pins for get_ports?

[oharboe]

I'm using -group -order with set_io_constraints and I'm using the tcl snippet below to enumerate pins.

However, this brings up the question: what order does get_ports return pins in?

proc match_pins { regex } {
    set pins {}
    foreach pin [get_ports -regexp $regex] {
        lappend pins [get_property $pin name]
    }
    return $pins
}

[oharboe]

@nerriav FYI

[maliberty]

arbitrary order, no assumptions should be made

[oharboe]

So, if I want pins such as a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7], a[8], a[9], a[10], ..., then I need to sort the pins non-lexigraphically.

Note that the pins are sorted non-lexiographically today. Perhaps by the ordering from Verilog?

It would therefore be covenient to add to the API definition of get_ports that pins have a defined order.

I believe this change could amount to:

1. find out what the origin of the order today is. That is: no change to the code is actually necessary.
2. write a test that ensures that this ordering is retained
3. define it so in the documentation

Otherwise, in every io.tcl file, I need to add something like:

# Helper function to split a string into a list of strings and numbers
proc split {str} {
    set result {}
    foreach {all letters numbers} [regexp -all -inline {(\D*)(\d*)} $str] {
        if {$letters ne ""} {
            lappend result $letters
        }
        if {$numbers ne ""} {
            lappend result [expr {$numbers + 0}]  ;# Convert to integer
        }
    }
    return $result
}

# Custom comparison function
proc natural_compare {str1 str2} {
    set list1 [split $str1]
    set list2 [split $str2]
    set len [expr {min([llength $list1], [llength $list2])}]
    for {set i 0} {$i < $len} {incr i} {
        set part1 [lindex $list1 $i]
        set part2 [lindex $list2 $i]
        if {$part1 ne $part2} {
            if {[string is integer -strict $part1] && [string is integer -strict $part2]} {
                return [expr {$part1 - $part2}]
            } else {
                return [string compare $part1 $part2]
            }
        }
    }
    return [expr {[llength $list1] - [llength $list2]}]  ;# If all parts are equal, compare by length
}

set myList {abc[10] abc[1] abc[11] abc[0] abc[2] abc[3] abc[4] abc abc[5] abc[21]}

# Sort the list using the custom comparison function
set sortedList [lsort -command natural_compare $myList]

puts "Sorted List: $sortedList"

Result:

Sorted List: abc {abc[0]} {abc[1]} {abc[2]} {abc[3]} {abc[4]} {abc[5]} {abc[10]} {abc[11]} {abc[21]}

[maliberty]

The command comes from SDC and such an option would be non-standard and non-portable.

[oharboe]

So get_ports is from SDC, as I understand. I was not suggesting changing syntax, but defining the order of the returned pins in OpenROAD.

[oharboe]

mock-array-big was assuming ordering: The-OpenROAD-Project/OpenROAD-flow-scripts#1066

[maliberty]

Doing a sort of every usage would impose a performance penalty on all the uses that don't require sorting. Nor is it clear that the sort order we pick would always match your desired result.

I'm guessing this relates to ppl and not timing at all. Perhaps we should have some option in ppl to sort the pins given in a group?

[oharboe]

Worth pondering a bit. Perhaps a sort Tcl function made available would be adequate?

This decouples the set_io_constraints API from the question of sorting and if the user has special needs, they are likely to pick up on that they can write their own sorting function?

set_io_constraints ... -order -pin_names [sort_natural $pins]

[maliberty]

I'm fine to include sort_natural as a utility function in OR if people find it generally useful.

[oharboe]

In mock-array-big, I introduced a designs/asap7/mock-array-big/util.tcl function, which is shared between macros and top level of the design.

I'm thinking that a shared util.tcl function will be required for non-trivial designs anyway.

Perhaps it is sufficient to provide an example of this in mock-array-big for now?

I see this somewhat tying into how one would have a centralized method to calculate properties of macros and the top level design: manual placement of macros relative to eachother, sizes of macros calculated based on environment variables, etc.

The-OpenROAD-Project/OpenROAD-flow-scripts#1067