DRC and netclasses : "potential classes"

Bug #983230 reported by Vesa Solonen
160
This bug affects 37 people
Affects Status Importance Assigned to Milestone
KiCad
Fix Released
Unknown

Bug Description

Flexible automatic design rules would need "differential net classes" that means different rules for a net depending on surrounding nets.

As an example I'll explain the problem of a traditional power electronics half bridge circuit:

HV---- [400V 10A]
     |
Gh--|< [0-415V 1A] [0 < V(Gh)-V(Sh) < 15]
     |
Sh-------> Out [0-400V 10A]
     |
Gl--|< [0-15V 1A]
     |
GND------> [0V 10A]

HV net needs "power" class clearance and width towards all nets as does Out. Sh needs "power" class clearance towards all nets, but Gh and width according to "control" class. Gh needs the same, but "control" clearance towards Sh. Gl needs "control" class clearance and width.

Curently this system is unrealisable using KiCad DRC. I propose adding a "potential class" description to net class design rules to address this problem. Needed data stuctures for file format support and implementation need to be discussed and designed. Interested parties are encouraged to comment here and aim for a production ready blueprint.

Tags: drc pcbnew
description: updated
description: updated
description: updated
Revision history for this message
Thord Nilson (thordn) wrote :

Yep, this is needed for the DRC to work for higher-voltage designs.

You would also need to be able to specify a clearance that is depending on if the net is on the surface layer or an internal layer.

In practice you can typically have half the clearance on an inner layer vs an outer one.

You can also consider a simpler case where one wants to measure a high voltage net via a number of series connected smd
resistors. Since each resistor only have a part of the clearance needed you need many in series, and to pass a correct DRC you need to be able to specify the clearance to the nets between the resistors.

Revision history for this message
Evan Shultz (evan-shultz) wrote :

Cadence Allegro has a very powerful spreadsheet-based Constraint Manager to handle this and many other ways of constraining a board design. See http://community.cadence.com/CSSharedFiles/forums/storage/27/964232/cmug.pdf for a (slightly outdated) overview, with the spacing being handled either as part of the net's constraint or a net class-class constraint.

The image I'll post here and in the next two responses will show this better. First is the constraint class set up, capturing distances from one object to other objects. The distances can obviously vary for different classes.

Revision history for this message
Evan Shultz (evan-shultz) wrote :

Oops. Here's the first image.

Revision history for this message
Evan Shultz (evan-shultz) wrote :

This is assigning a constraint class to a net (or bus, diff pair, etc.).

Revision history for this message
Evan Shultz (evan-shultz) wrote :

And the last showing constraints between net classes.

I'm not attempting to give a direction to KiCad, but I see similarities between the existing constraint approaches with the spreadsheet format already being used by KiCad. I hope only to show how this issue has been resolved before in one specific case, to make the complexities known so an appropriate solution can be developed for KiCad.

Revision history for this message
Jeff Young (jeyjey) wrote :
Revision history for this message
Victor W (vicw) wrote :

