How does OpenROAD computes the number of possible locations for IO's ?

[lustefan97]

Hello,

I have a question to know how does OpenROAD computes the possible IO pin locations, when placed on the top-most metal layer. I use the ASAP7 PDK, I already routed a "hello world" design using the ibex core which has 264 IO pins. Now I want to test a bit the capabilities of OpenROAD and start doing increasingly bigger designs.

Right now I have a design that has 4100 IO pins to place on the top layer. The die size is 20um x 20um more or less which, since I want to place the IO's on the Pad Layer whose track pitch is 0.08um, would give me more or less 62 tracks on which I can place my pins (mind you I place the pins with a minimum width of 0.32um). The M9 metal layer also has a track pitch of 0.08, so I could think that I would also have 62 tracks on which I could have a pin routed (on top). This would give me 62 x 62 = 3844 potential pin locations with this die size, but the tool give me the following error :

[ERROR PPL-0024] Number of IO pins (4100) exceeds maximum number of available positions (788).

Which is far less than what I expect, so my questions are as follows :

1. How does OpenROAD compute those available positions ?
2. Could those locations be linked to an oversight/mistake in my synthesis script ?
3. If I am mistaken in the way to compute the "potential location", how does one compute it properly based of the design size (number of cells/die area) ?

[maliberty]

@eder-matheus please help

[rovinski]

I don't know how the pin capacity is calculated exactly, but I know that the pin placer only works on edges of the die, not across an area. The total pins on the top layer would be around the perimeter, i.e. 62 * 4 = 248.
But, usually PPL does not want to place pins on edges that do not correspond to the preferred direction of that layer. PAD layers may or may not have a preferred direction. The other pins in the 788 reported may be coming from other layers along the edge of the die.

But anyways, you are probably looking at the wrong tool. You want to be looking at the PAD tool which is meant for bump placement on flip-chip designs, which is much closer to what you are trying to do.

[lustefan97]

@rovinski The reason I used the PPL tool instead of the PAD tool is simply due to the fact that I didn't see anything related to Face-to-face 3D stacking in the PAD documentation. There is indeed the possibility to define a bump array, but no way to impose constraints on the placement regarding the layer on which the bump will be created (like with the define_pin_shape_pattern command), so I assumed that it was for bumps on the periphery (sides) of the die not on top of it.

Does it mean that the make_io_bump_array command automatically place the pins on the top layer and allow placement/wire length minimization/routing like the PPL tool does ? Doesn't it create a redundancy with the define_pin_shape_pattern command and the PPL tool then ?

EDIT : If the design I have doesn't have any pad, then I have to use PPL as per the flow documentation ? It is something to consider from the beginning, not only in OpenROAD flow's ? I tried to use make_io_bump_array and it was unable to find the "master"

[rovinski]

I didn't see anything related to Face-to-face 3D stacking in the PAD documentation.

There is nothing implicit about F2F that precludes you from using PAD for placing the bumps

There is indeed the possibility to define a bump array, but no way to impose constraints on the placement regarding the layer on which the bump will be created

Bumps are always on the top layer.

I assumed that it was for bumps on the periphery (sides) of the die not on top of it.

I'm not sure I follow, bumps are always on the top of the die.

Does it mean that the make_io_bump_array command automatically place the pins on the top layer

Yes

and allow placement/wire length minimization/routing like the PPL tool does ?

No. Bump maps are expected to be manually designed in coordination with the package, so there is no optimization. That being said, GPL will optimize for HPWL based on the constraints of the bumps.

Doesn't it create a redundancy with the define_pin_shape_pattern command and the PPL tool then ?

No

EDIT : If the design I have doesn't have any pad, then I have to use PPL as per the flow documentation ?

I think you would use the bump placement but not the pad placement. This isn't the intended flow for PAD nor for PPL so neither of them will be perfect solutions. But I believe PAD should get you closer.

I tried to use make_io_bump_array and it was unable to find the "master"

Bumps are always provided in cells which are instantiated. If you are modeling a F2F flow, then you should either have a bump, pad, TSV, or some other kind of connection which is modeled as a cell with LEF. This is generally either an octagon (if large) or square (if small) patch of metal.

Overall I think this is something the team is interested in implementing, likely as part of PPL, in the future to support 3D IC. But that is contingent on sponsors to support it.

[maliberty]

We support pins over the top of the core area through define_pin_shape_pattern. The number of pins locations will be determined by the region and the x/y step given. If you need to actually place bumps at specific locations that is different than pin placement. What is your goal?

[eder-matheus]

@lustefan97 Adding to Matt's comment, the pin placer tool also looks for routing obstructions and other existing objects in the top layer. So, if you have other geometries in the top layer, you will see a smaller number than you expected.

Could you also share your call for the define_pin_shape_pattern command?

[lustefan97]

I don't think that I have any other geometries on the top layer, I just synthesized an LDPC cell and put all its pins on top, the goal here being to see how the tools handle the routing to IOs or bumps on the top layer.

My call for define_pin_shape_pattern is as follows :

set io_placer_hor_layer M4
set io_placer_ver_layer M5
set x_pitch 0.32
set y_pitch 0.32
set top_pin_size {0.12 0.12}

define_pin_shape_pattern -layer $top_layer -x_step $x_pitch -y_step $y_pitch -region [ord::get_core_area] -size $top_pin_size
set_io_pin_constraint -pin_names * -region "up:*"
place_pins -random -hor_layers $io_placer_hor_layer -ver_layers $io_placer_ver_layer

This is not exactly how it is structured, but every relevant info is there. I just checked the core area using ord::get_core_area which gave me {1.026 1.08 19.17 19.17}, it may be too small with regard to the true "final area" (I have warnings concerning a LEF master not found for some XOR and XNOR gates, I have to check this out since they are present in the LEF file for asap7) but still, if x/y_pitch are given in micron like the core area this should give me :

For the x axis : 19.17 - 1.026 = 18.144 => 18.144 / 0.32 = floor(56.7) = 56 tracks
For the y axis : 19.17 - 1.08 = 18.09 => 18.09 / 0.32 = floor(56.53) = 56 tracks

Which in total give me 56*56 = 3136 locations expected...

Note that in the place_pins command the -hor_layers and -ver_layers are both said to be optional in the documentation (29th September 2023) as they are in brackets, yet when I remove them from the command I get an error saying that they are required
([ERROR PPL-0017] -hor_layers is required). Those argument do have an influence as I tried to change M4/M5 to M8/M9 to see what would happen and the number of potential location dropped to 456, I may be a few commit behind if it has been changed recently.

[eder-matheus]

@lustefan97 I found out why you're seeing fewer available positions. In the check of #pins against #positions, we only compare with the number of positions in the die boundaries and do not compare with the top layer slots. The reported #positions in the log also consider only the positions in the boundaries.

I'll update this check and the report.

[eder-matheus]

@lustefan97 I've created a PR to fix the check for pins in the top layer. You can find it here: #4071. I've also fixed the README with the correct mandatory parameters.

[lustefan97]

Perfect ! Thanks for your help !