← Back to team overview

kicad-developers team mailing list archive

Re: zone fill with micro-vias


Dick Hollenbeck a écrit :
Tim Hanson wrote:


> >
> Further research is desired before a solution is chosen. I for one am
> not in favor of tying the solution to the fill tracks a.k.a "class
> SEGZONE" instances, if we can find an alternative.
> We should start out with an objective of finding a solution based on the
> zone container and invasive tracks from other nets, and the clearance in
> play from those invasive nets, and any internal keepouts.
> Many folks are doing this now, including freerouting. net. Even the
> Specctra DSN file spec has no notion of "fill tracks", so that means
> CADENCE specctra, electra, etc., have all managed to do it without the
> ho-key fill tracks.
> Dick
Obviously, thinking in matter of polygons is the best solution.
When others softs use tracks to fill copper poor, this is only at plot
time (when creating gerber files).
So the focus is on using polygons to manage zones (including DRC and
Plot files).

Jean-Peirre, Dick & all --

Ok, I disagree on this point. Until we have a zone filler that uses
polygons, we *should not* test connectivity with anything other than
the *actual copper* that is laid out on the actual board using
algorithm that we have, the rasterized fill. If the user chooses a
coarse rasterization, whether or not a connection is made to a
nearly-isolated zone 'island' can be dependent on the alignment of
vias and tracks relative to the grid of the rasterization. I think
doing things with polygons is correct and better, but only if we have
zones that are filled with polygons.

Alternately (or equivalently), if the zone fill test connection based
on laying out hypothetical tracks to see if they can fit through any
gaps without DRC violations, then these tracks should be included in
the board.

I think that filling a zone, though it is done as the last step in
board production, should be treated like laying out any other track,
at least with the present zone filling algorithm: it connects all nets
only when there will be copper in the finalized board to connect them.
This means that we add a bit more code onto the zone-fill code to
test and connect vias, tracks, and pads. Zone fill on my board takes
a few seconds, so a few seconds more should not be bad if it gives me
peace-of-mind that all my grounds and VDDs are connected properly.

Of course, I agree with you that pcbnew should be able to determine if
it can connect a pad/via/track to a zone without actually filling the
zone, but that seems to be a much more complex problem (and seems
isomorphic to writing an autorouter)...still IMHO better to get
something practical (if slow and hokey) until we have a new
zone-filling algorithm.


Why don't you add DRC support to gerbview? If you are listening carefully, you may have heard that the zone filling may not even be in Kicad in the near future and that we might move it to gerber file generation time. What about the free DFM site to test for your worries using the gerber files?

It is not that I don't understand your concerns. I understand every last one of them. But as I weigh *all* the costs and benefits, your idea is a dead end. I have about 20 copper zones on my board. I do not think it is appropriate to refill each time I drop a via into one of them.

This disagreement it probably large enough to be justification for a fork.

I might have bad eyes because i do not see here any disagreement...

To use the zone filling in connectivity calculations, only a volunteer is needed to create 2 or 3 functions which test zone segments connectivity. Tim, currently, you cannot be this volunteer because you have work about eeschema.
Dick i believe you are not volunteer (am I right ?)
And i am busy...

But if a volunteer exists, i could help it to start the work.

At this time what we need is good ideas, not code. Code will become after.

Using segments zone in connectivity calculations cannot be made in real time (because it involves refilling after changes.). So if new refilling + connectivity calculations is a matter of seconds, this is useable.
But if this is a matter of minutes, or much more ?
On my last board, zone refilling takes few minutes, not seconds.
So the first work for the volunteer will be to write a function to create a list of connected pads and tracks for a given zone filling. This function will be tested with large boards (more than 4000 pads, and more than 1000 vias).
I have such boards.
Of course, such boards have 4 to 20 (and more) zones (1 to 3 by layer)
So the computation time will be 4 to 20 the basic time relative to one zone.
If it is acceptable, we can put the code in pcbnew.
But each time a track is modified, the the caluculations must be remade.
So i am not sure using zone segments is better than the current way of work.
(Users must create tracks in zones, but (favour in return) they have a fast and reliable DRC)

Others problems (a crappy shape around pads and 45 degrees tracks ) will remain....
One of the critical problems is the filling algorithm uses a grid.
Now most of boards use small smd components, and the grid must be small.
But each time the grid size is decreased by 2,
the time calculation, the time to draw filling on screen, and the files size (gerber files and pcb files) are increased by 4 And boards which need small grid size have many layers, therefore many zones.

So the current implantation of zone filling has reached the practical limits.

On an other hand, using polygons can create excessive time computation (like using zone segments in DRC), but solves most of others problems, because this is a vectored approach of complex shape description (do not depend on grid size, and very few on the zone size). The problem is **only** we have a lack of knowledge about efficiency usage of them.
A fork does not solve this problem.
Only work, work and work is needed.

But please consider the current implantation of edges zones: polygons can be merged and broken into pieces... Algos currently in code can detected if 2 polygons are adjacents or overlapping (connected ?) and if a a point ( a pad ?) is in a given polygon. So we have a lack of knowledge, it is true, but we have also some knowledge about them.

And also we have some example in FreePCB and gpcb code.

But i have and other reason to want to use polygons:
In the near future we **must** use complex shapes in microwave applications (and, i think, in many other cases).
Some of these shapes can be described by polygons.
A good knowledge about them, and a good library to use easily them will be necessary.

if (one day) qucs uses pcbnew to create board this is the first thing which will be needed.

The good use of polygonal shapes in copper layer is mandatory for the future of pcbnew, that is to say of kicad.


Jean-Pierre CHARRAS

Maître de conférences
Directeur d'études 2ieme année.
Génie Electrique et Informatique Industrielle 2
Institut Universitaire de Technologie 1 de Grenoble
BP 67, 38402 St Martin d'Heres Cedex

Recherche :
46, Avenue Félix Viallet
38031 Grenoble cedex

Follow ups