kicad-developers team mailing list archive

[jean-pierre charras <jean-pierre.charras@...>]

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.
> >
> > thanks,
> > Tim
>
> 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. 
>
> Dick
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 :
GIPSA-LIS - INPG
46, Avenue Félix Viallet
38031 Grenoble cedex