Add support for `techlef` `SpacingRange` feature

[mithro]

The GF180MCU PDK has the SpacingRange features (?) in its techlef file. It would be good for the OpenROAD tooling to support this.

See report from @kareefardi @ https://github.com/RTimothyEdwards/open_pdks/issues/277

[rovinski]

The related rule appears to be here:

LAYER Metal1
    # ...

    MINWIDTH 0.230 ;                   # Mn.1  (n=1)
    WIDTH 0.230 ;                      # Mn.1  (n=1)
    SPACING 0.230  ;                   # Mn.2a (n=1)
    SPACING 0.300 RANGE 10.005 999.00 ; # Mn.2b

    # ...
END Metal1

This will very rarely if ever impact DRT correctness because it only applies to metals with width > 10.005 um, which is way out of range of the 0.230 um default width.

That being said, since we support spacing tables, I don't think this should be too difficult to implement?

[maliberty]

This is only going to be relevant for pdngen @arlpetergadfort

[rovinski]

@maliberty the warning about not being supported is in DRT:

https://github.com/The-OpenROAD-Project/OpenROAD/blob/5140e61103f7c01ccad05718f746fc598c0581bb/src/drt/src/io/io.cpp#L1633-L1634

[gadfort]

@maliberty if it's implemented in https://github.com/The-OpenROAD-Project/OpenROAD/blob/bbf00fa504cb847866c9f91d641a4a0ad53f45ed/src/odb/include/odb/db.h#L7032 PDNGEN would honor it.

[maliberty]

I don't think this represents a real barrier to gf180 bring up. PDN supports it and drt will only hit it with some extreme NDR of the sort we never use. I'll leave it open but as a low priority.

[vijayank88]

As GF180 implemented with OpenROAD flow, is the issue still relevant?

[maliberty]

We still don't support it in drt but I don't think this will ever get to the top of the priority list.