While there is a chance that we can chalk some or all of this off to
"operator stupidity", here is one big problem, and a few related little

I've got a 9.5 x 9.5 inch 6 layer board, with all 4 internal planes being
power and ground (23 little split plane islands), and all of the circuitry
routed on the 2 external layers.

Additionally, I have 6 "Polygon Planes" covering the top and bottom of the
of the board, which "pour" around existing routing and "fill" the open
areas, all going to relevant grounds.

I have spent an exhorbanent amount of time to add "stitching vias" in these
polygon "ground" planes. where I would place a track on the top layer
outside of the perimeter of the board, edit the track and assign it to net
GND, and then select and copy a tented via of the proper size, and with the
grid set to .250", use E P (edit paste) to put vias on the track at .250
intervals, which, because I am using E P, would all correctly assume the net
of the track that I was placing them on, GND. I would then select the entire
line of vias, without the track, and copy them using E A (paste array)
keeping the net name, on to the board, in rows, one  at a time, also spaced
at .250", but checking each row as I proceed to delete any of these
"stitching vias" that fall into the wrong area, or cause shorts, or other
problems. Once I completed this process for one ground plane area, I would
do a global edit on my "string of vias" outside the board and change the
nets to GNDI, one of my analog grounds, and repeat the process in that area
of the board.

Problem here is, that as I have been working on the board, the engineers at
another company, for whom I am doing the board, are making some subtle
changes. They do their schematics in OrCAD, but I only have an older version
(7.2), so we are doing all changes by importing netlists, which has been
working fine.

Very large Polygon Planes, especially when there mixed with large amounts of
routing, or other "obstacles", appear to have the ability to bring Protel to
its knees.

I learned this on faster machines now on 866 Mhz P3), where even with a much
smaller board, and faster machine (2.2 GHz P4), it would take Protel up to
20 seconds to recover, "analyze GND", and redraw a screen from a simple
thing like deleting one of these "stitching vias", when Polygon Planes were

Anyway, I 've learned by this that I do not want to put the "Polygon Planes"
into the design until the last possible minute, because of the way that they
overload Protel.

Problem is that I have one Precision Oscillator (TXO) which has two possible
sources and two possible packages, and hence I have a "dual footprint", and
because of this, I have "copper" in the "component part" in PCB Lib, which
means I need to do an "Update Free Primitives From Component Pads", after
updating the board by importing a new netlist with changes.

This was no problem in doing this prior to adding the Polygon Planes to the
top and bottom layers.

Anyway, after adding the Polygon  Planes, I do an "Update Free Primitives .
. .", and it takes forever, and appears to have gone south, and I check with
"Task Manager", and it reports that Client99se is "Not Responding", so I
kill it and try again. This was the problem of repeated "crashes" that I had
a week or two back when I had DXP eat my backup file.

Anyway, I tried deleting the Polygon Planes on the outer layers, figuring I
can just take an extra 10 minutes and add them back in, and the "Update Free
Primitives . . . " works properly, and correctly updates the copper on the
TXO, but this time, since the polygon planes were not present, it lost the
net names of all of the hundreds of "stitching vias" that I added.

I can partially understand this, and almost accept it, since the vias are
copper, and not directly connected to a component pin, but they were in fact
directly connected to split planes that do in fact have defined net names.

I will call this Bug or Buglet number 2.

Bug or Buglet number 1, of course, is Protel going "south for the winter" on
the "Update Free Primitives . . ." in the first place.

Ok, so I have shipped the board, and convinced the engineers to ignore the
DRC Errors associated with the "connected copper" on the "dual footprint".
But now I want to find out what happened.

I make a copy of the database, load it in, and do an "Update Free Primitives
. . .", and just simply walk away. I come back in a half an hour, and it is
still sitting there, I hit "Close" on the "Netlist Manager" dialogue box,
and it just sits there, so I walk away again. I come back in another 10
minutes, and it cleared the dialogue box, so I look at the TXO footprint,
and it is updated. GREAT!

So I close the database, without saving it, and start over, and this is what
I found after another 7 or 8 tries:

1.) After Selecting "Update Free Primitives . . ." from the "Netlist Manager
Menu", and then answering Yes to the "Update . . ." question box, Protel
turns off the main menu (turns the text from black to gray), and states
"Selecting connected copper . . . ESC to cancel" in the status bar, and just
sits there appearing to do nothing.

2.) After about 22 seconds, the "Selecting connected copper . . ." message
begins to blink, and a percentage counter appears in another portion of
status bar, and begins to count, and a "progress indicator" appears at the
left on the status bar. This continues until about 3 minutes into the

3.) After about 3 minutes, Protel just sits there, and does absolutely
nothing, although it still has the main menu "turned off" (set to gray
instead of black), along with the blue bar at the top of the window.

At this point I have done several different things, some of which I have
done several times.

A). Waited for a while, until 4 minutes 20 seconds, and then checked the
Task Manager, which stated Client99se Not Responding, but I did not abort
the process, I simply closed the Task Manager, and waited until 6 minutes,
and hit the "Close" button on the "Netlist Manager", which actually did
close after about 30 more seconds, and left me in an operational Protel 99
SE session, but without having fixed the TXO footprint. Needless to say,
time shutdown and reboot.

