`place_pins` does not place pins directly between macro pins and boundary in some cases

[mole99]

Describe the bug

This problem actually occurs with a design in OpenLane 2, but since I can reproduce it standalone, I opted to file it as such.

The general idea is that the macros are placed close to the boundary, so that only the pins fit in between the macro pins and the boundary and therefore directly connect to the pins of the macros.

However, the pins that are inserted are slightly offset and don't touch the macro pins even though it should be possible to do so.

Expected Behavior

The pins are placed between the macro pins and the boundary so that they touch the macro pins.

Environment

I'm using OpenLane 2 which runs OpenROAD using Nix for the environment, so I'm not sure how to get the environment information easily. Please let me know if it's needed for this issue.

To Reproduce

ODB: eFPGA.zip

Open the provided ODB in the GUI and run the following commands:

set_pin_thick_multiplier -hor_multiplier 2 -ver_multiplier 2

set_pin_length -hor_length 0.48 -ver_length 0.48

place_pins -hor_layers Metal2 -ver_layers Metal3

After running the commands, you will see that all pins were placed successfully. But if you take a closer look at the pins inserted on the east or west side, they don't touch the macro pins but are slightly offset. It seems as if the pins avoid touching each other, even though they belong to the same net. Both pins are on-grid.

With a different design this strategy worked fine, but now that I've changed the geometry a bit, it has led to this issue.

Relevant log output

Found 126 macro blocks.
Using 2 tracks default min distance between IO pins.
[INFO PPL-0001] Number of slots           11580
[INFO PPL-0002] Number of I/O             1522
[INFO PPL-0003] Number of I/O w/sink      1522
[INFO PPL-0004] Number of I/O w/o sink    0
[INFO PPL-0005] Slots per section         200
[INFO PPL-0008] Successfully assigned pins to sections.
[INFO PPL-0012] I/O nets HPWL: 2767.64 um.

Screenshots

Additional Context

No response

[eder-matheus]

@mole99 The pin placer tool has a default min distance between pins of 2 routing tracks. The possible positions for having IO pins are calculated before placing them, and in your design, these positions were not aligned with the macro pins.

To ensure that the positions aligned with the macro pins will be considered, you can change the min distance between the pins by updating the place_pins command call: place_pins -hor_layers Metal2 -ver_layers Metal3 -min_distance 1 -min_distance_in_tracks

With this command, I was able to get the behavior you've described:

Let me know if it works for you or any other requests regarding this issue.

[mole99]

@eder-matheus Thanks so much for your reply!

Somehow I overlooked this peculiarity of the pin placer tool. After I changed the minimum spacing to a single track, the pins are now successfully placed! It seems that in a previous run the pins of the macro happened to be aligned with the default pin placement grid, so I didn't have the issue then.

Thanks again for the help!

[mole99]

So I've been playing around with different fabric sizes, and this time I may have actually found an issue. All pins are placed as expected, except for 6 pins in the bottom right corner. Instead of being directly aligned with the macro pins, they are packed tightly together in seemingly random order.

To reproduce, same as before, load the ODB (eFPGA.zip) in the GUI and run (this time with min_distance):

set_pin_thick_multiplier -hor_multiplier 2 -ver_multiplier 2

set_pin_length -hor_length 0.48 -ver_length 0.48

place_pins -hor_layers Metal2 -ver_layers Metal3 -min_distance 1 -min_distance_in_tracks

Perhaps @eder-matheus you could take a quick look to confirm whether it's a real bug and we can reopen the issue. I had a close look at the place_pins command, but couldn't find anything that explains this behavior. Thanks!

[maliberty]

Eder is on vacation next week but it looks real so I'll re-open and leave it for him when he returns.

[eder-matheus]

@mole99 I found an explanation for this behavior. It's not exactly a bug, it is more a product of the approach we implemented to assign the pins.

Before assigning the pins to their actual positions, we first assign them to a Section, which is a set of 200 possible positions. We perform this to deal with runtime issues with the hungarian matching solver. After assigning the pins to the sections, we then assign the pins to their real positions, according to the positions availiable inside each section. Check the figure below:

We use the center of each section to compute the cost of assigning a pin to a section. For the 6 pins that are placed in a non-optimal position, the center of the red section is closer to the pins connections than the center of the blue section. So it chooses the red section, and assign the pins to the positions inside it.

I will try to enhance this section assigning to have a better placement for the pins.

[maliberty]

@eder-matheus would using the annealer solve this too?

[eder-matheus]

@eder-matheus would using the annealer solve this too?

I've tried the annealer with some tuned parameters, and it is not aligning the IO pins with the macro pins for every case:

[maliberty]

For a simple two pin net like this we might want to just snap it into alignment if possible

[mole99]

Thanks for taking a look at this and the detailed explanation for the behavior!