@User do you know why the resizer doesn't attempt to fix fanout issues (eg repairMaxFanout)? It looks like the code is disabled

commented out where in OR or ORFS?

@User OpenROAD. There are a chunk of functions in

src/rsz/src/Unused.cc

# git grep repair_max_fanout_cmd
src/rsz/src/Unused.cc:repair_max_fanout_cmd(LibertyCell *buffer_cell)

repair_design handles max_fanout now

@User Ok, let me work out why it isn't. Am I right in thinking

set_max_fanout 5.0000 [current_design]

Sets a max fanout for every net in the design?

it seems that way

Ok, let me dig into it. FYI I'm trying to understand why my design has a lot of nets with quite high max slew violations:

Pin                                    Limit    Slew   Slack
------------------------------------------------------------
U$$545/B2                               1.50    4.35   -2.85 (VIOLATED)
U$$543/B2                               1.50    4.35   -2.85 (VIOLATED)
...

I'm not sure if current_design would work as but hopefully. @User may know better

1. The net has quite a lot on it. That's why I started looking at the max fanout setting:

- sel_1$4647 ( U$$545 B2 ) ( U$$543 B2 ) ( U$$541 B2 ) ( U$$539 B2 ) ( U$$537 B2 ) ( U$$535 B2 ) ( U$$533 B2 )
      ( U$$531 B2 ) ( U$$529 B2 ) ( U$$527 B2 ) ( U$$525 B2 ) ( U$$523 B2 ) ( U$$521 B2 ) ( U$$519 B2 ) ( U$$517 B2 )
      ( U$$515 B2 ) ( U$$513 B2 ) ( U$$511 B2 ) ( U$$509 B2 ) ( U$$507 B2 ) ( U$$505 B2 ) ( U$$503 B2 ) ( U$$501 B2 )
      ( U$$499 B2 ) ( U$$497 B2 ) ( U$$495 B2 ) ( U$$493 B2 ) ( U$$491 B2 ) ( U$$489 B2 ) ( U$$487 B2 ) ( U$$485 B2 )
      ( U$$483 B2 ) ( U$$481 B2 ) ( U$$479 B2 ) ( U$$477 B2 ) ( U$$475 B2 ) ( U$$473 B2 ) ( U$$471 B2 ) ( U$$469 B2 )
      ( U$$467 B2 ) ( U$$465 B2 ) ( U$$463 B2 ) ( U$$461 B2 ) ( U$$459 B2 ) ( U$$457 B2 ) ( U$$455 B2 ) ( U$$453 B2 )
      ( U$$451 B2 ) ( U$$449 B2 ) ( U$$447 B2 ) ( U$$445 B2 ) ( U$$443 B2 ) ( U$$441 B2 ) ( U$$439 B2 ) ( U$$437 B2 )
      ( U$$435 B2 ) ( U$$433 B2 ) ( U$$431 B2 ) ( U$$429 B2 ) ( U$$427 B2 ) ( U$$425 B2 ) ( U$$423 B2 ) ( U$$421 B2 )
      ( U$$419 B2 ) ( U$$417 B2 ) ( U$$416 X ) + USE SIGNAL ;

I'm looking at https://github.com/The-OpenROAD-Project/OpenROAD/issues/1702 which seems to relate to macro pins with a tight max slew

Having said that, we see no max slew violations even when I add a stage to fix slew violations after global routing

that seems different

Current design returns a module not nets. Instead do get_nets -hier *

I also note that the global routes and the detailed routes closely match, so it's not due to a difference there

@User the doc says ports or cells rather than nets

Oh actually, it does take a fairly different route on the top right

Then get_pins -of_object [get_nets -hier *]

set_max_fanout

doesnt seem to like either nets or pins

maybe try cells instead

Like this?

>>> set_max_fanout 5 [ get_cells -of_object [get_nets -hier *] ]
... 
... 
[ERROR STA-0467] unsupported object type Instance.
[ERROR GUI-0070] STA-0467

get_cells -hier *

Ahh yes makes sense. Doesn't seem to work either:

>>> set_max_fanout 5 [ get_cells -hier * ]
[ERROR STA-0467] unsupported object type Instance.
[ERROR GUI-0070] STA-0467

I'm guess a bit but maybe get_lib_cells * ?

@User makes sense, I did see some documentation that said set_max_fanout could apply to liberty cells. Didn't seem to work, perhaps because we only expect cells and ports:

proc set_fanout_limit { fanout min_max objects } {
  check_positive_float "limit" $fanout
  parse_cell_port_args $objects cells ports

I think it only wants leaf instances so maybe: set_max_fanout 5 [get_cells]