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