The-OpenROAD-Project / OpenROAD-flow-scripts

OpenROAD's scripts implementing an RTL-to-GDS Flow. Documentation at https://openroad-flow-scripts.readthedocs.io/en/latest/
https://theopenroadproject.org/
Other
282 stars 262 forks source link

asap7/mock-array: switch manual macro placement for mpl2 flow #2059

Open AcKoucher opened 2 weeks ago

AcKoucher commented 2 weeks ago

Resolve #1928,

Using #2020 to test mpl2 flow for mock-array showed some metrics degradation in both timing and WL caused by a group of IOs placed in a different location than we see on master:

[ERROR] detailedroute__route__wirelength fail test: 76149.0 <= 73578.0
[ERROR] finish__timing__setup__ws fail test: -78.1376 >= -6.93
[ERROR] finish__timing__wns_percent_delay fail test: -49.411146 >= -10.0

When using manual macro placement, when we get to non-random pin placement stage in the flow, PPL has no information about the std cells position - because non of them are placed - so we luckily end up placing the problematic IO group in the center of the right boundary, because PPL uses as reference the center of the design when it finds no placed insts.

However, MPL2 does generate a temporary location for std cells in order to improve macros' orientations. These locations end up been seen by PPL which chooses a different position for the IO group changing upstream results leading to degradation.

A possible solution would be to not skip global placement without IOs when we have constraints for the pins as it is for mock-array. This way, PPL would have a better std cell location data to work with. Testing this showed that std cells get split based on the arrays' rows and so does the IO group (in the images zooming into the fourth row from bottom to top):

This improves WR and ws and we get no failures.

[INFO] detailedroute__route__wirelength pass test: 63606.0 <= 73578.0
[INFO] finish__timing__setup__ws pass test: 34.7588 >= -6.93
[INFO] finish__timing__wns_percent_delay pass test: 6.875599 >= -10.0

Master:

[INFO] detailedroute__route__wirelength pass test: 69582.0 <= 73578.0
[INFO] finish__timing__setup__ws pass test: 10.0482 >= -6.93
[INFO] finish__timing__wns_percent_delay pass test: 14.364462 >= -10.0
AcKoucher commented 2 weeks ago

@oharboe FYI

One additional thing: In this PR the halos generate the exact same macro placement as we'd get using manual macro placement (In your test PR there were some subtle differences). It was just a matter of using a more precise value. I made that to exclude the possibility of the macro placement to be the actual cause of the degradation we see in your test PR.

AcKoucher commented 2 weeks ago

@maliberty Is running a separate secure-ci for the global placement without IOs.

oharboe commented 2 weeks ago

I looked at the significant WNS regression:

[ERROR] finish__timing__setup__ws fail test: -91.4696 >= -6.93

io_lsbs_61 is a pipeliened signal from ces_7_5, i.e. top row that is driven all the way to the lower right corner with only a single flip flop for that entire path.

image

image

oharboe commented 2 weeks ago

On master, the iolsbs* pins are placed in the middle on the right, which improves WNS by ca. 100ps on a clock period of 250ps.

image

AcKoucher commented 2 weeks ago

@oharboe The changes here depend on not skipping global placement without IOs in the flow which is skipped on master for mock-array (we skip this stage when we have pin constraints). We'll need another PR for this skipping part. We're running a secure-ci for it separately, but there are some other issues regarding different designs which are being studied.