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

Reply via email to