At 11:26 AM 6/9/01 +1000, Geoff Harland wrote:
>Protel should *not*
>contemplate removing support for split planes (and should even *still*
>contemplate acting on a previous suggestion of mine: that the capability be
>provided for split plane polygons to reside *entirely* within other split
>plane polygons).
I want to underscore what Mr. Harland has written. Split plane support
should have been provided for nested planes from the beginning. It is not
more difficult to define copper affiliation with nested planes than with
regular distinct planes, it is merely a different alogrithm.
An algorithm description (skip between *** if this stuff is not of interest):
***
I'd use a line crossing algorithm; to determine the affiliation of a point,
one would scan all points with, say, the same y coordinate, beginning with,
say negative infinity (or perhaps workspace edge, but no reason to not use
the minimum x coordinate of all primitives, and the latter would be safer).
A "scan" is a sorted list of all nodes and boundary crossings with a given
y coordinate. The node locations exist in the database; the boundaries will
usually need to be calculated from intersection with the polygon segments.
When a split plane edge belonging to a new split is crossed, the current
affiliation (which begins with default net affiliation for the plane layer
itself) is pushed onto a stack and the current affiliation becomes that of
the polygon entered. With the affiliations, current and stacked, a polygon
identifier is also kept. Crossing the boundary of a split which is current
causes the removal of the current affiliation, which becomes what is on the
top of the stack. Crossing a boundary which belongs to a polygon in the
stack other than the current polygon causes the removal of that polygon
from the stack; but [a set of nodes assigned since the previous boundary
crossing will become ambiguous]. When coincident boundaries are crossed,
any polygon whose boundary is crossed at that point is removed from current
or stack. If only a single boundary remains among those which were
coincident, the affiliated net and polygon become current. If more than one
boundary remains subsequent nodes are marked as pending, belonging
potentially to any one of the involved polygons. When another boundary is
crossed belonging to one of the pending polygons, intermediate nodes are
assigned to that polygon and its net and that polygon is removed from
current and the list of pending polygons. When only one polygon remains in
the pending list, it becomes current.
If the next boundary crossing, while there are pending polygons, is
coincident for more than one of the pending polygons, there is a length of
the scan which is, so far, undefined. A simple solution, as with the
ambiguous condition above, would be to mark the polygons as illegally
coincident, asking the user to split at least one of them so that there is
not any ambiguity. (Double crossings would be relatively unusual and easy
to split; a tool could be provided that would automatically split the
polygons into unambiguous and ambiguous sections; the user would then edit
the ambiguous sections -- now independent polygons -- to specify the net to
which they belong. In fact, such a tool would be useful for other reasons
as well; right now there is no easy way to split a polygon into two
polygons without basically redrawing both.) It would be possible to
intelligently assign the ambiguous sections in some cases (basically, any
polygon which includes no area outside that of another is either
unambiguous, even if the algorithm described considers it so, or it is
coincident, which is an error condition.
I'm not satisfied with the completeness of this description, but that's
about as far as I'll go with it now.
****
Now, right now we could make a tool which would discover ambiguous sections
and split them; but Protel will not handle even unambiguous,
fully-contained nested split planes, and planes are calculated, so there is
no workaround. And as soon as I write "no workaround," the gears start
turning. It would not be easy, but it would be possible to write a tool
which would split the outer plane in such a way as to leave the inner
polyon uncontained, and *maybe* the segments that do this could be moved to
another layer or something like that so that the plane would plot properly.
But I'm not sure, I'd have to experiment some.
>The other desirable enhancement for Power Plane layers has been mentioned on
>assorted previous occasions, but for the record, I will repeat it now. It
>would be nice if the Design Rule checking procedure could detect (through
>hole) pads and vias which are disconnected from *other* pads and vias
>connected to the *same* net on each Power Plane layer (or in an extension of
>this concept, whenever the "quality" of each such connection is not
>compliant with a minimum standard defined by the user). But this is easier
>said than done, and I think that it is realistic to say that it would be
>more difficult to implement than supporting split planes being totally
>surrounded by other split planes on each of these layers. (However, the fact
>that it would not be straightforward to implement still does not alter the
>desirability of having it provided.)
I consider this improvement essential, in fact. It is a major hole in the
DRC process. Some solutions have been discussed in the past. One is to go
to positive-negative merges, requiring an explicit connection (positive)
with the negative planes merely filling out the space and being correct by
design (i.e., they are kept clear of possible shorts by design rule, and
they would *not* by themselves create any connections.) Another solution is
to use some of the autorouter code or another flood router to identify the
existence of paths of the required width between nodes, entirely contained
within the copper of the negative plane.
Going to a positive/negative solution would be better because it would also
have other uses, but best would be a combination solution:
positive/negative, and the positive tracks are added by an autorouter.
Among other things, this would completely solve the nested plane problem.
This would be the procedure:
(1) Place a plane polygon, similar to a copper pour. (In fact, the present
copper pours would become unnecessary). This plane would define all space
within itself, clear of other conductive primitives by design rule
distances, as copper, assigned to a net. But it would not itself connect to
any pads or vias. It would remain clear of pads and vias net-affiliated
with it by the thermal relief distance defined by rule. (Direct connect
pads and vias would likewise be clear by this distance)
(2) Automatically or by command, an autoroute routine identifies paths
contained entirely within the plane which implement any possible
connections to the plane. The thermal relief connecting spokes would be
added as necessary (or sufficient positive copper to direct-connect vias or
pads as required) and track would be put down connecting the spokes. If a
path cannot be found, the pad or via will not be connected, which will be
detected by DRC.
[EMAIL PROTECTED]
Abdulrahman Lomax
P.O. Box 690
El Verano, CA 95433
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/subscrib.html
* - or email -
* mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Browse or Search previous postings:
* http://www.mail-archive.com/[email protected]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
