> On Thu, 6 Dec 2001 16:22:34 -0800, Dwight wrote: > > >PERSONALLY, I don't find a couple extra pins per IC that cluttering. > > But what about gates, what does a nand SR latch look like with power pins? > Or big chips which might have 40 power pins? > > >I also > >find it easier to have the power net listed there than having to flip to > >another page (especially since that "flipping" is usually on a pdf file!). > >HOWEVER, much of this stuff IS personal preference -- to each his own! > > Unless you are the only one who is ever going to see the schematic I > disagree. Schematics distributed with products may have to be read by > hundreds or thousands of engineers for many years to come. > > Someone screwing up netlist generation a couple of times because they > didn't understand or check hidden power connections is not a good excuse > for making all those engineers suffer. > > Cheers, Terry.
A schematic file has the dual purpose of specifying assorted details required by the (associated) PCB file (the Designator and Comment strings and footprint of each component, netlist information, etc), *and* of documenting that PCB's circuitry to those examining the (schematic) file. Assuming that it is accomplished in an elegant manner, I would regard it as preferable, and even desirable, for schematic files to explicitly display all connections to Ground and Power nets. Even though engineers examining schematic printouts might not always be interested in such details, there can still be times when the provision of these details is desirable. My recollections of a DOS version of PCAD (version AD 2.0) are that it was "orthodox" to specify power and ground net connections to ICs (74HC00, etc) by the use of a distinct text file (whose contents had to comply with a specified format). However, unless the associated details were duplicated on the schematic files by text within a "lookup table" though, that meant that these details were not depicted on the schematic file at all (which I don't care for). My view (though I am well aware that others might not concur) is that it is desirable for schematic (file) components (or symbols in the terminology of PCAD AD2.0) for devices like a 74HC00 to have a fifth part for power and ground connections. That part can either be placed on the last page (of a set of schematic files) or the same page as (the majority of the) other parts of the same component are located on, depending upon the preferences of the engineer producing the schematic files (along with other factors, such as the specific nature of the circuits, etc). For multiple pin devices like microprocessors or programmable logic devices, which incorporate not just large numbers of signal pins, but also "significant" numbers of power and ground pins, either a "one part" symbol (containing both signal pins and power and ground pins) could be defined and used, or a "two part" symbol (with one part containing the signal pins and the other part containing the ground and power pins); again whether these parts were on the same page, or separate pages, would depend upon the designer and the nature of the circuits, etc. I suspect that at this stage, many will have deduced that I don't care too much for pins of a hidden nature. By default, the usage of this feature results in associated connections to power and ground nets not being visually documented in the schematic files. As I see it, depicting all pins (regardless of *where* these are depicted) fulfils both roles of a schematic file; both the PCB file and the viewer of the schematic file are informed of which nets these pins are connected to. Conceivably, an "intelligent lookup table" feature could be provided with the schematic editor, in which pertinent details of the associated text (within a schematic file) are "passed on" to netlist files and PCB files. Such an approach would also comply with both purposes of a schematic file, and in a manner which could well be preferable to many users. As I see it, that approach would avoid the requirement to (also) enter such data in the form of "non-intelligent" text, where the potential exists for the associated details to differ from what was specified by other means. (In other words, whenever something needs to be specified twice, there is the risk of inconsistencies between the data of each specification; hence the interest, in software engineering, of specifying code just once, etc.) As long as they are prepared to provide the associated time requirements, there is nothing to stop engineers from creating multiple sets of library files for the same components. For example, a microprocessor might be defined in one library file with hidden power and ground pins. In another file, the same device could again be defined with just one part, but with no hidden pins. And in a third file, the same device could be defined with two parts; the second part would contain the power and ground pins. An appropriate suffix could be used with each component to distinguish each of these types, e.g. _H for the single part component with hidden power and ground pins, _S for the single part component with no hidden pins, _D for the dual part component, etc. What could help in this regard could be the provision of some type of utility or addon server with which the user can specify all of the associated details *once*, with some type of wizard interface to make the procedure more "user-friendly". Once all of the details had been specified, the associated components would then be added, automatically, in an initial form, to *all* of the appropriate library files. At that point, the user could further edit the components within each of those files if so desired, e.g. to fine-tune the relative positions and orientations of each pin, etc. I created and sent this post not with the intention to troll, but to pass on my thoughts on this matter, and hopefully to stimulate further discussion. There is another matter I would also like to comment on concerning schematic components, to wit, being able to re-arrange pins (locations and orientations) within components within schematic files (as opposed to schematic *library* files). In DOS versions of Protel's schematic editor, that was possible, and it would be nice if that feature could be restored. Those versions of Protel also permitted users to change *other* properties of pins, e.g. pin number and pin type, and while I am *not* advocating that that aspect should (also) be restored, the restoration of the ability to re-arrange pins would still be desirable in many situations. As such, a *qualified* restoration of that aspect of those versions of Protel. Perhaps there is something to be said for being able to inhibit the re-arrangement of pins by adding a "locked" property to each part. When a part is locked, the pins can't be re-arranged, and that would cater for those who don't want that capability. (Is there something to be said for all pins to be restored to their default locations if an "unlocked" part is placed in a "locked" state again? And should the ability to unlock parts be "inhibitable" by means of some type of global/system setting? ...) I have other things to do for now, but let the discussions continue... Regards, Geoff Harland. ----------------------------- E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
