WIREEXTENSION not considered

[juspertor]

In TLEF files for any layer a WIREEXTENSION can be set:

LAYER MET2
    TYPE ROUTING ;
    WIDTH 0.28 ;
    SPACING 0.28 ;
    WIREEXTENSION 0.19 ;
#   ...
END MET2

This should result in a DEF with a third coordinate in the NETS section on that layer when connecting a with a via:

- Node_37 ( I_21 A ) ( I_23 Q ) ( I_24 C ) 
  + ROUTED MET2 ( 13720 10920 ) ( 19320 10920 )
    NEW MET2 ( 19320 10920 ) ( 19320 15960 )
    NEW MET2 ( 19320 15960 ) ( 17640 15960 190 ) VIA1_Y_so
# ...

This is described in the DEF spec as: The routingPoints syntax is defined as follows: ( x y [extValue] ) { (x y [extValue] ) | viaName [orient]} ... extValue Specifies the amount by which the wire is extended past the endpoint of the segment. The extension value must be greater than or equal to 0 (zero). Default: Half the wire width

TritonRoute uses this extension value when connecting a net to a pin. The extension is set to zero. However, for layers that require this extension, the extValue is omitted.

This results in DRC violations of the resulting design.

[maliberty]

The current TR doesn't support wireextension. I guess this must be for an older tech as the ref says:

For 65nm and below, WIREEXTENSION is no longer recommended because it may generate some advance rule violations if wires and vias have different widths.

What is your urgency for this issue?

[juspertor]

I evaluate OpenROAD with several PDK I have access to. This issue pops up with the most recent version of the X-Fab XH018 process. After a brief review of other TLEF files, WIREEXTENSIONs are used in several other 180nm processes as well and I expect that these processes will be available for many years to come. A lot of mix-signal designs are currently developed with processes with this dimension.