Bug in DRC (possibly caused by track of length 0)

Layout
1

Attached is a minimal sample of the alleged bug: the layout contains only two tracks on the top layer: a 0.15mm wide track of length 2.55mm, and a 0.42mm track of length 0 (it does show as a disc). The edges of those tracks are 0.12mm away from each other.

The DRC says that the tracks cross

DRC-bug.kicad_pcb (4.8 KB)

It is my opinion that the above by itself describes the bug. However, for some background on this (i.e., how did I stumble into this and why do I care): I’m trying to achieve stubless vias (vias that do not produce a stub in inner layers due to KiCAD’s inability to have pads of different diameters for different layers). Using notation (d,h) to denote a via with pad’s diameter d and hole’s diameter h, I am writing a program that scans the .kicad_pcb file and replaces every via (d,h) with a via (h + 0.002mm, h) + pads (of diameter d) on outer layers + pads on any layer where a track connects to the via.

For the pads, I noticed that KiCAD accepts tracks of length 0, so it seems like the most effective way to put a round pad: just create a track of width d (the diameter of the original via) and length 0 (i.e., the track goes from the position of the via, to the position of the via).

The funny thing is: in the original board where I’m trying the program, there are hundreds of vias, and many tens of vias placed pretty much in the same arrangement as this one (it’s a via to fan-out from a BGA, so there are many many others that are similarly connected).

And yet, the DRC gives me only this one error. No nets unconnected, no objects too close, nothing: just this one tracks crossed error. (the minimal sample comes from that board; I just erased everything else, and the error still shows up)

KiCAD’s version info:

Application: Pcbnew
Version: 5.1.9-73d0e3b20d~88~ubuntu18.04.1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 5.4.0-66-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
    Boost: 1.65.1
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.58.0
    Compiler: GCC 7.5.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=ON
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
1 Like
2

I can see nothing wrong, except the “zero length track” but that is apparently not the issue.

I took some of your numbers, and gave them names:
(You can check these numbers with your file, and paste them in a python console thingy, octave, etc)

XXX = 92.974013
X_W = 0.15
EBI = 0.115
CLK_X = 93.374
CLK_W = 0.42

Then I calculated the width of the stack:

End = XXX + X_W/2 + EBI + CLK_W/2
End
93.37401299999999

And calculated the overlap:

CLK_X - End
-1.2999999995599865e-05

So you have an overlap of 13um and DRC is right.

To double check, I clicked on the “zero length” track, and e to edit it’s properties, and moved it an extra 13nm to the left:
image

And with this 13nm push DRC is happy because there is no overlap anymore.

How important is this overall feature to you?
In KiCad-nightly V5.99 there is a an option to remove pads from inner layers if there is no track connected. It’s not a full pad stack yet (were each layer can have it’s own pad size) but it is a step in the right direction. But before you dive into that, read: Is it a good idea to use a nightly build version?

