PDN m4 stripes run through macro (if several macros are placed)

[hpretl]

Description

When integrating several hardened macros into caravel then the m4 vertical PDN straps run through some of the macros.

Expected Behavior

The m4 straps are cut where there is a hardened macro.

Environment report

Traceback (most recent call last):
  File "./env.py", line 265, in <module>
    main()
  File "./env.py", line 261, in main
    commands[args[0]]()
  File "./env.py", line 168, in issue_survey
    % get_tag()
  File "/foss/tools/openlane/2022.11/dependencies/get_tag.py", line 67, in get_tag
    raise e
  File "/foss/tools/openlane/2022.11/dependencies/get_tag.py", line 47, in get_tag
    raise NoGitException(
dependencies.get_tag.NoGitException: Cannot determine git branch. Please specify OPENLANE_IMAGE_NAME manually.
Full output: fatal: detected dubious ownership in repository at '/foss/tools/openlane/2022.11'
To add an exception for this directory, call:

    git config --global --add safe.directory /foss/tools/openlane/2022.11

Reproduction material

I am using OpenLane 2022.11.25 and its dependencies.

Relevant log output

The error only pops up during the LVS stage, when there is an LVS mismatch displayed. Reviewing the resulting GDS shows the error of the `m4` PDN straps causing shorts.

[hpretl]

This is how it looks like.

[hpretl]

All macros that are placed are hardened with OpenLane version 2022.11.25

[maliberty]

@arlpetergadfort thoughts?

[maliberty]

Does your macro have an OBS on met4?

[hpretl]

No. The OL flow apparently only puts the OBS in where there are tracks, and not across the full macro. See here the relevant section of tempsense.lef (that is the smaller macro placed at the corners):

 OBS
      LAYER li1 ;
        RECT 5.520 10.795 144.440 138.805 ;
      LAYER met1 ;
        RECT 5.520 10.640 144.440 138.960 ;
      LAYER met2 ;
        RECT 7.450 4.280 142.500 141.965 ;
        RECT 7.450 4.000 18.670 4.280 ;
        RECT 19.510 4.000 55.930 4.280 ;
        RECT 56.770 4.000 93.190 4.280 ;
        RECT 94.030 4.000 130.450 4.280 ;
        RECT 131.290 4.000 142.500 4.280 ;
      LAYER met3 ;
        RECT 4.000 141.080 145.600 141.945 ;
        RECT 4.000 136.360 146.000 141.080 ;
        RECT 4.400 134.960 146.000 136.360 ;
        RECT 4.000 130.240 146.000 134.960 ;
        RECT 4.000 128.840 145.600 130.240 ;
        RECT 4.000 118.000 146.000 128.840 ;
        RECT 4.000 116.600 145.600 118.000 ;
        RECT 4.000 111.880 146.000 116.600 ;
        RECT 4.400 110.480 146.000 111.880 ;
        RECT 4.000 105.760 146.000 110.480 ;
        RECT 4.000 104.360 145.600 105.760 ;
        RECT 4.000 93.520 146.000 104.360 ;
        RECT 4.000 92.120 145.600 93.520 ;
        RECT 4.000 87.400 146.000 92.120 ;
        RECT 4.400 86.000 146.000 87.400 ;
        RECT 4.000 81.280 146.000 86.000 ;
        RECT 4.000 79.880 145.600 81.280 ;
        RECT 4.000 69.040 146.000 79.880 ;
        RECT 4.000 67.640 145.600 69.040 ;
        RECT 4.000 62.920 146.000 67.640 ;
        RECT 4.400 61.520 146.000 62.920 ;
        RECT 4.000 56.800 146.000 61.520 ;
        RECT 4.000 55.400 145.600 56.800 ;
        RECT 4.000 44.560 146.000 55.400 ;
        RECT 4.000 43.160 145.600 44.560 ;
        RECT 4.000 38.440 146.000 43.160 ;
        RECT 4.400 37.040 146.000 38.440 ;
        RECT 4.000 32.320 146.000 37.040 ;
        RECT 4.000 30.920 145.600 32.320 ;
        RECT 4.000 20.080 146.000 30.920 ;
        RECT 4.000 18.680 145.600 20.080 ;
        RECT 4.000 13.960 146.000 18.680 ;
        RECT 4.400 12.560 146.000 13.960 ;
        RECT 4.000 7.840 146.000 12.560 ;
        RECT 4.000 6.975 145.600 7.840 ;
  END

[maliberty]

If there is no OBS then pdngen is free to put stripes across your macro.

I'm not sure what you mean by "where there are tracks". Wouldn't you have routing tracks on metal4? Or do you mean actual routing as opposed to tracks?

[hpretl]

Take an example from the other small macro config_reg_mux.lef: There is one small routing on m4, and this gets an OBS. If the intention is that a macro should get an OBS across the whole macro (as is done on li1 and met1) then something needs to be changed. I am using stock OL.

 OBS
      LAYER li1 ;
        RECT 5.520 10.795 294.400 288.405 ;
      LAYER met1 ;
        RECT 3.290 8.880 298.010 289.640 ;
      LAYER met2 ;
        RECT 3.320 295.720 9.010 296.000 ;
        RECT 9.850 295.720 14.990 296.000 ;
        RECT 15.830 295.720 20.970 296.000 ;
        <snip>
  LAYER met3 ;
        RECT 4.000 294.080 295.600 294.945 ;
        RECT 4.000 291.400 296.000 294.080 ;
        RECT 4.000 290.000 295.600 291.400 ;
        <snip>
    LAYER met4 ;
        RECT 283.655 18.535 284.905 200.425 ;

[maliberty]

I'm not clear why it is a problem that the rail crosses your block if you aren't using m4.

[hpretl]

Good question, so I checked, here the macro tempsense: It has m4 in the local PDN, but nothing on OBS in the LEF. So this causes shorts with the PDN above:

[hpretl]

So here is tempsense.lef in klayout, here the layers are better to see: There are tracks on met4, but no OBS:

[hpretl]

On a larger macro, the met4.OBS is put in (same OpenLane, similar config.json). Can it be that there is an issue on smaller macros?

[hpretl]

Here is the config.json of the larger macro where met4.OBS is correctly in the LEF:

{
    "DESIGN_NAME": "audiodac",
    "DESIGN_IS_CORE": 0,
    "VERILOG_FILES": ["dir::../../verilog/rtl/defines.v", "dir::../../verilog/rtl/audiodac.v", "dir::../../verilog/rtl/audiodac_dsmod.v", "dir::../../verilog/rtl/audiodac_fifo.v", "dir::../../verilog/rtl/audiodac_sinegen.v"],
    "CLOCK_PERIOD": 50,
    "CLOCK_PORT": "clk_i",
    "CLOCK_NET": "clk_i",
    "FP_SIZING": "relative",
    "ROUTING_CORES": 8,
    "FP_PIN_ORDER_CFG": "dir::pin_order.cfg",
    "PL_BASIC_PLACEMENT": 0,
    "PL_TARGET_DENSITY": 0.30,
    "VDD_NETS": ["vccd1"],
    "GND_NETS": ["vssd1"],
    "DIODE_INSERTION_STRATEGY": 4,
    "RUN_CVC": 1,
    "pdk::sky130*": {
        "FP_CORE_UTIL": 25,
        "RT_MAX_LAYER": "met4",
        "scl::sky130_fd_sc_hd": {
            "CLOCK_PERIOD": 50
        },
        "scl::sky130_fd_sc_hdll": {
            "CLOCK_PERIOD": 50
        },
        "scl::sky130_fd_sc_hs": {
            "CLOCK_PERIOD": 50
        },
        "scl::sky130_fd_sc_ls": {
            "CLOCK_PERIOD": 50,
            "SYNTH_MAX_FANOUT": 5
        },
        "scl::sky130_fd_sc_ms": {
            "CLOCK_PERIOD": 50
        }
    },
    "pdk::gf180mcuC": {
        "STD_CELL_LIBRARY": "gf180mcu_fd_sc_mcu7t5v0",
        "CLOCK_PERIOD": 50,
        "FP_CORE_UTIL": 25,
        "RT_MAX_LAYER": "Metal4",
        "SYNTH_MAX_FANOUT": 4,
        "PL_TARGET_DENSITY": 0.30
    }
}

[hpretl]

Here is the config.json of the smaller macro where met4.OBS is missing in the LEF:

{
    "DESIGN_NAME": "config_reg_mux",
    "DESIGN_IS_CORE": 0,
    "VERILOG_FILES": ["dir::../../verilog/rtl/defines.v", "dir::../../verilog/rtl/config_reg_mux.v"],
    "CLOCK_PERIOD": 50,
    "CLOCK_PORT": "clk_i",
    "CLOCK_NET": "clk_i",
    "FP_SIZING": "absolute",
    "DIE_AREA": "0 0 300 300",
    "ROUTING_CORES": 8,
    "FP_PIN_ORDER_CFG": "dir::pin_order.cfg",
    "PL_BASIC_PLACEMENT": 0,
    "PL_TARGET_DENSITY": 0.20,
    "VDD_NETS": ["vccd1"],
    "GND_NETS": ["vssd1"],
    "DIODE_INSERTION_STRATEGY": 4,
    "RUN_CVC": 1,
    "pdk::sky130*": {
        "FP_CORE_UTIL": 10,
        "RT_MAX_LAYER": "met4",
        "scl::sky130_fd_sc_hd": {
            "CLOCK_PERIOD": 50
        },
        "scl::sky130_fd_sc_hdll": {
            "CLOCK_PERIOD": 50
        },
        "scl::sky130_fd_sc_hs": {
            "CLOCK_PERIOD": 50
        },
        "scl::sky130_fd_sc_ls": {
            "CLOCK_PERIOD": 50,
            "SYNTH_MAX_FANOUT": 5
        },
        "scl::sky130_fd_sc_ms": {
            "CLOCK_PERIOD": 50
        }
    },
    "pdk::gf180mcuC": {
        "STD_CELL_LIBRARY": "gf180mcu_fd_sc_mcu7t5v0",
        "CLOCK_PERIOD": 50,
        "FP_CORE_UTIL": 20,
        "RT_MAX_LAYER": "Metal4",
        "SYNTH_MAX_FANOUT": 4,
        "PL_TARGET_DENSITY": 0.20
    }
}

[maliberty]

So the problem here is not with pdngen but with whatever is generating your LEF. Is that OR or magic?

[hpretl]

Unfortunately, I don't know. It pops out of the OL flow at the end.

[hpretl]

A related question: So pdngen expects an OBS on met4, but why is it not taking any met4 structure in the LEF as an obstruction. Like merging met4 and met4.OBS into met.OBS to avoid routing through it.

[maliberty]

Do you have non-OBS met4 in your LEF?

[hpretl]

Yes, see example above. It is on the PIN layer, but I guess this is OK.

[maliberty]

You example previously only showed on shape

LAYER met4 ;
        RECT 283.655 18.535 284.905 200.425 ;

while your image shows many. It is getting hard to follow with multiple blocks and snippets.

[hpretl]

Yeah, sorry for the confusion! In summary:

• There are structures on met4.PIN but not on met4.OBS in small blocks.
• In larger blocks, there is a large structure on met4.OBS.

[maliberty]

@arlpetergadfort pin shapes should be avoided by pdngen, correct?

[antonblanchard]

So the problem here is not with pdngen but with whatever is generating your LEF. Is that OR or magic?

Openlane uses magic to create the LEF. By default it creates an abstract LEF, but you can use MAGIC_WRITE_FULL_LEF to disable this.

With the recent updates to the Openroad LEF generator, perhaps we should switch Openlane to it.

[maliberty]

@antonblanchard do you know why the results differ for various blocks?

[antonblanchard]

@antonblanchard do you know why the results differ for various blocks?

Could be a magic bug. @hpretl could you please attach def files for the two examples above (met4 OBS and no OBS)?

[gadfort]

@arlpetergadfort pin shapes should be avoided by pdngen, correct?

@maliberty yes it should. Unless it's connected to a net pdngen is trying to connect to.

[hpretl]

@antonblanchard Here you go, all the LEFs in questions:

ol_1522.tar.gz

[hpretl]

I manually copied the met1 OBS to met4 OBS in the LEFs of the blocks config_reg_mux and tempsense (just to block met4 completely), and then everything is good (proper PDN generation and connection, and LVS passes).

So the issue is either:

• The pdngen should consider met4 PIN together with the met4 OBS to stay clear of these with the power grid.
• Or the LEF generation should put proper met4 OBS into the LEF (like copying pin and routes into the OBS section).

What of this two is the root cause and the appropriate solution is beyond my means.

[antonblanchard]

@antonblanchard Here you go, all the LEFs in questions:

ol_1522.tar.gz

Thanks, but we need the defs so we can recreate the lefs

[hpretl]

Sorry, my bad! Here are the DEFs:

ol_1522_def.tar.gz

[kareefardi]

@arlpetergadfort pin shapes should be avoided by pdngen, correct?

I believe this is true too. It is not a lef generation issue as areas with no met4.drawing in it will not generate OBS. @hpretl If this is still happening can you provide the design files to recreate the short ?