Using dont_touch to keep a buffer

[povik]

In issue 8229 I advised @mole99 to insert a buffer in the incoming netlist and mark it dont_touch to prevent its removal by the resizer.

  (* dont_touch *)
  gf180mcu_fd_sc_mcu7t5v0__buf_1 buf_rst_n (
    .I(rst_n_PAD2CORE),
    .Z(\i_chip_core.rst_n )
  );

As it turned out that also makes the buffer be ignored in global connections.

WARNING [ODB-0383] buf_rst_n is marked do not touch and will be skipped in global connections.

dont_touch looks too strong here. Should we support a keep or dont_resize attribute which is weaker?

[povik]

@gadfort @maliberty do you have any opinions here?

[povik]

I have updated the question. I said "this use case" without defining what the use case is. I'm wondering about an attribute which would make the instantation of a standard cell be handled similarly to a macro: not being removed or resized but still modified e.g. in global connections. I'm not sure how often people need this in practice or if other tools provide the same.

[mole99]

I think it would be valuable to be able to keep the dont_touch attribute during the whole flow, without having to remove and reapply it for certain commands.

This is important if you want to apply the dont_touch attribute solely through Verilog.
(Okay, you probably could save the dont_touch attribute for all cells, nets etc. and restore it afterwards, but I'm not sure if this is really necessary.)

Is there a reason why global connections has to ignore cells with dont_touch set?

Regarding the poor support of dont_touch, let's improve it over time :)
I think I found one such issue: #8642

[maliberty]

dont-touch means don't change any netlist connections and global connect is doing that. You could imagine you have the cell connected to a specific power supply and inadvertently it matches a global connect. That should be an error.

[mole99]

I see, that does make sense logically.

But then I'm wondering how the proprietary tools handle that? 🤔
If you set dont_touch as a Verilog attribute on a cell, do you also need to remove and re-apply the attribute throughout the flow? At least you need to global connect the stdcells, I think.

[gadfort]

dont_touch would imply that you handled the power connections in the RTL. Other tools have other flags to ensure the instance is not removed but allows for sizing changes. Right now our global connect is extremely aggressive and it would be good to adjust it's behavior to be more incremental instead of what it is currently doing

[povik]

As an alternative to dont_resize one can set/unset dont_touch around individual commands. Looking at the threads linked to by @mole99 there might be an issue with timing-driven placement which internally calls the resizer but marking instances dont_touch for placement will prevent them from getting placed.

[mole99]

@povik I posted an update at: librelane/librelane#695 (comment)

It seems that OpenROAD does place cells during GPL, even when dont_touch is set.

[maliberty]

dont-touch is different from placement status. dont-touch only refers to editing the netlist. If you want the cell to be immovable you would make it fixed.

[mole99]

Thanks for confirming that! This means that we can apply and remove the dont_touch attribute before/after GPL in LibreLane.

"dont-touch = refers to editing the netlist" is a good mnemonic

[maliberty]

Why does the instance need to be don't touch? If you are trying to manually enforce a max fanout=1 then the net should be don't touch not the instance.

[povik]

It looks like we don't import dont_touch on nets from Verilog, only instances

[maliberty]

We should fix that.

[mole99]

Hi @maliberty. I tried out your suggestion by manually setting the dont_touch attribute on the net.
It works fine - thanks for the tip!

[povik]

Was that through a set_dont_touch command? I'm asking to confirm if the import from Verilog is missing.

[mole99]

@povik Correct, that was through set_dont_touch.