More thoughts on schematic and DRC errors:

Sometimes your EDA system is just too complex (or not complex enough
depending on how you look at it!).  For instance Mentor Graphics shows
DRC errors when in fact none exist.  An example - text. MGC sees a piece
of text as a rectangular box and if you cut the corner of that box (even
if the letter is an "o" or "i") it will flag an error.  Another example
(for us) is coax connectors (5 pin where the 4 corners are ground,
middle is the signal).  MGC doesn't like the 4 corner pins connected (at
least the way our stuff is set up) so it flags an error.  It's just an
idiosyncrasy (sp?) of the system that you learn to live with and work
around.

I agree with Paul that the errors should be addressed and fixed if
possible.  If you don't address them you always run the risk, like
Abdulrahman said of having a real error in the midst of all the
"ignored" ones.  We really try to get all the errors out, but sometimes
it just ain't possible.

I really feel for you folks that have to use the "crappy" inputs.  At
least we can kick it back and say fix it or we won't do it.  Sometimes
it helps to have a boss with guts (at least part of the time).

later....

Ben Davis
[log in to unmask]


Paul Anderson wrote:
>
> Some more thoughts:
>
> It seems to me that the problems detailed below have arisen in PCB design systems out of control.  I
> apologize if that sounds harsh but let me explain the characterization.  By out of control, I mean that
> certain process rules either were disregarded or not in place or perhaps misunderstood.  For a PCB design
> system to be "in control",  the mandate needs to come from the top - if for nothing else but design
> efficiency.  Management must understand that cutting corners only serves to cost more money in the long run
> by forcing the organization to deal with mistakes further down the line rather than up front.  A design
> flaw costs somewhere around 10 times more to remedy with each design milestone it passes undiscovered.
> Design process control trickles down from library management, to design entry, to ECO control, to
> understanding the significance and impact of design rules, to understanding the idiosyncrasies of the EDA
> tools, to checking for and eliminating the common design pratfalls that come up,  to continuing to evaluate
> and enhance the design process, and a whole host of others too numerous to mention.
>
> On a note specific to Mr. Lomax's and Ms. Amerson's difficulty below, "If it works" can either mean that
> the engineer got lucky or his design constraints were too limiting or he didn't have a handle on their
> efficient use.  Further,  I'd point out to the engineer,  in a self-effacing, humble, and yet pragmatic
> tone, that going back and making his schematic updates on the debugged version of schematics might be a
> little less time-consuming and therefore less costly.  Though I wouldn't say it out loud, I shouldn't have
> to RE-FIX his errors.  Keep the faith.
>
> Boy was that rant cathartic!
>
> Abdulrahman Lomax wrote:
>
> > One is that sometimes the exigencies of a project make it necessary to put
> > a board into production even when the schematic or PCB generate lots of
> > "errors" or "warnings." If "it works."
> >
> > The other thought is that this should never be done unless it is truly an
> > emergency. It makes more work for everyone later on.
> >
> > A schematic or board that generates dozens or hundreds of DRC errors and
> > warnings (I just got a schematic from a customer that generated about 150)
> > may well have a few real errors buried amidst all those. One can take the
> > time to track down each one of them and verify that it is only a formal
> > error, not a "real" one, but next time changes are made to this schematic
> > or PCB, those errors and warnings will pop up again. It is far superior, if
> > the time is available, to fix them so that one gets the blessed "no errors
> > or warnings" message.... And perhaps so that the next schematic.
> >
> > So it is generally worth the time to identify why the errors and warnings
> > are popping up, and fix it. Maybe the DRC rules need to be modified. Maybe
> > schematic library parts need to have pin attributes changed. Whatever, it
> > is worth the effort.
> >
> > Another application for that zapper:
> >
> > The engineer sends me one of those schematics full of errors. I fix them
> > and send the schematic back to him, telling him about the corrections. He
> > says, "fine," and I go ahead and design the board. Then he says, "Oh, I
> > have some changes, quite a few of them." And the new schematic he sends me
> > was made from the error-laden version, not the corrected version I returned
> > to him.
> >
> > [log in to unmask]
> > Abdulrahman Lomax
> > P.O. Box 423
> > Sonoma, CA 95476
> >

################################################################
DesignerCouncil E-Mail Forum provided as a free service by IPC using LISTSERV 1.8c
################################################################
To subscribe/unsubscribe, send a message to [log in to unmask] with following text in the body:
To subscribe:   SUBSCRIBE DesignerCouncil <your full name>
To unsubscribe:   SIGNOFF DesignerCouncil 
################################################################
Please visit IPC's web site (http://www.ipc.org) "On-Line Services" section for additional information.
For technical support contact Hugo Scaramuzza at [log in to unmask] or 847-509-9700 ext.312
################################################################