DESIGNERCOUNCIL Archives

September 1998

DesignerCouncil@IPC.ORG

Options: Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
DesignerCouncil <[log in to unmask]>
X-To:
Abdulrahman Lomax <[log in to unmask]>
Date:
Wed, 30 Sep 1998 19:01:10 -0400
Reply-To:
"DesignerCouncil E-Mail Forum." <[log in to unmask]>, Paul Anderson <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
Content-Type:
text/plain; charset=us-ascii
From:
Paul Anderson <[log in to unmask]>
Parts/Attachments:
text/plain (104 lines)
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:

> At 03:42 PM 9/29/98 -0400, JoAnn Amerson wrote:
> >I want to know which one of you designing gurus out there are going to be the
> >one to design that implant that's used on shoddy designers?  The one that
> >gives them a "zap-a-roony" for turning in a design chock for of DRC errors.
> >Would you let me know when it's commercially available?  And can you make
> >one that can be inserted in a supervisor who allows said design to slide
> >because "it works"?  Can I get a discount for buying multiple units?
>
> Get me a purchase order, we'll design the PCB.... :-)
>
> Two thoughts:
>
> 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
> ################################################################



--
                        Have a Golden Day,

Paul Anderson
[log in to unmask]
http://www.amherst.com/

################################################################
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
################################################################


ATOM RSS1 RSS2