Julian,

Went thru both of your emails (spliced below) trying to figure out exactly
what you were describing, and the best that I can come up with goes like
this: 1.) You have two split planes adjacent to each other on the same
layer; and 2.) You have one hole placed directly in the gap between the two
planes (or minimally directly on the edge of one of the planes), and 3.)
That hole is electrically connected to one of the planes, and 4.) That hole
has a thermal relief defined for its connection to the plane.

If I am understanding this correctly, this would have probably resulted in
the "spokes" of the thermal relief shorting both planes.

If this is the case, I am surprised that Protel did not flag it in your DRC.

It has always been one of my pet peeves with Protel in that it does not
handle vias or component holes correctly when it comes to "gaps" in planes,
since it has always been my experience that Protel seems to treat the "gap"
as a "trace" when it comes to doing DRC, and ignoring the fact that it is a
negative image or representation. By that I mean that whenever I have placed
a via or component hole near the edge of a plane, Protel would flag a
clearance error between the edges of the pads of the via or hole, and the
"trace", which in reality is not a copper feature at all, but simply a void,
and as such should not generate a clearance violation.

The reason this bugs me so much is that I did a whole series of little
boards which all had the same little microcontroller circuit on them, on an
isolated little island all of its own, packed in just as tight as I could
get it. Due to the analog and digital separation in one corner of the chip,
I had a tight little spot where I had to put a few vias right near the edge
of one of the planes (although not connected to any plane). Protel would
always flag this as a DRC clearance error, highlighting the "gap" (as if it
were a "trace") when in fact it was not.

In light of this behavior, I am really surprised that it did not flag it
(your problem) as an DRC error.

Is it possible that there is an "error" in your DRC report file that you may
have overlooked?

I would think that you might want to check to see if something is turned off
or set wrong in your DRC setup.

Respecting whether or not it is the vendors fault, I would say that that
depends on just what your gerber files told him to build. I can't think of
anything that he would have done wrong, unless you are paying him to examine
the design as part of the setup, and then you might have a case to say that
he should have caught it.

What does CAMtastic have to say about the situation? Just what do the
gerbers really look like.

In view of the fact that it has been a common rule of thumb in the industry
now for many many years that you should never put a via "in" a gap between
planes, I would vote on the side of the vendor and recite the Toyota Slogan
to you, where they say "you asked for it, you got it". If I remember
correctly, I think that I may have seen somewhere that Protel might have
even told you not to do this somewhere in their Manual or Tutorials.

If this were to be called a bug, I would say that it is only a small part of
a bigger overall problem that Protel has in dealing with "gaps" in planes
and DRC errors. I wonder if this been fixed or at least improved in DXP (I
may be able to import one of my older designs and see how DXP responds to
it, DRC wise, but that may not really tell anything since I have only
installed SP2 so far.

An example of another problem with the way Protel handles "gaps" in planes
and DRC, is the following: 1.) Take a 6 layer board, with all of your signal
traces on the outer layers 1 and 6; and 2.) A solid ground plane on layers 2
and 5; and 3.) multiple little split plane patterns for power on layers 4
and 5. This is exactly the way that I laid out my last Xilink Vertex II BGA
board, in 6 layers (2 routing, 2 ground, and 2 power) with a total of 23
different little "split plane" segments.

In the above example, if I run a long signal trace on layer 1 (or 6) from
one end of the board to the other, it will always have a solid ground plane
directly beneath it on layer 2 (or 5). But, and here's the problem, the
trace may in fact cross several "gaps" in the inner planes on layers 3 and 4
(which are physically and electrically NOT related to the signals on layer 1
(or 6)). Nevertheless, Protel insists on flagging all of these signal traces
as errors, since they cross an unrelated "gap" in an unrelated inner plane.

In the above example, there are those that would argue both sides of the
issue as to whether or not Protel was right in calling it a DRC error.

While I would not argue one way or the other on this one, I bring it up
because it is a perfect example to show how Protel really does not know how
to really handle the issue of "gaps" in "split planes".

Here again, some might argue that it is not really Protel's responsibility
to really understand the issue or say what is or is not an error, but only
to report it. Again, I would not argue pro or con on this one either, but
the whole point is that this is an area where Protel's DRC cannot really be
trusted to really understand what is going on, and properly flag something
as an "error".

As far as "gaps" in "split planes" in Protel are concerned, I would simply
say "caveat emptor", or possibly a little more appropriately, "you paid your
money, you take your chances".

