the windows task manager is not as smart as you or i would like it to be

sometimes the 'not responding' is correct and it really is all over and
sometimes it is not correct and a process is just taking a while 

i wouldn't be too eager to do the 3 finger salute

i recently had several 'crashes' (task manager not responding) when
doing a select inside operation
i went through the kill operation, sometimes reboot etc.

i finally tracked it down to a stupid logo on the board which had a
bazillion fills on the silkscreen
the select inside just didn't like that, even though it wasn't analyzing
i deleted the logo and all was fine and i'll just put it back at the end

sometimes the online DRC or the netlist load lights up problems that are
not for real, just cancel, reset drc markers and that trust what you
have done is correct for the moment and run a real DRC at the
appropriate time later when you have reviewed the situation and
corrected real problems if any

i too have had many frustrating iterations of load the nets, clear the
nets, learn the traces, load the nets, but in retrospect it seems that
many times i was just trying too hard

it's not a perfect world but i have found that the 'real' RUN DRC is
very accurate 

the poured polygons can be troublesome in this regard but they actually
work better than the software would sometimes lead you to believe

as to your connector DRC errors from what i read they sound real or
possibly need a rule to be created 
or your dual footprint may need a dual schematic object to correspond

i think deleting the pours is a mistake as a solution as it compounds
the errors as you have noted

you don't need to pre-edit the vias with the net name just paste no net
vias onto netted names and they will acquire the right net, even a
string of no net vias pasted onto various nets will get the various nets

as to 26 splits ...
i am far from an expert in this area but that sounds pretty extreme
a designer much smarter than i with whom i have worked recently assured
that in the end there really is only one ground and if necessary you
control circulating 
currents and potentially polluting currents by means of 'cuts' in the
plane as opposed to full splits in the plane

these cuts are simply traces (non copper) on the plane in the proper
spots and have the effect of localizing the current flows if applied

high speed traces should not cross either the cuts or splits as is well
known EMI issue

i have had problems with copying the database file, be careful with that
as it seems to refer to files in the original database, in particular
loaded netlists

if you are compelled to make a fresh start make a new empty database
file and drag files into that

Dennis Saputelli

JaMi Smith wrote:
> 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
> ones.
> 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
> involved.
> 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
> session.
> 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
> else.
> 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

___________________________________________________________________________            Integrated Controls, Inc.    
   tel: 415-647-0480                        2851 21st Street          
      fax: 415-647-3003                        San Francisco, CA 94110

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to