Home > Community > Blogs > Digital Implementation > simple steps to debug drc violations undetected in edi system
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Digital Implementation blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Simple Steps to Debug DRC Violations Undetected in EDI System

Comments(3)Filed under: Digital Implementation, encounter, LEF, DRC, Encounter Digital Implementation, design rules, EDI, Cadence Online Support, NanoRoute, Verify Geometry, PVS, DRC signoff, DRC violations, debug DRC violations

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:

  1. Load the DRC violation report into EDI System
  2. Use Violation Browser to see details of violation
  3. Verify violation is valid by reviewing Design Rule Manual
  4. Determine if corresponding LEF rule is correct
  5. 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

Comments(3)

By Kari on September 17, 2012
Great post, Brian! For those of us used to using the PVS error viewer, that can be done in EDI as well using the menu item PVS->Open DRC/XOR Run...

By pandamaneni on January 5, 2013
how to resolve spacing violations after routing database

By wally1 on January 8, 2013
If routing violations remain after NanoRoute you can run:

   editDeleteViolations -keep_fixed

   routeDesign

This will remove nets with violations (unless they are FIXED) and then re-route these nets. This often resolves the violations because global routing is able to come up with a new plan to successfully route the nets.


Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.