I’m routing a BGA with 0.8mm pitch and 0.4mm diameter pads (created as per the datasheet).
I set the Pad Clearance on the footprint properties to 0.12mm to allow for an escape via or a single 0.1524mm (6mil) trace between the pads.
I have created net classes for my signals, many of which connect to BGA pads. The bulk of the signals are in the main net class with 0.1524mm (6mil) clearance and minimum track width.
The problem is, when I try to route a BGA pad the escape via is not allowed (violates the net class) because the pad seems to inherit the net class clearance (0.1524mm) instead of using the value I have set for the footprint (0.12mm).
The only way I have found to make this work is to set the net class to 0.12mm clearance and route the BGA escape vias, then change the net class back to 0.1524mm clearance so I can route the remainder of the trace on the board. The problem with this is, now when I run the DRC all the BGA pads show clearance errors.
This is very frustrating. Am I missing something, or is this a bug?
KiCad takes the larger of the two values. Anything else would lead to worse issues as you don’t inherently know which signal is trying to route close to your BGA pads. Having the pads override the net clearances would be problematic on a board.
As a designer, you will need to choose the correct net class clearance for the electrical signal type you are routing. If you really want to have two different clearances, you can always add a net tie after your signal exits the BGA. Then assign one clearance to the traces that are under the BGA and a larger one to the area outside.
That makes sense, pads should not override net classes of traces being routed near them, but I’m talking about the pads themselves inheriting the net class clearance instead of using the value set in the footprint.
Attached are two screen shots. The first could only be routed when the net class for the HSWAP signal (which connects to pad B2) was set to match the footprint clearance of 0.12mm. If I set the desired net class clearance of 0.1524 for the class that HSWAP belongs to, then you can see in the second screen shot that pad B2 is pushing the via up and right because the pad itself is using the net class clearance of the signal connected to it (and B2 is not even routed yet). Also note that the clearance for the +3V3, GND and unused pins net class is set to 0.0001mm in this case to be sure it is not causing the problem.
It seems to me that that pads should not do this. If pads inherent the net class clearance of any signals connected to them, then what is the purpose of the pad clearance in the first place?
I think other PCB software fixed this by having multiple separate clearance settings in each net class for things like pad-to-pad, via-to-pad, via-to-trace, trace-to-pad, and trace-to-trace. In my case, after routing, all nets with vias under the BGA fail the DRC because the via-to-pad clearance needs to be that of the footprint (0.12mm), yet the vias get the trace net class clearance value of 0.1524mm.
I thought about the net-tie work-around, however can I have a net-tie that does not require a physical footprint? Logical net class separation is all I need / desire in this case.
Yup, and somehow KiCad needs to be able to offer the same control.
Valid question.
Rhetorical question: If a user specifies a PAD clearance, what are they trying to tell the tools ?
With finer pitch parts, the need for some trace necking control increases. That necking control needs to cover both trace width and clearance settings.
Maybe we need to wait to see what v6 does to solve this ?
I don’t believe something like differing clearances per area or per trace has been added to v5. But there are plans to do it for v6. At least according to this mailing list message: https://lists.launchpad.net/kicad-developers/msg34781.html
It’s not a bug, just missing functionality. I’ve been fighting this for a year. I have a patch to fix this ready to go into version 5 but the small delay to the release of version 5 it would cause is not acceptable to the core developers. Not enough people are affected by it I guess.
I’m not sure about 4.0.7, but in 5.0RC1 you can set clearances visible (as outlines) for the tracks and pads through Display preferences. At least you can easily see what’s actually causing the violation.
Not until development on 6 starts, and not unless the core developers accept the approach. If there were more people that needed this I might have a chance of getting it into version 5 but so far it seems only a few people do complicated enough layouts to be affected by this.
Wayne rejected it not because it is not useful but because kicad is in feature freeze. (And it seems some developers had a more powerful feature in mind that might need a slightly different approach. So maybe kicad will benefit from a discussion here.)
Right now kicad is even farther ahead than a simple feature freeze. The first release candidate has been tagged. As your patch would change the file format this would mean that a file made by rc2 can’t be opened by rc1. That is just not how release candidates are supposed to be.
Even changes to the user interface are now problematic as the guys writing the documentation need something stability such that they can write the documentation for v5. (The docu should be finished before the official release.)
The time between rc1 release and the final release is mainly used to write the docu and to fix remaining bugs.
You would have had a chance getting it in v5 if you submitted your patch at least half a year ago. You are not the only developer who submitted a feature during feature freeze. Others have also been told that their patch goes too far. Their patches had much less impact then yours.
If the development team would be a bit larger it would be possible to branch away v5 and start developing v6 already. But a lack of manpower means the core team really needs to focus on v5.
Thanks for commenting. My understanding of the situation matches yours though I’d like to clarify a couple points.
I did not claim Wayne would reject it for any reason other than feature freeze. The stable release policy states that features can go in post feature freeze by exception. If I thought I had enough support for the feature from the community (what I lamented about earlier) then I would bug Wayne with the actual patch. But I don’t have that support and I have not bugged him. I’m aware how limited the resources are and have tried hard to not get in the way. As soon as 5 goes stable I’ll bring it up.
The file format tweak (https://lists.launchpad.net/kicad-developers/msg34779.html) is a different, very small patch. Furthermore, it does not change the file format in a breaking way. There would be no problem opening v5rc1 files. I will still try to get this added. There are a lot of good reasons why the patch may not be accepted, but the impact of it on my team is too big to not try.
Thanks for all the work you put into the libraries.
I think the basic idea that something which would serve only one customer would be added to the file format is problematic. Even if it would be easy to remove afterwards. Have you thought about a more general solution, like adding “custom-extension” attribute which would have text/text (key/value) pair? I don’t know about the file format, but if there can be many attributes with the same name, anyone could add any data to items and handle it as they wish. So, if your patch only enables the possibility of some new data by letting KiCad accept and ignore a certain attribute, why not make it so that anyone could use that for any purpose? That could be more interesting to the core developers.
It’s not a matter of not needing it or not doing “complicated enough” layouts, but rather having features like this, and several others that have been mentioned on this forum lately, thought through and implemented properly.
@1.21Gigawatts I get your point. Of course in my opinion what you see in the video has been carefully thought through and implemented properly. It slots in with the DRC system and the netclass system, both as it is now and with the additional heuristics being talked about as future stuff. It stays out of sight in the UI until users actually need and use it, so as to not complicate things for new users coming up the learning chain.
I do honestly believe that if enough users would benefit from it, it could go into version 5. But I only count a few so far that have voiced their need, and I have no intention of wasting the core developers time for that.
They say this "- we are planning to overhaul the clearance/design rules system in V6. Storing the clearance DIRECTLY for each track segment/via will conflict with any more sophisticated design rule management system."
I can see merit in clearance-by-segment, as it is easy to explain, but it is manually focused, and not compatible with Autorouters. If you rip-up a trace, the clearance info is lost.
Being manual in nature, it also consumes many mouse clicks, and is less compatible with more formal design rule definitions (which avoid operator over-rides)
Best to wait to see what the “overhaul the clearance/design rules system in V6” means - this thread is about PAD / PART clearance, which is useful to be able to mange with fine pitched parts.
Expanding that, a more general neck-down-rule would permit shove routing to exit fine pads, then use a default larger trace/clearance, but permit necking between pads.
@eelik I believe that code exactly like my file format patch will need to go into 6 (even if they do their own clearance thing and reject mine) so I prefer to think of it as an early code addition rather than something that serves only me and my team.
I thought about offering a patch like you describe. Because one has keep track of those key/value pairs (and where they are if you allow them to be anywhere in the hierarchy) and then rewrite them, the patch would be a good chunk of code and bigger than I felt comfortable trying to push into version 5.
I think user key/value pairs would be a good addition to the format.
Interesting idea. It would be fairly easy to have KiCad tolerate extensions, but the tricky bits come during edit and save.
How should Kicad preserve those extensions, if it does not understand them ?
In this suggested case, clearance info is optionally added/removed to segments during editing, but the file that results will only generate final valid copper plots in a segment-clearance-aware KiCad.
