You've placed and routed your design in the Encounter Digital Implementation (EDI) System. It passed Verify Geometry and Verify Connectivity without a violation. Great!
But when you run DRC signoff with your physical verification tool, you have violations related to the routing. What should you do now?
Depending on your situation there are usually two solutions:
1. Fix the violations by hand. This is okay if there are a small number and you don't need to go back to physical design.
2. Debug why these violations were not caught during physical design. This is done when you want to understand the cause of the miscorrelation. Is it a bug in one of the tools? Is a LEF rule wrong? Is the DRC rule deck wrong?
In this blog I'll explain my approach to debugging the discrepancy. If you have a different approach, please share it by adding a comment below. Here are the details of my approach:
- Load the DRC violation report into EDI System
- Use Violation Browser to see details of violation
- Verify violation is valid by reviewing Design Rule Manual
- Determine if corresponding LEF rule is correct
- Review other causes such as Verify Geometry option settings
First I read the violation report from the DRC checker into EDI System. EDI System supports the major DRC tool formats. In my run I've taken advantage of the Physical Verification System (PVS) interface from EDI System and invoked it straight from the EDI System GUI (PVS - Run DRC).
To read in the results to the violation browser I select Tools - Violation Browser. Then I on the Load Violation Report form, specify the report file, ts format and click OK.
Here I see there is a violation on an M2 metal. If I go back to the Violation Browser and click on the actual rule, the Description field gives the reason for the violation. In this case it says the METAL2 to METAL2 spacing required is >= 0.15.
Zoom into the violation by clicking on it under the Location section of the Violation Browser.
Below is the example violation with rulers added to show the spacing and widths:
If you have the Design Rule Manual (DRM) you can double check the rule to confirm the DRC check is correct. If the DRC deck is in development or for a newer technology ,it's possible it's wrong, but typically it is correct since this is for signoff.
The next step is to determine which LEF rule should enforce this spacing and verify it is defined correctly. This is not always easy, especially as more and more rules are required for smaller geometries, but typically you can narrow it down by knowing the layer, type of rule and value expected. And if the LEF has comments to label which LEF rules correspond to the DRM rules, then it's even easier.
If we go to the spacing rules for M2 we have a SPACING table which specifies required spacing based on the object width and parallel run length. This rule is likely the one which should be enforcing the spacing.
LAYER Metal2
...
SPACINGTABLE
PARALLELRUNLENGTH 0 0.32 0.75 1.5 2.5 3.5
WIDTH 0 X.XX X.XX X.XX X.XX X.XX X.XX
WIDTH 0.11 X.XX 0.15 X.XX X.XX X.XX X.XX
WIDTH 0.75 X.XX X.XX X.XX X.XX X.XX X.XX
WIDTH 1.5 X.XX X.XX X.XX X.XX X.XX X.XX
WIDTH 2.5 X.XX X.XX X.XX X.XX X.XX X.XX
WIDTH 3.5 X.XX X.XX X.XX X.XX X.XX X.XX ;
The rule seems correct ,stating that for a width 0.11 and parallel run length of 0.32 the spacing should be 0.15. But looking closely at the LEF syntax I find objects have to be greater than the specified width to trigger the rule:
PARALLELRUNLENGTH {length} ...
{WIDTH width {spacing} ...}
Specifies the maximum parallel run length between two objects, in microns. If the maximum width of the two objects is greater than width, and the parallel run length is greater than length, then the spacing between the objects must be greater than or equal to spacing. The first spacing value is the minimum spacing for a given width, even if the PRL value is not met.
So in this case the LEF rule is incorrect and must be adjusted. After I change 0.11 to 0.10 in the LEF rule above then Verify Geometry catches the error shown in the browser below and the GUI:
An incorrect LEF rule definition is just one possible cause. Other possible reasons are listed in solution 11728790 on Cadence Online Support:
Lastly, always check with your foundry for the latest technology LEF. They often provide technology LEF files optimized and tested for EDI System.
And if you ever need help with debugging we're here to help. Contact us by opening a Service Request by going to http://support.cadence.com and selecting Service Requests - Create Service Request.
Thanks,
Brian Wallace