Re: [PEDA] Strange behavior on unconnected pins
Fabian Hartery wrote: Hi Everyone, I have some real strange behavior going on with the dreaded hidden pins. These are being assigned sub-nets and are showing global netlist behavior where none exists. That means, a floating terminal of part 1, pin 2, is shown associated with pin 2 of part 2. I would have suspected that a parts definitions are held in a 'local' definition and not a global one. I can't see an applicable rule affecting this, unless there is a rub in the protocol of creating a netlist. Hidden pins will be assigned to a net containing all hidden pins of the same name in any component. This is one of the hazards of using hidden pins. Hidden pins are intended to be used for power and ground, which you normally would want connected on all components. DO NOT use hidden pins to represent unused or no connect pins, or Protel will connect them all together. -- Peter Bennett TRIUMF 4004 Wesbrook Mall, Vancouver, BC, Canada GPS and NMEA info and programs: http://vancouver-webpages.com/peter/index.html * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Strange behavior on unconnected pins
On 01:08 PM 14/03/2001 -03-30, Fabian Hartery said: Hi Everyone, I have some real strange behavior going on with the dreaded hidden pins. These are being assigned sub-nets and are showing global netlist behavior where none exists. That means, a floating terminal of part 1, pin 2, is shown associated with pin 2 of part 2. I would have suspected that a parts definitions are held in a 'local' definition and not a global one. I can't see an applicable rule affecting this, unless there is a rub in the protocol of creating a netlist. Hidden pins always imply global connectivity (same as power objects). You can't change it - all you can do is never use hidden pins and make your life easier and better documented. Regular readers will know that I am being very constrained as this whole hidden pin thing is one of my *major* hates. It traps new users over and over again. As I have said before all of Protel's vaunted ISO9000 libraries use hidden pins so what chance of there being a change to their behavior? But I do think that the tide is turning and Protel would do well to take note - hidden pin connectivity should be an option and should be OFF for new installations. They can then deal with the whole library issue with copious notes, warnings, erc errors and humble apologies grovelling all the time while whipping one-self with a birch and bellowing I have sinned. Hidden pin connectivity is a crime against humanity. I can also report that parts created with multilayer pinning create keep out zone for components on both sides of the pwb. This means for example, you cannot place a coupling cap underneath a DIP part without encountering a DRC component spacing error. At least, that is what I have found. There is a difference in keep out zone Protel assumes and ones you can actually edit. This is very much a shortcoming. This one can be fixed. In the Placement design rules have a look at you component placement rules and I bet you will see they are set for a quick check. if you change the check from Quick to either Multi-layer of Full you will not get errors as you describe. So a bottom side surface mount component will not be flagged as fouling with a top side through-hole component and visa-versa. Ian Wilson Fabe Guigne International Limited Paradise, Newfoundland * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Strange behavior on unconnected pins
At 01:08 PM 3/14/01 -03-30, Fabian Hartery wrote: I have some real strange behavior going on with the dreaded hidden pins. These are being assigned sub-nets and are showing global netlist behavior where none exists. That means, a floating terminal of part 1, pin 2, is shown associated with pin 2 of part 2. I would have suspected that a parts definitions are held in a 'local' definition and not a global one. I can't see an applicable rule affecting this, unless there is a rub in the protocol of creating a netlist. I'm not sure what is meant here. Hidden pins always create global nets, just like power ports. The behavior is not alterable except by unhiding the pins. Never hide an unconnected pin. Instead, either delete the pin from the symbol (assuming that it is a genuine no-function pin, though some of us would say to always show all pins, functional or not), or show it and place a No-ERC directive on it to suppress the unconnected warning. I can also report that parts created with multilayer pinning create keep out zone for components on both sides of the pwb. This means for example, you cannot place a coupling cap underneath a DIP part without encountering a DRC component spacing error. At least, that is what I have found. There is a difference in keep out zone Protel assumes and ones you can actually edit. This is very much a shortcoming. For those of us who have been using Protel for a longer time than the life of 99SE, the component clearance rules are an addition, nor a shortcoming. Until quite recently, we had no component clearance checking. It is not a mature feature. For example, it should be possible to define a negative clearance, which would allow a defined overlap. If the overlay outline of a part is drawn at MMC, DRC will consider the part outline to be MMC plus half the track width of the outline. So parts which are butted together, which is fine if the outline is MMC, will display a clearance error. It should be possible to suppress this easily by allowing a negative clearance equal to half the track width. As to the situation described by Mr. Hartery, I have generally turned off component clearance checking. But I would think that if one defines component classes for top and bottom components, one could set the clearance rule so that top components were checked against top components only, etc. But I have not actually tried it. There should be a quick way to make top and bottom component classes and assign them to already placed parts. Anyone know one? [EMAIL PROTECTED] Abdulrahman Lomax P.O. Box 690 El Verano, CA 95433 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Strange behavior on unconnected pins
Thanks Peter. This is what I expected. It's unfortunate the library I have is inherited from another designer via a PCAD import. I do not like the hidden pins issues either. I usually display them. It would be prudent for Protel to include a override, allowing unconnected pins to remain hidden. By default, hidden connectivity could be left enabled. It certainly would reduce the seen snow on schematics. Practically, this could be achieved in the pcb library editor with a No Connect option in the otherwise No Net option box. Fabe Fabian Hartery Guigne International Limited Paradise, Newfoundland -Original Message- From: Peter Bennett [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 14, 2001 5:08 PM To: Protel EDA Forum Subject: Re: [PEDA] Strange behavior on unconnected pins Fabian Hartery wrote: Hi Everyone, I have some real strange behavior going on with the dreaded hidden pins. These are being assigned sub-nets and are showing global netlist behavior where none exists. That means, a floating terminal of part 1, pin 2, is shown associated with pin 2 of part 2. I would have suspected that a parts definitions are held in a 'local' definition and not a global one. I can't see an applicable rule affecting this, unless there is a rub in the protocol of creating a netlist. Hidden pins will be assigned to a net containing all hidden pins of the same name in any component. This is one of the hazards of using hidden pins. Hidden pins are intended to be used for power and ground, which you normally would want connected on all components. DO NOT use hidden pins to represent unused or no connect pins, or Protel will connect them all together. -- Peter Bennett TRIUMF 4004 Wesbrook Mall, Vancouver, BC, Canada GPS and NMEA info and programs: http://vancouver-webpages.com/peter/index.html * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Strange behavior on unconnected pins
At 11:44 AM 3/15/01 +1100, Ian Wilson wrote: There should be a quick way to make top and bottom component classes and assign them to already placed parts. Anyone know one? Design|Classes click Component tab, click Class Generator - take it from there. Never tried it myself. From the Component tab, one must press the Add or Edit button before getting a Class Generator button. Way cool! Sometimes I wonder if there is any single person who knows all the nooks and crannies of this program. Probably. But he isn't talking Actually, the class generator is mentioned on p. 541 of the manual. It's easy to overlook. And this is one big reason why I read this list and write for it. [EMAIL PROTECTED] Abdulrahman Lomax P.O. Box 690 El Verano, CA 95433 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Strange behavior on unconnected pins
On Thu, 15 Mar 2001 09:09:41 +1100, you wrote: On 01:08 PM 14/03/2001 -03-30, Fabian Hartery said: Hi Everyone, I have some real strange behavior going on with the dreaded hidden pins. These are being assigned sub-nets and are showing global netlist behavior where none exists. That means, a floating terminal of part 1, pin 2, is shown associated with pin 2 of part 2. I would have suspected that a parts definitions are held in a 'local' definition and not a global one. I can't see an applicable rule affecting this, unless there is a rub in the protocol of creating a netlist. Hidden pins always imply global connectivity (same as power objects). You can't change it - all you can do is never use hidden pins and make your life easier and better documented. Regular readers will know that I am being very constrained as this whole hidden pin thing is one of my *major* hates. Yep we heard it - I have used hidden power pins without issue in every design I have done since Orcad SDT version 2 days. I have actually had more hassle with shown power pins on multipart components where the parts move around on annotation (duplicating power pins on each part is yuk, and how do you justify showing the same pin 4 times on a schematic?). Also hassle with things like op amps where there is no space to label the power pins and the typical convention of +ve supply at the top and -ve at the bottom may have to be broken. The only dumb trap people can fall into is making a schematic part with all pins and calling all the no connect pins NC and hiding them. If power supplies are not straight forward then it takes about 30 seconds to make a copy of the schematic part with power pins showing. As for showing no connect pins - it is about as useful as adding a few ficticious components to the schematic and marking them as not fitted and nothing to do with the design? Elsewhere in this thread Ivan Baggett said [Off topic] I also hate assembly language code written with macros. Same concept (hidden code). It makes it very difficult to figure out what's really happening. This is quite telling, and actually exactly wrong - macros and hidden code make it easy to figure out what is going on - that is the whole point of using them and the founding principle of all Object Oriented Languages. We have a limited capacity to deal with complexity and the complexity of problems and hence solutions is increasing all the time. The most succesful way we have come up with for managing complexity involves organising it into lumps which look simple from the outside. This specifically involves hiding of information. The point is hiding information is not inherently bad - it is powerful part of information management. Cheers, Terry. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Strange behavior on unconnected pins
Hi Terry, sorry, but I do not at all agree with you. As for showing no connect pins - it is about as useful as adding a few ficticious components to the schematic and marking them as not fitted and nothing to do with the design? These pins are not fictitious and have everything to do with the design. May be it is not absolutely necessary to show them in all cases, but it is helpful for checks. For example I defined some weeks ago in a library a northbridge which exists in 2 versions: with and without an additional PCI bus connection. Some 60 pins of the 480 pin BGA are defined as NC in one version, as signal pins in the other. I find it explicitly useful to show them as unconnects in the version without second PCI bus. Elsewhere in this thread Ivan Baggett said [Off topic] I also hate assembly language code written with macros. Same concept (hidden code). It makes it very difficult to figure out what's really happening. This is quite telling, and actually exactly wrong - macros and hidden code make it easy to figure out what is going on - that is the whole point of using them and the founding principle of all Object Oriented Languages. I am just a hardware designer, so I would never dare judging the founding principle of Object Oriented Languages. But I spend hours with a logic analyzer searching for strange effects happening with microcontroller port pins, just because my software colleague swears he never touched that pin setting in his code, but it changes state when it should not. He was right, the code he had written himself was clean, but the macros written by someone else touched it. Macros and hidden code make it easy to figure out what is going on? I doubt it, as far as hardware-related software is concerned. But may be you did not notice that Ivan was talking about assembler. IMHO this is not an Object Oriented Language. ;-) Regards, Gisbert * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Strange behavior on unconnected pins
On Thu, 15 Mar 2001 12:41:43 +0100, Gisbert wrote: sorry, but I do not at all agree with you. As for showing no connect pins - it is about as useful as adding a few ficticious components to the schematic and marking them as not fitted and nothing to do with the design? These pins are not fictitious and have everything to do with the design. May be it is not absolutely necessary to show them in all cases, but it is helpful for checks. For example I defined some weeks ago in a library a northbridge which exists in 2 versions: with and without an additional PCI bus connection. Some 60 pins of the 480 pin BGA are defined as NC in one version, as signal pins in the other. I find it explicitly useful to show them as unconnects in the version without second PCI bus. Hmm, An old example - what about those 14 pin DIL reed relays some of which have all 14 pins on the package and some of which have the 3 middle pins on each side physically removed? Should I show pins which have been physically chopped off by the manufacturer? Would it make any difference on other parts if the NC pins were physically chopped off or not? This is quite telling, and actually exactly wrong - macros and hidden code make it easy to figure out what is going on - that is the whole point of using them and the founding principle of all Object Oriented Languages. I am just a hardware designer, so I would never dare judging the founding principle of Object Oriented Languages. But I spend hours with a logic analyzer searching for strange effects happening with microcontroller port pins, just because my software colleague swears he never touched that pin setting in his code, but it changes state when it should not. He was right, the code he had written himself was clean, but the macros written by someone else touched it. Macros and hidden code make it easy to figure out what is going on? I doubt it, as far as hardware-related software is concerned. The guy who wrote the macro or the guy using it did a bad job. The macro was doing more than it was supposed to, or it was insufficiently documented or the guy using it didn't check what it was supposed to do. The sharp knife/blunt knife argument - when someone cuts themselves with a sharp knife the answer is not to only use blunt knives. Cheers, Terry. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
