Do not write physical-only cells in the output verilog file

[openroad-ci]

• Modified DbInstanceChildIterator to iterate through logical cells (exclude physical-only cells).
• This makes STA not traverse physical-only cells.
• In the output .v, there will be no physical-only cells.

Fixes #8254

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[gadfort]

@maliberty any concerns is changes power or other metrics? Write verilog already has an option to remove cells from the netlist.

[maliberty]

@jhkim-pii please run a small design with and without this change and compare for the concerns above.

@gadfort I don't think we'll have Liberty files for physical only cells like tapcell or fillers so I don't expect it to affect power (still good to check).

[gadfort]

@maliberty I would imagine it would effect leakage power only. If you mock the liberty file to ensure there is enough leakage power that it would be noticable.

An alternative would be to add the ability to selectively preserve the old behavior.

[maliberty]

@gadfort do you have an actual case where it matters or is this theoretical?

[jhkim-pii]

I checked the fix in ORFS.
There was no metadata check fail (no notable QoR change).
Let me check if there are small differences in any metrics.

Preserving the old behavior looks good. Do you have any recommendation for the UI?

[gadfort]

@maliberty decap filler cells are physical only, but have leakage power

[maliberty]

@maliberty decap filler cells are physical only, but have leakage power

That is a fair point. @jhkim-pii perhaps we should leave sta seeing these cells in dbNetwork and just change ORFS to use -remove_cells to drop them from Verilog.

[jhkim-pii]

Sorry for sharing this result late.
I can see differences in the leakage power only, but they are trivial in ORFS.
Other key metrics are identical. Please refer to the below.

In the current ORFS designs, the leakage power delta is very small.
However, you may concern the bigger gate leakage power error from DECAP cells in advanced nodes. Am I correct?

Hmm... Open STA performs the leakage power calculation. Therefore, no matter how large, the leakage error exists.

---

ORFS dashboard - Base vs Test:
https://dashboard.precisioninno.com/compare?sourceAType=Commit&sourceBType=Commit&designs=aes%2Cgcd%2Ci2c-gpio-expander%2Cibex%2Cjpeg%2Criscv32i%2Cspi&sourceAName=33e29bff117562482f165cfbc499da0b9a7f4840&sourceAID=5983&sourceBName=e535cd04f669046929bc5636cd8cf6b12eef402b&sourceBID=2

ihp-sg13g2

• Trivial differences in the leakage

gf180

• Trivial differences in the leakage

asap7, nangate45, sky130hd, sky130hs

• No difference

nangate45 case

[jhkim-pii]

That is a fair point. @jhkim-pii perhaps we should leave sta seeing these cells in dbNetwork and just change ORFS to use -remove_cells to drop them from Verilog.

Hmm.. I don't know how to do this. How can we check the physical-only attribute with Tcl command?

[maliberty]

We know the classes of cells we want to exclude (fill, tap). Those cells are specified in variables that we can use.

[jhkim-pii]

Got it.
Discard this approach due to the leakage power error.

This is an alternative ORFS solution (it does not dump physical-only cells by write_verilog).
The-OpenROAD-Project/OpenROAD-flow-scripts#3480