rsz: Preserve port-backed ModNet names during buffer removal

[jhkim-pii]

Summary

• Preserve input/inout port-backed hierarchical ModNet names when removing timing-repair buffers.
• Prevent write_verilog from emitting kept-module boundary loads without a driver.

Problem

• BufRemTest3.HierInputPortNamePreservedAfterBufferRemoval reproduces the failure through the same insert/remove ECO APIs used by timing repair. The snippets below show the relevant Verilog at each operation.

1. Initial netlist

   module top (a, seed, out0, out1);
     input a;
     input seed;
     output out0;
     output out1;
     wire signal;
     Source source (.in(a), .out(signal));
     Sink sink (.seed(seed), .out0(out0), .out1(out1));
   endmodule
   
   module Sink (seed, out0, out1);
     input seed;
     Load0 load0 (.i(seed), .out(out0));
     Load1 load1 (.i(seed), .out(out1));
   endmodule

2. u_buf is inserted by Rebuffer.

   module top (a, seed, out0, out1);
     input a;
     input seed;
     output out0;
     output out1;
     wire signal;
     Source source (.in(a), .out(signal));
     Sink sink (.net(signal), .seed(seed), .out0(out0), .out1(out1));
   endmodule
   
   module Sink (net, seed, out0, out1);
     input net;
     input seed;
     wire load_net;
     BUF_X2 u_buf (.A(net), .Z(load_net));     // INSERTED BUFFER
     Load0 load0 (.i(load_net), .out(out0));   // Net name changes: seed -> load_net
     Load1 load1 (.i(load_net), .out(out1));
   endmodule

   • This intermediate netlist is correct: input port net drives u_buf, and load_net is driven by the buffer output.

3. u_buf is removed by remove_buffer. In the output verilog, the undriven net load_net remains.

   module Sink (net, seed, out0, out1);
     input net;
     input seed;
     wire load_net;
     Load0 load0 (.i(load_net), .out(out0));    // BUFFER u_buf is removed. But net name "load_net" remains  --> UNDRIVEN
     Load1 load1 (.i(load_net), .out(out1));
     // Missing: assign load_net = net;
   endmodule

• The net name should be seed instead of load_net.

Cause

• In the regression, when u_buf is removed, one of two nets (input net net and output net load_net) should survive.
• net is selected as the surviving net, but its corresponding ModNet name is renamed to load_net, which is wrong.
• removeBuffer() selects source/driver/out and its input-port ModNet net as the survivors, while sink/load_net and its ModNet load_net are removed.
• Because the surviving flat net is deeper, the old depth-based naming logic copies the shallower removed names to both survivors: sink/load_net to the flat net and load_net to the ModNet.
• After the ModNets are merged, the Sink.net ModBTerm remains connected but its surviving ModNet is renamed from net to load_net.
• write_verilog then declares input net, connects the loads to load_net, and emits no input-to-net assign, producing the undriven loads.

Solution

• Add dbModNet::isConnectedToInputPort() and isConnectedToOutputPort() to detect top-level BTerms and hierarchical ModBTerms, including inout/feedthrough directions.
• In Resizer::removeBuffer(), detect when the deeper surviving ModNet is connected to an input-capable port before applying the depth-based rename.
• Preserve that ModNet name instead of copying the removed output ModNet name. In the regression, the surviving ModNet therefore remains net and continues to represent Sink.net correctly.
• Copy the shallower flat-net name only when it remains represented after the ModNet merge. Since the removed ModNet owns sink/load_net in the regression, neither survivor adopts that name.

Related

• Fixes https://github.com/The-OpenROAD-Project-private/ascenium/issues/54

[gemini-code-assist]

Code Review

This pull request introduces isConnectedToInputPort() and isConnectedToOutputPort() helper methods to dbModNet to check for connections to input/output ports. These methods are utilized in the Resizer to correctly preserve input/inout port names during buffer removal, ensuring that write_verilog retains the necessary feedthrough assigns. A new unit test has also been added to verify this behavior. I have no feedback to provide.

[oharboe]

🥳

[jhkim-pii]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-08-31T04:03:38.987285Z	f6de0bc	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Breezy!

Reviewed commit: f6de0bc8c4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".