In addition to being able to uniquely specify zone clearances for a particular net (as mentioned in https://bugs.launchpad.net/kicad/+bug/1783091), an interim solution would be allow net classes to specify per layer clearances.

This would be incredibly useful when routing multi-layer boards with different dielectrics. In our case, we have three different differential geometries, depending on whether it is being routed on an outside layer, an internal IO layer, or an internal Signal layer. Each of these layers has a different geometry, but there presently no mechanism to ensure that the appropriate DRC rules are applied on a per-layer basis.

In particular, routing from an external layer to an internal layer requires very different clearance rules, but there is presently no way to distinguish the per layer rules that should be defined for each trace.

The current behavior sees us apply a constant geometry across all layers. A small drop down that would allow us to adjust the clearances on a per layer basis would fix this issue.

Revision history for this message
muzaffer (muzaffernizam) wrote :

can we see netclass clearance matrix in kicad 6? like eagle netclass clearance matrix?

tags: added: kicad6
tags: added: drc pcbnew
removed: kicad6
Revision history for this message
Michael Heidinger (mch-heidinger) wrote :

I would like to see the clearance matrix really in version 6, as i really require it for high voltage designs. It would make KiCad a professional tool like altium for me.

Revision history for this message
muzaffer (muzaffernizam) wrote :
Revision history for this message
NhatKhai (nhatkhai) wrote :

Also, https://bugs.launchpad.net/kicad/+bug/980919 may also relative to the implementation of this issue.

Revision history for this message
muzaffer (muzaffernizam) wrote :

Everyday i am checking this issue, everyday i am checking clearance matrix on kicad, everyday i open kicad nighly but i can't see clearance matrix, i lost my prospect from clearance matrix :(

Revision history for this message
Michael Heidinger (mch-heidinger) wrote :

@muzaffer. I'd love that feature too. Please kicad-dev-Team implement it! I support also your work regularly with donations. (3 times till today!)

Revision history for this message
muzaffer (muzaffernizam) wrote :
Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

This has been on the v6 roadmap[1] since the first revision. We are planning major constraint improvements in v6. What form that take has yet to be determined. The road map is suffering from bit rot but I plan to update it in the not too distant future after we get 5.0.1 out.

[1]: http://docs.kicad-pcb.org/doxygen/v6_road_map.html#v6_pcb_net_class_improvements

Changed in kicad:
status: New → Triaged
Revision history for this message
Michael Heidinger (mch-heidinger) wrote :

Dear Wayne, i would really apprechiate to see that feature on KiCad V6. This feature is highly important for high voltage PCB design, where maintaining propper clearances is a big issue.

Thanks for your work regarding this issue. Michael.

Revision history for this message
Tomasz Wlostowski (twlostow) wrote :

@mch-heidinger As Wayne already mentioned, we plan to rewrite the DRC engine and add improve the DRC rules editor in V6. I doubt the clearances will be entered in a matrix, though (I assume you mean Eagle's clearance matrix), as such approach only allows net-to-net or netclass-to-netclass custom clearances. We need a more flexible editor that will also allow setting per-layer, per-component or per-certain-part-of-the-PCB (a.k.a. rooms) clearance constraints.

@muzaffer: spare yourself the time making online petitions. DRC improvements are planned for V6, if you want to see V6 faster you can help us by testing or sending patches. Big features like DRC take time to implement.

Tom

Revision history for this message
muzaffer (muzaffernizam) wrote :

@tom: everytime i use kicad nightly in every my project and i am testing first. All of kicad features is may be important, but clearance matrix is the best important feature. Because every custom pcb designers use this feature. In pcb design other features may tolerate but we can't tolerate clearance matrix. This status cause huge error in pcb.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

@muzaffer, kicad cannot cause huge errors in pcbs unless is creates gerber files that do not match the board design. Only designers can make huge errors in pcbs. No constraint feature that I can think of can prevent you from making mistakes. At best (assuming you configured it correctly) it can only determine if you violated the constraints that you have set. When I hear comments like this, it makes me wonder how we ever made boards 30 years ago when few if any tools had sophisticated constraint settings.

Revision history for this message
muzaffer (muzaffernizam) wrote :

My flowers faded from waiting clearance matrix. Everyday i am control kicad v6 with clearance matrix :(

Revision history for this message
Michael Heidinger (mch-heidinger) wrote :

@Wayne/Thomaz:
I would really require this feature for my work with KiCAD for my high voltage designs.
-Michael

Revision history for this message
Victor W (vicw) wrote :

This feature is actually really important for us:

We are working on a complex, 26 layer board, with 0.5oz signal layers, and 3oz inner copper weights (due to current draw).

The problem is that we need to define separate clearance rules depending on the layer (aka copper weight. Due to the number of BGA breakouts we have, along with the dielectric and board thickness, we have VERY tight clearance requirements.

The problem here is that we only have these tight clearances on specific layers, and because kicad doesn't support per-layer clearances, we have to apply the tightest clearance on the net.

This is very sub-optimal because our designs are fairly complex, and we're looking to relax these constraints whenever possible. In this case, these tight constraints, coupled with an incorrect entry by the fab house CAM operator, contributed to an entire run being scrapped due to insufficient clearance after fab compensation.

The worst part is that the fix here is really simple; an additional 1mil (0.025mm) of clearance against the those vias, on the 3oz power layers, was "all" that was required to fix this issue.

The reason this is bad is because while engineers and designers obviously carry responsibility for identifying these issues, there is no easy way for us to simultaneously manage tight constraints for the controlled impedance geometries we require on dense, signal critical layers, and the substantially more relaxed constraints required for power.

If there is any way to help speed up development on this feature, or if you require additional users or testers, please let me know.

Revision history for this message
Rene Poeschl (poeschlr) wrote :

The developers are aware that this feature is important to many users. This is why it is planned for v6. It however takes time to completely rewrite DRC. So be patient and only comment if you have something new to add to the discussion! (Still waiting is not a good comment! It might even be detrimental. Remember KiCad is mostly made by volunteers that work on it in their spare time.)

Revision history for this message
JonRB (eeyrjmr) wrote :

Hi, just to chime in on this. As a power engineer having such a constraint management system would be worth its weight in gold.

Ultimately the responsibility resides with the designer, the reviewer BUT anything the tool can do to minimize errors is beneficial. Being able to provide minimum creapage between net's (or net classes) which PCBnew would honor while tracking will permit reviewing to concentrate on the less obvious area's rather than the novice errors.

If the entire constraint system is being reviewed for v6, it maybe worth creating a map of how others have solved it and any issued.

The three things I would say would be worth considering are
1) Each entry could have four entries
a) external uncoated ( esp < 3000m)
b) external coated
c) internal
d) internal, intralayer

2) Creapage between netgroups not just between net classes. A professional product for instance will provide a creepage/clearance table based upon net classes BUT if all nets within an isolated gatedrive are set to 3.5mm the resultant layout constrains would attempt to place 3.5mm between all nets within one channel - workaround was assigning at the context boundary and review.

3) Vertical creapage. Just to stress 1.d since prepreg is only so good an equally using multiple cores to mitigate quality isn't complete either.

The make/break of this is how easy it would be to enter such constraints but also how to manage. Aspects of this needs to be captured from the schematic capture.

Revision history for this message
KiCad Janitor (kicad-janitor) wrote :

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/1965

Changed in kicad:
status: Triaged → Expired
Changed in kicad:
importance: Wishlist → Unknown
status: Expired → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.