Mail Archives: geda-user/2018/07/14/23:40:17
Hello Luis,
On Sat, 14 Jul 2018, Luis de Arquer (ldearquer AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> Chad -and everyone,
>
> I have been diving a bit more into the DRC clearance issues on
> launchpad, and I found that the problem is bigger than I thought. The
> same problem is present in pcb-rnd.
Thanks!
> The DRC clearance-check works in three steps (this is line to polygon,
> but arc and pad to polygon is probably the same)
>
> 1. Check whether bounding box of the line overlaps the polygon
> 2. If so, check if they are joined or separated.
> 3. If they are separated, check the clearance between them.
>
> This scheme looks fine to me, except on how it is executed:
>
> 1. The bounding box used for checking the overlap is the line's
> regular bounding box. This bounding box is built with [line thickness
> + line clearance]. This is wrong. It should be made with [line
> thickness + *DRC clearance*]. The consequence is missed errors in DRC.
You are right. The basic wrong assumption probably was that the
per object clearance value will always match the drc clearance value.
(Somewhat related: many other EDA systems have a much more limited model:
they don't have per object clearance, but only one global clearance which
is then used both for polygon clearances and DRC checks. In those systems
they can have this assumption)
This problem is more generic and affects a lot of other parts of the code.
A typical example is the dashed outline of the subcircuit. It is drawn at
the boudning box of the subcircuit, which is the bounding box union of all
objects within the subcircuit. This, of course, also includes the
clearance - which makes the subcircuit bounding box extend slightly beyond
the expected.
This is somewhat tolerable with copper because one can reason for
including all side effects of a subcircuit in bbox. But it gets especially
bad if you have lines objects on silk or outline or mask or paste where
clearance won't matter (because you won't draw polygons there), but you
left the clearance value non-zero. There you really have the extra bloat
in the subc bbox for seemingly no reason.
Another example where this hurts: draw a line with a large clearance
value, then cut to buffer and move. The buffer content will bump into
board edge at the buffer's bounding box. Which, of course, is again the
union of all contained objects' bounding boxes - including the clearance.
So you can't get the _copper_ of the line close to the edges because it
insists on keeping even the clearance within the drawing area, which is
stupid.
Solutoin:
This generic problem is well known in pcb-rnd and I have a plan for it: we
simply need to track two bounding boxes for every object. One is the naked
("copper") bounding box that is the base object without any side effect,
and the other is the final bounding box, the object with all side effects
including clearance. We need to keep the second only for historical
reasons because the code depends on it everywhere. As long as the only
such side effect we have is clearance it is cheap to calculate: most of
the cases you just bloat up the naked box by clearance on all sides to get
the final box. Then each part of the code can decide which bbox to use.
So in case of drc, we'd use the naked bbox and would add the drc
clearance on top of it.
> 2. In order to check whether the line and polygon are joined or
> separated, the "clearline" [J] flag on the line is checked. This is
> wrong too, because false positives and negatives exist:
> - A line may belong to the same net than the polygon, even though it
> has the "clearline" set (e.g. a third line connects each other)
That's not necessarily a bug imho. It depends on how we define things and
what we want of DRC.
Approach #1 is that DRC is coupled with nets. In this setup, you are
mostly interested whether your nets risk a break (minimal overlap not met)
or risk a short (minimal copper distance not met).
Approach #2 is that you have a board with different objects and you want
to fab the board. At the end, the dabbing process will go wrong (or at
least will get very expensive) if you have thin hair of objects (copper,
or even silk!) or you don't meet the minimal overlap.
We inherited approach #1 from pcb. But I believe we should go toward
approach #2.
A trivial example is if you start drawing copper objects that are not part
of any network. In most cases they are totally invisible to the drc code
as they are not reachable from any netlisted terminal. But at the end,
physics work on them too, and your fab's CAM checking too, and they will
charge you the extra cost if you did something strange on non-net copper
(or even silk).
> - A line may not join the polygon, even with the clearline unset. For
> example, when other elements (vias, etc) clear the polygon around.
I agree. The generic rule should be real connection checking over
heuristics and assumptions.
>
> 3. Once the line is considered to plow the polygon, the DRC checks the
> clearance setting on the line (line->Clearance). This may create false
> positives, because there may be other elements clearing the polygon,
> or the line may be at a corner of the polygon. This is the bug i fixed
> in https://bugs.launchpad.net/pcb/+bug/746178
>
> I have attached three PCB examples, showing the three bugs separately.
> Most, if not all, the polygon to line/arc/pad bugs in launchpad are
> variants of these three.
>
> I think the solution is:
>
> 1. Use the DRC setting to build the line bounding box, not its own
> clearance setting.
I generally agree, but I'd prefer to do what I described above: just keep
track on both a naked and a with-side-effects bbox, because it's not only
the DRC that needs this.
Adding it only in the drc would lead to code duplication and more
expensive drc because it wouldn't be able toe asily cache this so it would
ahve to recalculate it every time.
> 2. Forget about the "clearline" flag. Instead, check whether there is
> electrical connection between the line and the polygon. Only if they
> are (directly or indirectly) connected, skip it. If there is an
> accidental, small connection betwen them though, it won't show up in
> DRC, but updating the rat nest will do (this is consistent with the
> overall behaviour of how DRC/rats work).
I agree.
Caveat/risk/challenge: the line end cap is a true half cirlce, while the
clearance arc cutout is emulated with straight line approximation (the
polygon code can't yet handle arc-in-contour). IIRC there's some
provisions for this in the polygon code, making the rounding in favor of
"rather staying farther than closer than the clearance", but we will need
to double check that. Worst case we can end up in a situation where the
clearance causes a 1..2 nanometer drc error because of the approximation.
> 3. Once the line is considered to plow the polygon, bloat the line
> with DRC clearance, and use IsLineInPolygon() for an exhaustive test.
> This uses the real shape of the line and the polygon, and should not
> throw any false positives.
Sounds good!
> I have corrected 1 and 3 in my local tree, as I need it for our PCB
> production (and verified 2 does not affect me). I will try to fix 2
> asap.
>
> Couple of requests/questions:
> - Any help confirming these issues is welcome (even just confirming
> the bug on the three attached files)
Your examples don't contain nets. I am not sure what mainline does these
days, but original PCB and pcb-rnd won't do much checks with these
objects. So as expected, I got no drc warnings for any of the examples.
I've tried connection find (a.k.a find.c, {c f}) on them, and that seemed
to do the right thing for all cases.
Extending your test set:
http://igor2.repo.hu/tmp/drc4.pcb
http://igor2.repo.hu/tmp/drc5.pcb
http://igor2.repo.hu/tmp/drc6.pcb
These demonstrate that actual minimal overlap or minimal distance rules
can be violated without DRC detection if objects are not part of the net.
This is the case where your fab will start charging a lot without DRC
warning you.
drc6 is a flag trickery: we do have clearline flag on the line but we do
not have clearpoly flag on the polygon. This results in the same
situation, no clearance, but with a different set of flags. We need to
make sure this doesn't break either.
> - Any thoughts/discussion about the proposed solutions would be very
> healthy too.
> - What is the normal workflow to publish the patches, so they are
> included asap in mainline?
pcb-rnd: we use svn instead of sending or collecting or tracking patches.
You still have your commit access. We are in feature development phase
yet, very far from the pre-release code freeze. If you fix drc bugs,
please feel free to commit them. I will review and comment (if needed)
after the commit (I do get automatic notification of commits).
Your commits are accessible for pcb-rnd users immediately - and we have a
strong, productive community and there are quiet a lot of hardcore folks
using SVN HEAD even for production! So your changes are tested through
fast. And of course, anything commited is included in the next release as
well.
If you say yes to commiting your drc fixes in pcb-rnd, I can add the
2-bbox system in the code today/tomorrow, so you don't need to worry
about that part.
(Offtopic: you got your write access for the rubber band upgrade back
then. You did a great job there; Ade went on building on top of your work
and combined it with his rubber band extensions. You should check it out
with either pcb-2.0.0 or SVN HEAD - the rubber band is so nice by now that
even I started to use it, while I was a rubber-band-hater for a decade,
lol)
Best regards,
Igor2
- Raw text -