At 11:26 AM 2/28/01 -0600, David W. Gulley wrote:
> Similarly, not understanding and validating the ERC errors
> is just like not reviewing the DRC errors.
The reality of today's design environment is a perception that there is no
time to fix all those phony "errors."
The old canard is "There is never enough time to do it right, but there is
always enough time to fix it later." Of course, sometimes it is actually
true. It may be better to send out the files today for a 1-day turn
prototype and clean up the mess later.
On a prototype one might well accept cuts and jumps, while, at the same
time, another is cleaning up the design. I've once saw a company fab
$10,000 worth of boards instead of waiting a couple of days for the next
revision, knowing that they would probably scrap the first lot, simply
because they needed a functioning product immediately.
On the other hand, that company went out of business shortly thereafter.
Probably a coincidence. :-)
I've also did a board capture and revision for a product that had been done
perhaps ten years earlier, on an unknown CAD system and all the files were
gone and the films discarded. My first task was to make a Protel file that
was an exact replica of the original. In doing so, I uncovered a number of
schematic errors. It is clear that the original board was not checked
thoroughly to its schematic. Now, this board went into an elevator
controller and was installed all over the world. It worked, obviously. But
one of the errors left an open CMOS input. That's the kind of thing that
can cause mysterious intermittent errors. Or maybe even a single incident,
when someone stands with their cell phone close to the controller....
It is ideal, of course, to identify and correct every schematic error so
that the ERC is clean. Open input warnings, once one has verified that the
pin is intentionally open, should be suppressed with a No-ERC Directive.
When I am drawing schematics, as soon as I place a part with a deliberately
open pin, I place the directive on the pin's active spot .
Sometimes there is an error or warning that can be difficult to eliminate,
and the project still needs to be done. Once the net list is verified, it
may be acceptable to suppress the error. But in the long run, it would be
best to find out why that error was reported, and fix it, if possible.
[EMAIL PROTECTED]
Abdulrahman Lomax
P.O. Box 690
El Verano, CA 95433
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This message sent by: PROTEL EDA USERS MAILING LIST
*
* Use the "reply" command in your email program to
* respond to this message.
*
* To unsubscribe from this mailing list use the form at
* the Association web site. You will need to give the same
* email address you originally used to subscribe (do not
* give an alias unless it was used to subscribe).
*
* Visit http://www.techservinc.com/protelusers/subscrib.html
* to unsubscribe or to subscribe a new email address.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
________________________________________________________
To leave the EDAFORUM discussion list, send a email with
'leave edaforum' in the body to '[EMAIL PROTECTED]'
