DRC misses odd trace/poly clearance error

[Ben Jackson]

The attached PCB is distilled from one I sent to Sierra Proto Express. Their DRC caught the problem. You can see I used 3 fat wires and 3 vias to tie a cap SMT pad to ground. The cap is inside a small poly on the surface. The lines themselves are not clearing the poly, but they don't touch because of the combination of the pad and via clearances overlapping. The actual gap (if you measure it) is only 4mil, though, smaller than the 6/6 rules.

[KaiMartin (kmk-familieknaak)]

Interestingly, I was able to pull the via a little more away from the pad so that the polygon copper still does not actually make contact to the track. But the DRC then detected the problem.

---<)kaimartin(>---

[Nicklas Karlsson (nicklas-karlsson17)]

I opened the attached file and if via is moved lines join polygon. If I press the "J" button "Change Join Object" clearance seems to work correct although I do not know the exact clearance value for the line.

[Luis de Arquer (ldearquer)]

This is due to the way DRC works.
If a line goes through a polygon, it is only tested for DRC if its "clearance" flag is set. This is because, if it is not set, the DRC system assumes it is intended to join the polygon. This is a very simple assumption which, in many cases, causes problems similar to this.
This can be located in PlowsPolygon() in polygon.c. Maybe we need to rethink how clearance-in-polygon DRC works (the same system is followed for vias, arcs, etc).

[Chad Parker (parker-charles)]

There are several ways that we might try to deal with this, but, none of them are easy.

One way would be to teach objects what electrical net they're connected to. Then, throw a DRC warning if a line from a different net doesn't have "clear" set.

Another way would be to find all of the different lists of connections that are connected to the polygon, and then check the netlist to see if any of the connected pins belonged to different nets.

Any other way I can think of would require changing how polygons and lines interact.

None of them easy, but the second one might be the most feasible given the state of the code right now. I'm open to ideas, if anyone has any.

[Luis de Arquer (ldearquer)]

I agree teaching each component what net they are connected to is a big change. Especially since, in practice, a component can be connected to multiple nets.

In the end, the DRC system decides which elements (at least lines, arcs and text) are candidates to violate the polygon clearance based on its CLEARLINEFLAG flag. The offending lines would be in PlowsPolygon():

    case LINE_TYPE:
    case ARC_TYPE:
    case TEXT_TYPE:
      /* the cast works equally well for lines and arcs */
      if (!TEST_FLAG (CLEARLINEFLAG, (LineType *) ptr2))
        return 0;

So, if CLEARLINEFLAG is set, then they can't violate clearance, because they are connected to the polygon. Which is a too-simple assumption because, as in this case, the line doesn't touch the polygon, due to the clearance of other components overlapping the line.

It can be solved by the user by simply turning on the CLEARLINE flag on the line, but that is not obvious for them; they just see a line not touching the polygon, and the DRC should still flag the error.

[Luis de Arquer (ldearquer)]

The simplest solution I can think of is removing those lines:

- if (!TEST_FLAG (CLEARLINEFLAG, (LineType *) ptr2))
- return 0;

and then, if PlowsPolygon() returns true (so the line is inside the polygon), check whether they belong to the same netlist, running the connectivity loop on the line.

Unlike the CLEARLINEFLAG test, it would be done *after* PlowsPolygon checks, and not before, because it is a heavier check. So it could be done in drc_callback()

Then we could work something out so the connectivity test is done only once per line -as it can plow different polygons.

[Chad Parker (parker-charles)]

In the case of this particular report, whether or not the net for the trace and the polygon are the same is irrelevant. I think the DRC of the fab house would still flag this as a minimum spacing violation.

The bad assumption appears to be that having the CLEARLINE flag set means that the line *IS* connected to the polygon, as opposed to *SHOULD* be connected. In this case, clearly it's not, and that means that there can be spacing violations.

So, as you say, perhaps the best answer is to check the objects for violations, no matter the state of the CLEARLINE flag. My first question is, would this break any of our existing tests?

[Chad Parker (parker-charles)]

I've investigated your solution here, and I agree with it.

I have a fix for this at the head of home/cparker/drc_updates. It creates a new kind of error for issues like this: "Joined line not connected to polygon". If the line bounding boxes overlap, and the CLEARLINEFLAG is NOT set (i.e. the line *should* be connected to polygons), I run the connection lookup to see if the line makes electrical contact with the polygon. If it doesn't, then we throw an error.

The user can then either move the line to make electrical contact, or turn on the CLEARLINEFLAG. With the CLEARLINEFLAG set, either the clearance issue will go away (if line->Clearance is adequate) or it will be flagged as an insufficient clearance in polygon error.

I'm actively developing this branch at the moment, so, it's been rebased several times. If you test it, make sure you get a clean copy.