Create an IP Checker Utility

[rovinski]

Description

Originally posted by @rovinski in https://github.com/The-OpenROAD-Project/OpenROAD/issues/4871#issuecomment-2026137319

Currently, it is very possible to import an IP block which is poorly designed and will cause downstream issues in OpenROAD, which becomes difficult to root-cause. A checker utility which checks against a list of common problems can go a long way in identifying problems early.

Suggested Solution

List of common problems to check (far from an exhaustive list):

• LEF
  • [ ] Macro dimensions are a multiple of the manufacturing grid
  • [ ] Pins are aligned to the manufacturing grid
  • [ ] Each signal pin must obey one of the following:
  • Minimum width, and each pin lies on the routing grid (with an offset is okay)
  • Greater than minimum size, has an access point on the routing grid, and connections from a default width wire OR an NDR rule does not cause a DRC violation.
  • Pins are wide enough such that regardless of offset, a connection from a default width wire (OR NDR rule) does not cause a DRC violation.
  • [ ] Power ring or grid straps are accessible (no obstructions in the way)
  • [ ] Signal pins are accessible (no obstructions in the way)
  • [ ] LEF file does not have an excessive number of polygons which will slow down OR
  • [ ] Ports have antenna info
  • [ ] LEFs in finfet processes have a fin grid property
• LIB
  • All quantities (rise, fall, delay, power, cap, etc.) are sane
  • [ ] No instantaneous transitions for reasonable input values
  • [ ] No excessively long transitions for reasonable input values
  • [ ] No excessively large capacitances
  • [ ] No missing properties
  • [ ] Characterization corner(s) match(es) the characterization corner(s) of the design
• LIB+LEF
  • [ ] Every LEF digital pin has lib timing info
  • [ ] LEF power pins defined match lib power pins
  • [ ] LEF and LIB area match

Additional Context

No response

[QuantamHD]

Huge +1 from me.

[maliberty]

Thanks for writing this up. A new comer doesn't have to implement every check in order to contribute. Ticking any box is helpful.

[rovinski]

Indeed, I just wanted to list everything I could think of.

[ghost]

Hi everyone, I am currently working on this subtask: Each signal pin must obey one of the following:

• Minimum width, and each pin lies on the routing grid (with an offset is okay)
• Greater than minimum size, has an access point on the routing grid, and connections from a default width wire OR an NDR rule does not cause a DRC violation
• Pins are wide enough such that regardless of offset, a connection from a default width wire (OR NDR rule) does not cause a DRC violation

Here is what I have gathered during my research:

• As I understood minimum width is defined as MINWIDTH in LEF files.
• I found the checkPin function in io_parser_helper.cpp, which uses frPin to check pin alignment on the routing grid. However, I am aware of different pin types such dbMPin, dbBPin, etc.
• I discovered code in FlexPA_prep.cpp where prepPoint_pin is called and a variable nAps is used to determine if there are access points for a pin.

Despite the progress, I still have some critical questions that I need your expertise to clarify:

• Given that this task pertains to LEF files, which function(s) or method(s) should I use to gather all necessary pins before reading the DEF file? I could not find a specific function for this purpose and would appreciate any guidance
• Is the checkPin function the only method available to verify if a pin is located on the routing grid, or are there other recommended approaches?
• Additionally, does the part of makeFastrouteNet function in the GlobalRouter serve any role in this validation?

@maliberty, @rovinski, @QuantamHD I appreciate your assistance in this matter. Any recommendations will greatly help me proceed with my task.

[maliberty]

@rovinski in order to talk about access points we would have to run pin_access. This can only happen after macro placement at the earliest. How are you intending for this checker to be used?

Perhaps it would be easier to check if the spacing between pins' centers are integral multiples of the track pitch. Sufficiently wide pins could be allowed to be exceptions.

[titan73]

+1 We had to develop such a tool. Some checks are listed here and some others are for compatibility with proprietary tools. And importantly, to check coherency between views (pins most of the time) between .lib, .lef, behavioural models, .cdl, ... We have a internal standard for IP package structure but I don't know if there is an open standard for that though.

[rovinski]

Sorry for late reply.

Ideally pin rules could be checked in isolation without having to have the macro placed yet. It would, however, require tracks and NDRs to be created already (NDRs mainly to avoid false positives).

If the macro has to be placed in order to run pin access, maybe is it possible to place it in a virtual block which then gets deleted after pin access runs?

[maliberty]

If you are just checking that the pins could be placed on the track grid then you don't need to use pin access and can just look at the pin spacing and shapes.

[rovinski]

That is one part, yes. But another part would be to check that the pins aren't blocked by obstructions. There could be a separate routine that does that, but it may or may not be easier to run pin acceess.

[maliberty]

Pins are never blocked by obstructions - pin shapes have priority over obstructions. From LEF:

Normally, obstructions block routing, except for when a pin port overlaps an obstruction (a port geometry overrules an obstruction).

[rovinski]

I mean something really dumb like this:

Also assuming that metals on top and bottom are blocked.

I've seen this happen in blocks that weren't extracted correctly.