> -----Original Message-----
> From: Dennis Saputelli [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, September 26, 2002 9:28 PM
> To: Protel EDA Forum
> Subject: Re: [PEDA] Bug / Buglet
> 
> 
> 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 copper 
> 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 

Except for broken nets that are contained within a split plane
definition. I should check to  see if that got fixed in DXP.


 
> 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 correctly
> 
> 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 independently 

Once Jami removed the poly, those vias somehow lost their netnames. I
could see how they would not have any netnames in the first place IF he
has placed them before the poly, but after the poly was deleted, it
baffles me as to why the vias didn't keep their nets.

Anyway, if those vias don't have netnames, any following poly pour would
not attach to them and he is stuck using 99SE. If Jami tried DXP, he
could use a query  (ObjectKind = 'Via') And (Net = 'No Net'). Oh, of
course, do the same thing in 99SE with global editing: Jami why not
select one of those no-net stitched vias and use the regular global
selection to select all vias that are not assigned to a net? Once you
have them selected, assign them to the net name of choice? If there are
mutiple regions, keep selecting all of them and deselecting the ones
outside of a given area. 

I think one thing you could try is to put a temporary keepout on the
poly layer under the TCXO and then you could have repoured the poly to
get out from under the TCXO and kept all your vias intact. Then you
could replace the TCXO and grab net from attached, then remove the
keepout and repour the poly.

Yeah, I don't do my polys until the very end, as you discovered.
 

> 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 me 
> 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 properly
> 
> 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
> 
> -- 
> ______________________________________________________________
> _____________
> www.integratedcontrolsinc.com            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:
* 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/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to