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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *