Technology LEF files have incorrect CPERSQDIST

[RTimothyEdwards]

The technology LEF files (for both standard cell libraries) all have the same value for CPERSQDIST for all metal layers. Cross-checked against a commercial tool, it was found that the given value is not equal to the actual CPERSQDIST for any metal layer (in fact, it is off by a factor of about 10x for metal 3).

The correct value needs to be determined for every metal layer.

Currently, min and max corners are being generated by open_pdks by substitution on the tech lef in the repository, which is assumed to be nominal. But at least the correct nominal corner values need to be present in the respository.

[QuantamHD]

Messaging from the foundry was that these values are to be considered random. They have not committed to updating them.

I'm happy to accept a PR to fix this, or enhance downstream software so that we can remove them.

[RTimothyEdwards]

@QuantamHD : Our flow (openlane) depends on these values for initial estimates before doing full STA, so updating them is much preferable to removing them. I expect to have values from M. Shalan's openlane team and we will prepare a pull request. I just wanted to make sure that there was an issue associated with the problem.

[QuantamHD]

I believe @maliberty already calculated these for resistance in OpenROAD can we leverage their work?

https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/656/files

[maliberty]

I took the via res values from the docs. They match what I see from signoff tools.

The cap values in LEF are useless unfortunately.

[QuantamHD]

What is the correct long term solution for this stuff? Should Google et al. ensure the values in the LEF are up to date or is there another format for this stuff we should be supporting?

[maliberty]

ORFS has some scripts to extract average values from a bunch of designs' spef files. I guess we'll have to fall back on that unless there is a better option. Right now we need to bring up a bunch more designs to have enough to sample.

[RTimothyEdwards]

@QuantamHD , @maliberty : The commercial tools ignore these values which is why they end up with random incorrect entries in the PDKs (they also were wildly incorrect in the sky130 PDK and had to be fixed). So you are not going to get corrected values from GF and it then becomes your responsibility to correct the values in the repository so that the open source tool flows work.

These values can be derived in various ways, and the openlane team already has correct nominal values and I think is working on min and max values.

[maliberty]

How were the "correct nominal values" generated?

[mithro]

Given that the proprietary tools ignore these values, I think we should remove them from the LEF files.

[mithro]

Or set them to a known constant that is clearly a dummy / invalid value.

[RTimothyEdwards]

@mithro : Your point is that you want the open source tools to break?

[QuantamHD]

@RTimothyEdwards I don't think that the tools should break, but since the LEF seems unreliable for this task we should define a format for OpenROAD that provides this information, and a process to get it.

[RTimothyEdwards]

@QuantamHD : The LEF is unreliable because the foundries haven't noticed or fixed it where the commercial tool flows don't use it. But we should not insist that the open source tools work differently than they do; we should instead enable the open source tools by fixing the broken parts of the PDK.

[QuantamHD]

I'm happy to update the values, but it also seems like the values aren't as expressive as we want. Providing essentially a single corner. We should think carefully about what we want the flow to look like, and how to get there.

This LEF solution is non-ideal, namely because it lacks expressive power. Let me know if you think differently