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

Reply via email to