Some time ago there was an issue on gitlab, concerning rotated footprints which caused DRC errors. (for example 0.5mm pitch QFP with 0.3mm wide pads and 0.2mm clearance. The solution was to add a tolerance for DRC of a nm. (Yep, nanometer) and that was deemed enough.

P.s:
Excuse the repetitive digits. It’s rounding error from Pythons floating point stuff. KiCad itself works with 32-bit integers in nanometer resolution (so a max PCB size of 4 * 4 meters)

2 Likes
3

Thanks for your comments paulvdh.

So, two aspects:

  • Your calculation shows that the tracks are too close (closer than the 0.115 allowed clearance, as per the EBI net class), and not that the tracks cross, as KiCAD’s DRC reports!

  • With that said, I see that my program does round things: I read positions and sizes into double variables (in C++). So, the position of the via in the original file is 93.374023 (i.e., leaving 10 nm more than the required clearance). Since the via is the one that I replace with a track generated in my program, the 93.374023 that was read into my program now gets output as 93.374; however, everything else (including the D6 track) is just read into a string and later output directly from that string, so of course the 92.974013 is output verbatim to the modified file.

Sill, like I mentioned: regardless of the motivation or the “political (in)correctness” in what I’m attempting to do, the fact that KiCAD’s DRC says that tracks cross is a bug. Granted, less “puzzling” than I originally thought.

Some follow-up aspects:

  • I go to the original file and place a 0.42mm track of 0.001mm length, running parallel to the D6 track,and make its X coordinates 93.374 (instead of 93.374023), and I get error Two parallel track segments too close.
  • If I make it diagonal (starting at the via’s position and going diagonally to X=93.374, I get error Two track ends too close (which, strictly speaking, is incorrect: what’s happening is that the end of one track is too close to another track).
  • And finally: if I make it length 0 (and X = 93.374), then I get error Tracks crossing (like in the minimal sample I posted. Which, again, is incorrect: the tracks do not cross; the tracks are too close).

So, I guess the bug goes beyond what I originally posted, but it simply relates to the phrasing used to report an error when two tracks are too close, which additionally depends on the relative arrangement/geometry of the two tracks.

Should I report this bug? (it may or may not be fixed in 5.99, but still, 5.1 or any possible 5.2 may still be around for a while)

4

Unless you can produce the situation without external help, i.e. without manipulating the file with something else than KiCad itself, I see little chance to get it fixed for v5.1.x unless maybe if it would require only changing description strings. (There won’t be 5.2.) The DRC system in 5.99 has been changed radically. If you want to help KiCad development I suggest you try with 5.99 and report bugs for it.

2 Likes
5

Fair enough. To be honest, I have been extremely tempted to get 5.99, both from my own selfish purposes (you know, get better functionality, or in any case better features), and from the perspective that you point out: any help in terms of bug reports would be best used in the development going forward.

But then, I’ve been extremely busy with work (which in the past several weeks has involved mostly doing boards layouts and designs), so I cannot risk using the nightly builds for that.

Cheers!

6

OH, BTW, at first read I sort of missed this detail. No, of course the bug can manifest in KiCAD by itself: the bug description is extremely simple: if two tracks are too close, then for some arrangements/geometries, the DRC error message is incorrect/misleading. Although during the creation/routing of the track (under normal conditions) KiCAD will not allow a “tracks too close” violation, it can happen later as a result of a large number of possible actions (editing tracks, manually moving with M or Ctrl-M, changing a net class, etc.)

The worst-case is perhaps when one track has 0-length, which can be produced by KiCAD, through the properties dialog for the track. Although possibly unlikely, a user may have a similar use-case/motivation as mine, and just try that without going and writing an external program to manipulate the file.

7

This brings me to perhaps the fundamental / bottom-line aspect: do we have an idea of how close 5.99 is from release, or in any case from “production quality” that one could reasonably consider to use for real-life work?

It’s been already close to three years since v5, and that was more or less the time from v4 to v5. From what I’ve read, v6 is involving more fundamental changes, so it seems like it will take longer from v5 to v6 than it took v4 to v5? I guess my question is: are we close-enough yet? :‒)

8

I would report it against 5.1.9, the steps to reproduce it are easy.
If setting length = zero in the dialog causes this, it should be fixed or not allowed.
I’m confident we will see 5.1.10

2 Likes
9

There’s no one-size-fits-all answer to that question. Personally I would say that if you are willing to take some risk compared to using only the stable version but still be relatively safe, wait until all the new features have been integrated and then stabilized for maybe a month. The features which are still waiting are arcs in polygons and the new python API.

When these features will be there is not known yet. @Qbort has been working on a merge request for arcs in polygons, maybe he has something to say. Earlier today someone asked about the new API in the developers mailing list (https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg39436.html) and I’m sure everyone who has ever done something with the python API of KiCad are impatiently waiting for the answer.

10

There is also another case where the report is incorrect, although admittedly, not nearly as bad as the “Tracks crossed” due to length=0. See screenshot below:

image
image1782×791 113 KB

The actual error is that the end of one track (the thin one, net +3.3V) is too close to another track (the wide, GND track).

I would definitely prefer that length=0 remain allowed :‒) It may seem useless, but it is neat that it is allowed and produces a disk of diameter = the width of the track.

11

Sorry @eelik for some reason I only received the ping now. Yes I’m working on that MR (which Seth already started), to bring curved polygons in. I am probably a couple of weeks away, depends how far I get this weekend.

12

Again: DRC is correct. (As far as I can see. I assume same clearancefor the track as for the GND pad)

