Passive makes sense on connectors. I too would not actively label each one based on 
the signal. What a pain that would be. However, I think a passive connector pin tied 
to an input pin should suppress a warning message from ERC.

Are you saying you get warnings/errors in that case?

Tony


On Tue, 19 Aug 2003 15:59:09 +1000, Damon Kelly wrote:
>?The connector is a 96-way Eurocard type.
>?The schematic symbol has all the pins as "Passive", since on some
>?boards the signals go OUT, and some IN.
>?I may have to bite the bullet and make separate sch. symbols for
>?each board, depending on function...
>?It might be a PITA having half a dozen 96-way Eurocard connector
>?symbols though, each with different pin attributes, which is why
>?I'm looking for a more robust solution (if there is one).
>
>
>?Damon Kelly
>?Hardware Engineer
>
>
>>?-----Original Message-----
>>?From: Tony Karavidas [mailto:[EMAIL PROTECTED] Sent:
>>?Friday, 15 August 2003 12:26 To: Protel EDA Forum
>>?Subject: Re: [PEDA] Unacceptable Bug in Protel 99 SE SP6..!
>>
>>
>>?Don't you show the connectors leading to the bus? Wouldn't they
>>?be the source of the address on your peripheral cards and
>>?therefore you shouldn't have any "Unconnected Input Pins"?
>>
>>
>>?On Fri, 15 Aug 2003 08:49:02 +1000, Damon Kelly wrote:
>>
>>>?I have been designing some bus-based cards (with a processor
>>>?card, ?and other peripheral cards), and have the problem that
>>>?on many of ?the other cards, the address signals (in
>>>?particular) have no ?"outputs" (they come from the processor
>>>?card). ?This causes lots of "Unconnected Input Pin" type errors
>>>?(I can't ?remember the exact wording).
>>>?While I can live with that, I worry that I'll miss a _real_
>>>?error ?in the mass of spurious ones.
>>>?Any suggestions on a robust solution, not based on No-ERC ?
>>>?directives?
>>>
>>>
>>>?Cheers,
>>>
>>>
>>>?Damon Kelly
>>>?Hardware Engineer
>>>
>>>
>>>>?-----Original Message-----
>>>>?From: Abd ul-Rahman Lomax [mailto:[EMAIL PROTECTED] Sent: ?
>>>>?Friday, 15 August 2003 07:03 To: Protel EDA Forum ?Subject:
>>>>?Re: [PEDA] Unacceptable Bug in Protel 99 SE SP6..!
>>>>
>>>>
>>>>?At 05:09 AM 8/14/2003, Edi Im Hof wrote:
>>>>?It's also a good idea to set the ERC a bit tighter. [...]
>>>>
>>>>
>>>>>?On intentionally left open pins, I place a "no erc mark" on
>>>>>
>>>>>
>>>>?it. Keystrokes
>>>>>?p-i-n, witch is easy to remember because you'll place them
>>>>>?on a ?pin.
>>>>>
>>>>>
>>>>>?I have found quite a lot of schematic errors this way.
>>>>>
>>>>
>>>>?I'd like to underscore this. Especially when one is new to ?
>>>>?Protel, and is
>>>>?faced with a host of mostly phoney errors, it's tempting to
>>>>?set ?the ERC to
>>>>?tolerate open pins and type incompatibilities. And it's a bad
>>>>??idea.
>>>>
>>>>
>>>>?As to unconnected pins, when you deliberately leave a pin
>>>>?open, ?it is very
>>>>?simple to place a No-ERC directive on it. You'll never have
>>>>?to ?look at it
>>>>?again. And if you forget to do this, you'll get a warning and
>>>>?you ?can quickly and easily fix it. The large majority of
>>>>?schematic ?errors leave an unconnected pin.
>>>>
>>>>?Years ago, designing with mylar and tape, I had an engineer
>>>>?who ?used to
>>>>?take a design and quickly go over it for unconnected pins.
>>>>?Even ?on a complex multilayer design (complex for those days
>>>>?might have ?meant 6 layers), it was easy to see this. And
>>>>?then he'd make sure ?that they were
>>>>?all properly unconnected. He'd find the bulk of errors very ?
>>>>?quickly with this....
>>>>
>>>>?As to other errors, many types of pin type combinations will ?
>>>>?generate an
>>>>?error with the default matrix. The best solution may be to
>>>>?fix ?the pin
>>>>?types, i.e., make, for example, a connector pin be an input
>>>>?or an ?output or
>>>>?passive instead of I/O, which doesn't like to be connected to
>>>>?an ?output.
>>>>?But this is not always practical. so, once again, it's simple
>>>>?to ?place
>>>>?No-ERC directives, though in this case I'd wait until running
>>>>?the ?first
>>>>?ERC. If it is easy to understand why an error is popping up,
>>>>?it ?may be
>>>>?relatively safe to suppress it with No-ERC, but if it is at
>>>>?all ?unclear,
>>>>?the safe path is to figure out why the error is happening.
>>>>?You ?might just
>>>>?find an error. And once you know, and it is not practical to
>>>>?fix ?it --
>>>>?i.e., the error is purely formal -- then it should be
>>>>?suppressed. ?It only
>>>>?takes minutes at most to deal with even a host of connector
>>>>?pins.
>>>>
>>>>
>>>>?The goal is to generate a clean ERC report. Ideally, No-ERC ?
>>>>?markers would
>>>>?not be used, but practical reasons make us very glad that the
>>>>??primitive
>>>>?exists: at least we have made a conscious decision that a ?
>>>>?particular "error" or warning can be disregarded, and the
>>>>?markers ?allow us to avoid
>>>>?having to make this decision with every revision of the
>>>>?schematic.
>>>>
>>>>
>>>>?The cost of a schematic error can be very high, both in terms
>>>>?of ?money and
>>>>?in time-to-market, so it's worth the effort to learn to use
>>>>?the ?error-checking tools to best advantage. In the end, it's
>>>>?easy, ?the difficulty is only in the beginning....
>>>>
>>>>?It's too bad that Protel 99SE does not have editable pin
>>>>?types at ?the schematic level: Tango DOS allowed this.... (In
>>>>?Protel, pin ?types are only
>>>>?editable in the Library editor.) What I'd have liked to see
>>>>?would ?have been
>>>>?a symbol attribute that is "Allow Pin Electrical Type Edits."
>>>>?If ?checked in
>>>>?the library, the pin types would be editable at the schematic
>>>>??level. If
>>>>?not, they'd be locked. So a connector symbol, generally,
>>>>?would ?have editable pin types. And then the error checking
>>>>?could get ?even better. I'd
>>>>?also like to have a way to quickly see the pin type of a pin.
>>>>??(Again, this was easy in Tango DOS).
>>>>
>>>>?Has any of this been done in DXP?
>>>
>>>
>>>?* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>>?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] * *
>>>? * * ??* * * * * * * * * * * * * * * * * * * * * * * * * *
>
>
>?* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * *
>? * * * * * * * * * * * * * * * * * * * * * * * * * *




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

Reply via email to