In other words, the designer needs to be very alert about what he is doing
in this area, and be very very careful.

As to what to do with it now for production? I would suggest isolating the
component hole from the plane by putting a little ring (made from an arc of
the proper size and thickness) around it on all of the plane layers, and
then making the connection by means of a trace on an outer layer and
appropriate via (or two (depending on the current involved)) to the plane. I
use this technique to isolate "control line" types of signals where I am
routing a BGA or PGA, and I do not want to have the "pin" connect directly
to an inner power or ground plane where I cannot get to it to isolate it in
the event I need to change something either for testing or production, which
I can then do by simply cutting a little jumper trace on the opposite side
of the board and then hooking the signal up to where it needs to go.

These would be very good issues (both the problems with "gaps" in "split
planes", and also the "isolation" of a pin (or via) from "direct connection"
to an internal plane) to raise in the DXP Tech Forum, but it would probably
best be handled by someone familiar with Service Pack 3 and Service Pack 3
and a half (both of which I am not familiar with) since these things may
have been addressed by those intermediate fixes. As a side note, I guess
that they are actually are up to their sixth real Service Pack now, but are
just not wanting to really call it such. After the initial DXP Product
Release: There was SP1 Pre Release, and then SP1, and then SP2 Pre Release,
and then SP2, and then SP3 Pre Release, and now SP3 Pre Release "Build 104".
Yes I know I have been asking for Service Pack 7, but for Protel 99 SE, not
DXP. Better keep your ATS paid up to date, because it looks like we're due
for a "Second Edition (SE)" real soon here.

Speaking of "gaps" in split planes, and DRC "errors", I would like to see
the capability in DXP (and even Protel 99 SE) to inspect a DRC "error", such
as the ones mentioned above regarding the crossing of an unrelated plane
with a trace on the outer layer, and say: OK, fine, Protel, you flagged it
as an "error", but I want to accept it as it is, and somehow override the
"error" in the DRC process so that it does not keep showing up again as a
new "error" every time I run a new DRC. I would like to be able to "flag
it", or "check it off", and possibly even have the ability to add "notation"
(or possibly a code) to the DRC report file such as that this is accepted as
is because of such and such and so and so. These "flagged" or "checked" DRC
"errors" would then be relegated to a separate location in the DRC report
file, and would not keep showing up continually as new "errors" every time I
run a DRC. These "flagged" or "checked" (and accepted) DRC "errors" could
even be displayed in a separate color that is different than the standard
error color. This would give me as a designer a fighting chance of really
staying on top of what is and is not a real error, and what is acceptable
for such and such a reason, and to actually document things in the DRC
report file that would stay with the board or project "database(s)". I could
then narrow down the real errors, and not have to continually reinspect all
of the little places that Protel really didn't understand the problem, or
the places where Protel really did understand it but I want to do it anyway,
and get them set aside (or to the bottom of the file). This might be an
ideal candidate for a SDK "server" for Protel 99 SE, but due to the fact
that displaying a separate color (which should show up and be controllable
both in the color scheme dialogue and layer selection (on or off) dialogue)
for the special category of "flagged" or "checked" (and accepted) "errors"
would be such an important part of the feature, it would probably be better
to actually have it incorporated directly into DXP rather than written as a
separate SDK "server" for DXP. I guess I really should write this one up for
the DXP Tech Forum as a request, rather than just talk about it here. This
is really a simple concept, and should be real easy to implement, since all
of the errors are identified by a specific type and location, and it really
becomes a simple programming problem of looking for an identical string of
characters in a newly generated report and relegating them to a buffer and
then tacking them on the end of the report as "Previously Flagged And
Accepted DRC Errors".

One other final issue here. Why are you using a thermal relief type of
connection to your planes when you are using such a large BGA. The thermal
reliefs make such a disasterous mess of swiss cheese out of the planes under
a structure such as a BGA, and are really unnecessary. A typical BGA pattern
layout consiste of a "pad" for the BGA "ball", with a short "trace" (usually
referred to as a "dog bone" connection) to a "via" (although some people
refer to the entire structure of pad, trace, and via as the "dog bone"),
which then goes down to the inner structure of the board. In this case, the
"dog bone" connection, if it is kept to a moderate size, provides all of the
thermal isolation that is really needed to properly solder the "ball"
connection without the common heat sinking problem (thermally speaking) of a
"direct" connection to the plane. Do a little checking in your current
design. I'll bet that you have less cross-sectional copper in the "dog bone"
connection (trace) than you do in the total of all of the "spokes" of your
current "thermal reliefs". You might just want to check into this with the
people who are mounting your BGA's for you, to see just how much thermal
isolation is really necessary, which can probably be hadled completely by
the "dog bone".