B.) Waited several different time periods ranging from 6  to 20 minutes on
the overall timer, and then hit the "Close" button with varying responses
ranging from immediate closure, to taking several more minutes to close, but
always levying me in an operational Protel 99 SE session, but never again
correctly updating the TXO footprint.

At this point in time, I have not been able to duplicate the correct
operation of "Update Free Primitives . . ." which happened the first time I
just walked away and let it run (and am even beginning to wonder if I
imagined it).

I am however convinced, that in spite of the Task Manager saying that
Client99se was "Not Responding", given enough time, it actually does come
back to life.

Problem is, it is not doing what it is supposed to be doing.

Anyway, how far can I really trust a process that goes "south" to the point
where Task Manager says its gone "south"? Possibly the appropriate time to
ask "Would you trust your "data" with this program?"

Other problems that have appeared here on this board, which I consider a Bug
or Buglet, since I have to try and convince the customer that Protel
actually made a mistake and it is OK to ignore the DRC on this one, as he is
looking at me with a weird look, and I am saying "common, trust me . . .",
are as follows.

I have two 192 pin BGA's, one 957 pin BGA, and twelve 24 pin BGA's, on which
ALL pads go to a "via", with the exception of those that are directly
connected to on the top side of the board by a trace that goes somewhere

Since this board is somewhat of a "proto" board which is being used to prove
out the operation of some 1 GHz ADC's and a big Xilink FPGA operating at 500
MHz, I have assumed that any of the pins might be required to be accessed at
any time, to add, change, or fix something, and as a result, I have
intentionally left all of the vias attached and in the design, even though
they are not in the schematic or netlist. This results in these items being
listed as an error in the DRC. This is a major annoyance, and I wish there
was some way of eliminating these from the DRC, but since they do not have a
net name (they are all "No Net", they are kind of hard to assign to a class
and say ignore). Maybe there is an easy one around this one which doesn't
require me to put several hundred little lines and "testpoints" or some such
on the schematic. I would welcome being called "stupid operator" on this
one, if there is an easy way out.

The other one that bit me here, has bit me on several different times in the
past, but I am just getting tired of having to explain to people that even
though Protel thinks its an error, and marks it as a DRC error, it really is
not an error, and saying "just trust me".

Whenever you have a via or hole in close proximity to a "split plane"
boundary, Protel flags it as a DRC error, when it really is not. Example: In
the current board, I am splitting a plane directly under the MAX104 BGA's.
This is being done by outlining the "split plane" with a 20 mil track. The
vias in the BGA "via farm" are located on 50 mil centers. Each via has a 25
mil pad, 13 mil hole, 10 mil plane clearance, with no thermals.
What Protel is flagging as a DRC error, is the vias and "track" which
separates the planes, and which is really not a "track" at all, but a void
in the copper. Please note that this is a "Violation" and not a "Warning"

The last of these little "gotchas" is that DRC is flagging a number of
traces, under the heading of "Broken- Net Constraints", with the "Warning"
that says "Connection to overlapping split planes". Now firstly, I know it
says "Warning" but that is just after it says "Violation", which is hard to
explain to someone else, but secondly, none of these signals are connected
to any of the "overlapping" plane segments, but only connected to things
located "over" those segments.

I think what it is trying to say is that I have taken a "trace" over a break
in a plane, which would actually be a nice warning if it were true, but the
problem here is that the "break in the planes is what might be called
"subterranean", in that it is only on the innermost planes, and actually
hidden under another plane, and therefore not relevant to the signal anyway.
Let me explain. I have a ground plane, which has routing over it, and has
several smaller broken up voltage planes under it, so that each BGA can have
its own clean isolated and filtered supply. None of the signals are routed
to the supply's, and none of the signals ever directly cross any break in
any planes themselves (they are actually isolated from the breaks in the
planes by the solid ground plane). I know Protel is just trying to warn me,
but it is not only improperly listed as a "Broken-Net", and a "Violation",
it actually does not even apply. Maybe we should just chalk this one up to
"software stupidity"

The real problem is this. Even though these people are only paying me fifty
cents an hour to do this job, it still represents a sizable investment for
them and it is very hard for me to explain to them that even though Protel
says that I made 642 errors on the board, that I really didn't make 642
errors, and the board is OK to build, and Protel just doesn't know what it
is talking about.

OK, so I also have about 22 edgemount SMA connectors, where I have the
copper going to within 5 mil of the edge, which is responsible for a few of
those 642 DRC errors.

Many of these problems would be much less of a problem if there were some
intermediate way to work with some of these things, without totally
disabling everything in the rules.

This would be a nice place to have the ability to "tag" or "flag" an item in
the design, and have it not keep showing up in my face every time I (or the
customer (who also has Protel)), runs a DRC.

It would be even better to have all of these things work properly.

I simply find it very hard to have to explain all of this to the customer,
when I do not think I should have to do so. The poor engineer at the
customer company actually sat there with his own copy of Protel and had do
go down the whole list one DRC error at a time, before he felt that it was
safe to send the board out for a quote.

Minimally, some of these are produtivity "buglets", but on the other hand, I
really would like to know where Protel goes when it "goes south for the
winter" and the Task Manager says Client99se is "Not Responding".

Respectfully submitted,

JaMi Smith

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

Reply via email to