Encounter LVS and DRC

This is a tough question to answer generally, but I'll share some thoughts that might be helpful for general troubleshooting that aren't necessarily tool-specific.

In any automatic routing tool, there is some build in DRC checking that occurs as the tool is going about it's task of doing routing.  Then beyond that, there's typically DRC checking built into the implementation tool that can be used to check the routing (and further check whether portions of the design that aren't necessarily automatically routed cause DRC violations).  Beyond this, there's also typically a signoff DRC tool that's used as a final check.  There's a natural speed/feature-support trade-off in each of these levels of checks.

When the automatic router finishes, it will leave markers for violations it knows it was unable to resolve.  Sometimes, the automatic router finishes and report *no* violations yet verifyGeometry does report violations.  One example of this that comes to mind are min-step violations.  In cases like this we need to troubleshoot why there is a discrepency.  In a perfect world, NanoRoute's view of DRCs is in alignment with verifyGeometry's.  But complex design rules sometimes aren't seen exactly the same given the run-time/feature-support tradeoff and we need to do things to help the automatic router avoid the violations either by coding the rule in a different way, constraining the router such that it doesn't make the violation, or using a post-processing step to resolve the violation.

If you have a specific example of a discrepency feel free to post a picture of it and a description of the issue in this forum for folks to comment on.

Hope this helps,
Bob

This is a tough question to answer generally, but I'll share some thoughts that might be helpful for general troubleshooting that aren't necessarily tool-specific.

In any automatic routing tool, there is some build in DRC checking that occurs as the tool is going about it's task of doing routing.  Then beyond that, there's typically DRC checking built into the implementation tool that can be used to check the routing (and further check whether portions of the design that aren't necessarily automatically routed cause DRC violations).  Beyond this, there's also typically a signoff DRC tool that's used as a final check.  There's a natural speed/feature-support trade-off in each of these levels of checks.

When the automatic router finishes, it will leave markers for violations it knows it was unable to resolve.  Sometimes, the automatic router finishes and report *no* violations yet verifyGeometry does report violations.  One example of this that comes to mind are min-step violations.  In cases like this we need to troubleshoot why there is a discrepency.  In a perfect world, NanoRoute's view of DRCs is in alignment with verifyGeometry's.  But complex design rules sometimes aren't seen exactly the same given the run-time/feature-support tradeoff and we need to do things to help the automatic router avoid the violations either by coding the rule in a different way, constraining the router such that it doesn't make the violation, or using a post-processing step to resolve the violation.

If you have a specific example of a discrepency feel free to post a picture of it and a description of the issue in this forum for folks to comment on.

Hope this helps,
Bob