analog IP power pins connection to pdn

[passant5]

Description

Hello, I am trying to connect an analog IP power pins on met2 and met4 with the power grid on met4 and met5. I am facing the following issues:

• The required vias are not generated for all the IP power nets overlapping with the pdn
• When I use add_pdn_connect with met2 and met4 layers, if the stripe overlaps with the net close to the IP edge, they're not connected. However, if the stripe is a bit away from the edge, they're connected. If there are multiple stripes that overlap, only the first one is connected. This issue is demonstrated in issue_reproducible_AIP_pdn_connect_met_2_4.tar.gz
• When I add add_pdn_connect with met2 and met5 layers, the previously connected stripe on met4 is no longer connected. As well, the stripes on met5 don't connect at all. This issue is demonstrated in issue_reproducible_AIP_pdn_connect_met_2_5.tar.gz

Environment

python3 ./env.py issue-survey
Kernel: Linux v4.19.0-21-cloud-amd64
Distribution: debian 10
Python: v3.7.3 (OK)
Container Engine: docker v20.10.8 (OK)
OpenLane Git Version: c0be54349f857783492bc45a3e714eb9676e4e41
pip: INSTALLED
python-venv: INSTALLED
---
PDK Version Verification Status: OK
---
Git Log (Last 3 Commits)

c0be543 2022-08-16T16:47:08+02:00 Update OpenROAD (#1267) - Mohamed Gaber -  (HEAD, tag: 2022.08.17)
7b15116 2022-08-15T18:27:17+02:00 Revamp Net Unbuffering (#1261) - Mohamed Gaber -  (tag: 2022.08.16)
6ab944b 2022-08-09T14:51:35+02:00 IR Drop Reports in the Signoff Stage (#1255) - Mohamed Gaber -  (tag: 2022.08.10)
---
Git Remotes

origin	[email protected]:The-OpenROAD-Project/OpenLane.git (fetch)
origin	[email protected]:The-OpenROAD-Project/OpenLane.git (push)

Reproduction Material

issue_reproducible_AIP_pdn_connect_met_2_4.tar.gz

issue_reproducible_AIP_pdn_connect_met_2_5.tar.gz

Expected behavior

Power grid nets overlapping with IP pins/nets should be connected during the power grid generation by generating the required vias.

[donn]

@maliberty Hi- Passant is one of our chip designers and I can't make heads or tails of the PDN script, would you mind taking a look at this?

[maliberty]

What are the names of the analog pins in question?

[passant5]

@maliberty The power supply pins; VDD VSS DVDD DVSS

[maliberty]

why are there pins outside of the block boundary?

[maliberty]

[maliberty]

@arlpetergadfort if you have any thoughts

[passant5]

The source layout has the pins at the boundary, but I extended them a bit outside the boundary when the pdn connections didn't work. I thought avoiding having the stripes go over the block might help as well. note though that In the reproducible, the pins are extended far more than needed for demonstration purposes.

[gadfort]

@arlpetergadfort if you have any thoughts

@passantih @maliberty I've only looked at it for a few moments, but some thoughts:

1. The macro connect statements need to specify connecting from met2 -> met4, met2 -> met5, etc (each combination).
2. It's possible the vias are getting removed because they are not inside the macro (thats going to take a bit of tracking down).

I probably wont have time until tomorrow afternoon to look at this in more detail.

In short, there is no reason PDNGEN shouldn't be able to connect, but there is something (either setup or PDNGEN itself, or both) that is getting in the way.

[armleo]

Can you post the full design including verilog if possible?

[kareefardi]

can I ask why do you need the full design ?

[passant5]

@arlpetergadfort Hii, I wanted to ask, did you get a chance to take a second look at this? thanks

[armleo]

can I ask why do you need the full design ?

I suspect that it is simply missing connection between the top level power net and the IP.

[kareefardi]

but the verilog isn't a factor here, as far as i know. openroad reads a def/lef and pdn commands file and these are the things that affect pdn output in this test case.

[armleo]

but the verilog isn't a factor here, as far as i know. openroad reads a def/lef and pdn commands file and these are the things that affect pdn output in this test case.

nvm, I realized that there is two files. One of pdn.tcl that adds the needed connections.

[gadfort]

@passantih I forgot about this.

It's not an ideal macro to connect to. But if you add a ring around the macro itself you can connect the pins to that, which PDNGen can then connect to the overall grid, see below:

define_pdn_grid \
    -name wrapper_grid \
    -starts_with POWER \
    -voltage_domain CORE \
    -pins "$::env(FP_PDN_LOWER_LAYER) $::env(FP_PDN_UPPER_LAYER)"

# Adds the core ring if enabled.
if { $::env(FP_PDN_CORE_RING) == 1 } {
    add_pdn_ring \
        -grid wrapper_grid \
        -layers "$::env(FP_PDN_LOWER_LAYER) $::env(FP_PDN_UPPER_LAYER)" \
        -widths "$::env(FP_PDN_CORE_RING_VWIDTH) $::env(FP_PDN_CORE_RING_HWIDTH)" \
        -spacings "$::env(FP_PDN_CORE_RING_VSPACING) $::env(FP_PDN_CORE_RING_HSPACING)" \
        -core_offset "$::env(FP_PDN_CORE_RING_VOFFSET) $::env(FP_PDN_CORE_RING_HOFFSET)"
}
add_pdn_stripe -grid wrapper_grid -layer met5 -width 1.6 -spacing 1.6 -pitch 20 -offset 20 -extend_to_core_ring
add_pdn_connect -grid wrapper_grid -layers "met4 met5"

define_pdn_grid \
    -macro \
    -default \
    -name macro \
    -starts_with POWER \
    -halo "$::env(FP_PDN_HORIZONTAL_HALO) $::env(FP_PDN_VERTICAL_HALO)"

add_pdn_ring \
	-grid macro \
  -layers "met3 met4" \
  -widths "1 1.2" \
  -spacings "0.5 0.5" \
  -core_offset "1 1"

add_pdn_connect -grid macro -layers "met3 met4"
add_pdn_connect -grid macro -layers "met3 met2"
add_pdn_connect -grid macro -layers "met2 met4"
add_pdn_connect -grid macro -layers "met2 met5"
add_pdn_connect -grid macro -layers "met4 met5"

[kareefardi]

how is this not an ideal macros to connect to? the macro has power pins and there are stripes inserted by pdn that pass through the macro's pin and pdn doesn't insert vias to connect the pin with the stripes. add_pdn_connect statements are provided for connections between the pin and the stripe.

i don't see how the above proposal addresses this specific issue.

[gadfort]

@kareefardi The pins extend pretty far outside the macro and has pins on met2 on multiple edges. These are both conditions PDNGEN isn't used to. The above code connects the to the macro and connects to the rings around the core. I think there is room to discuss what additional features would make sense to add to PDNGEN to make this easier (I'm open to suggestions), but the combination of halos and pins outside the macro makes things a little unusual for PDNGEN.