One final note. before you go into production, you should really check all
of the connections in the planes that have thermal relief types of
connections, with a gerber viewer, or possibly look at the film itself, to
make sure that the "thermals" aren't causing some real "problems" in terms
of "cutting into" the available plane area under the BGA, and possibly even
isolating some connections. This latter issue is also something that needs
to be looked at in DXP (probably too late for Protel 99 SE), since it is
really very easy to chop up a plane so much with "thermal reliefs" that you
actually can loose a connection without even knowing it, since, as your
initial post points out, Protel really does not understand the problem here.

JaMi


----- Original Message -----
From: "Julian Higginson" <[EMAIL PROTECTED]>
To: "'Protel EDA Forum'" <[EMAIL PROTECTED]>
Sent: Thursday, May 29, 2003 7:51 PM
Subject: Re: [PEDA] quick question


>
> Just to answer my own question, before it even arrives in my own inbox:
>
> It looks like in the case where you have a primitive overlapping two
planes
> on a single layer, and connecting to one, that protel does its thing
*before
> you even get to the gerber stage* with plonking a thermal relief down on
the
> layer for that primitive.
>
> So essentially, it shorts the two split planes together, then DOES NOT
> DETECT they are shorted in a DRC.
>
> Chalk another one up to experience I guess.... I've never even heard of
this
> bug before, but I can guarantee Altium have.
>
> You know - I really don't mind the occasional bug in software, it happens.
> And Windows isn't the nicest environment to develop in... But what really
> does annoy me about these sorts of things, is if Protel maintained an open
> and honest bug list on their website that listed exactly, in a point by
> point list, the things you should not do with various versions of their
> software, it would be a lot easier to make a board 100% right first time
> with their software.... Maybe it's worth someone's time to make one up and
> host it somewhere (like the OrCad website?!?!?) since Altium seem so
> unwilling to help their own users navigate the collection of small, yet
> potentially very damaging list of bugs.
>
>
>
> Julian
> (d'oh!!!)
>
>
> --
> Julian Higginson - Design Engineer - Lake Technology.
> Suite 502/55 Mountain St, Ultimo, NSW 2007, Australia.
> Phone: +61 2 9213 9000 - Direct: +61 2 9213 9021
> mailto:[EMAIL PROTECTED] - http://www.lake.com
>
>
>

< SPLICE >


----- Original Message -----
From: "Julian Higginson" <[EMAIL PROTECTED]>
To: "'Protel EDA Forum'" <[EMAIL PROTECTED]>
Sent: Thursday, May 29, 2003 6:43 PM
Subject: [PEDA] quick question


>
> heh, well as quick as can be, on a mailinglist with an 8 hour turnaround.
> :-)
>
>
> I just had a 4 layer PCB made up...
>
> My very first BGA - a Virtex 2 pro.(I'm terribly proud of it!) It was also
> the first time I have ever used two entire layers for split planes
carrying
> power and ground.
>
> Anyway ---
>
> I have a header for programming a microcontroller on this board, and one
of
> the pins of this is meant to be connected to a 3.3V plane on the plane
> layer.
>
> This pin just happens to also overlap another plane (5.6V)
>
> I supplied a PCB file to my board manufacturer, and the board has come
back
> with a standard thermal relief placed around the power pin. As a result
the
> pin is connected to both power planes, and they are shorted.
>
> This is not a tragedy in itself as I can drill out the hole and wire power
> to the programmer as needed, and its only a prototype run (2 boards) but
I'm
> just wondering is this bridging planes with pins something that you should
> never do in protel, and is it something (else) that Protel just can't
> handle? or did my PCB manufacturer stuff up??
>
>
>
> Julian
>
> --
> Julian Higginson - Design Engineer - Lake Technology.
> Suite 502/55 Mountain St, Ultimo, NSW 2007, Australia.
> Phone: +61 2 9213 9000 - Direct: +61 2 9213 9021
> mailto:[EMAIL PROTECTED] - http://www.lake.com
>
>



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
*
* Browse or Search previous postings:
* http://www.mail-archive.com/[EMAIL PROTECTED]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to