> 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/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to