To show what KiCad makes of clearances I suggest you turn on: Pcbnew / Preferences / Preferences / Pcbnew / Display Options / Clearance Outlines / Choose your Poison.
image

13

Again, @paulvdh ‒ looks like one of us is not understanding what the other is saying:

In the original case, the tracks do not cross. They are too close, and apparently when one of the tracks’ length is zero, the error is shown as “Tracks cross” (seems like a case of the else clause in an if -- elseif ··· block, where the developer did not see the one-of-the-tracks-being zero-length case coming).

In the above case, the error message is incorrect in a less severe way: the error message states that the track ends are too close. I argue that that statement is incorrect (the fact that there is an error is correct; what I claim is that the description of what the error is, that is what is incorrect). One of the track ends is too close to the middle of the other track. For that matter, I cannot even picture a situation where it would make sense to say “track ends too close” without inviting a philosophical discussion (if the “track end” is the point, then it’s not the end that is too close, since the violation occurs at the edge of the disc around the track end). Perhaps, the error message should (always) simply be: “Tracks too close”, and “Tracks overlap” when they do overlap (instead of “cross”, which implies that one of the tracks passes from one side to the other side of the other track).

Again, unless I’m not understanding what you’re saying?

14

5:99:

image
image1032×649 39.2 KB

15

Awesome, thanks for sharing @eelik.

It is awesome that v6 flgas (as a warning) a track with unconnected end!!! (which makes me wonder: is that a new feature in v6, or is it one of the (sadly so many) features that I have not discovered in v5?)

As feedback, I would say the error message (the third one) is confusing; the first part, “Error: clearance violation”, is perfect (I love it!! Much better than what I had imagined, just “tracks too close”) … however, the detailed info that follows, I find it confusing; two aspects:

  • Which one is “(current) clearance” and which one is “actual” ?? “actual” as in what you actually have in the layout? or “actual” as in the actual clearance specification?
  • Seems odd, talking about the clearance in the layout; intuitively, in the layout you have a distance; if that distance is smaller than the clearance, then there is a violation; maybe it is a linguistic issue / limitation on my side? It may well be that clearance means the space between two things; but in the context of a CAD software, in particular KiCAD, one gets used to understanding “clearance” as one of the specified requirements; in that sense, it sounds odd.
    I think what I’m trying to articulate is: if the dialog box refers to the distance you have in the layout as “the clearance”, then the specified clearance should be referred to as “required” and not “actual”.
16

Yes, it is.

actual:

  1. Existing in reality, not just potentially; really acted or acting; occurring in fact.

What you call “clearance specification” is called netclass clearance here.

clearance:

2: the distance by which one object clears another or the clear space between them

17

IMO saying just “clearance” is unclear. It could say for example “rule”. Even better would be if it would give details about the rule which causes the violation. In 5.99 there’s Inspect -> Clearance Resolution which gives some detail(s) about clearance rules between two items. The same idea could be utilized here somehow, and the Resolution dialog could be opened from the DRC window.

18

@eelik: while trying to figure out how to explain to radix what my actual (no pun intended) linguistic limitation would be (the way I suspected), I noticed a far worse issue with the dialog from 5.99:

It looks like you opened the same file I posted; however, there’s nothing in the file that has a clearance specification of 1.0 mm, and no two things in the layout are exactly 1.0mm away from each other. Where is that “1.0000 mm” in the dialog coming from?

Back to @radix point: the dialog above says “actual 0.115”. So, given the way you posted the dictionary definitions, I take it you’re suggesting that that can only mean “the clearance that does occur in reality, in the actual/concrete layout”. However, 0.115 is the specified clearance. From the DRC-bug.kicad_pcb file:

(net_class EBI ""
  (clearance 0.115)
  (trace_width 0.15)
  (via_dia 0.42)
  (via_drill 0.2)
  ···

Am I still missing something (linguistically or otherwise) ?? Or does that dialog require a closer look by its developer to sort things out?

19

My version works just fine.

image
image735×833 54 KB

I suspect @eelik modified your netclass clearance or something … In the end it doesn’t really matter.

20

That’s right, because there wasn’t effective clearance value in the project, it was 0 in the Board Settings -> Constraints. Sorry for the confusion, I should have told but was too lazy, and now I have to write much more than I would have written if I would have told in the first place. :smiley:

2 Likes