On 09:52 AM 11/06/2001 -0400, [EMAIL PROTECTED] said:
>We are trynig to clean up our design process by, among other things, going to
>a convention where net names are local to a sheet and module ports are
>global. But I'm having trouble understanding how the attributes of a port
>interact, and how they are meant to be used to ensure a well-documented,
>ERC-able design.
I'll give it a go.
(I say to people working for me that net labels and port names should
almost always be the same. So even though we would often be designing for
Ports Only Global or even the stricter Sheet Symbol/Port Connection, we
would still have the same net label for all sections of a physical net. In
other words our designs, even when we have multi-channels, are almost
always able to be synched/netlisted as everything global or one of the
stricter settings. I have never been happy with hierarchical multi-channel
design support under Protel as there is the requirement to flatten the
design. The hierarchical design support seems only to work at the initial
Sch design stage and from then on it is not very useful. I do not know how
it links with the synchroniser but I can imagine that once you have
flattened and link a sch to a pcb then you will have to keep working with
the flattened design otherwise you will loose the hidden handle
associations. I have done no testing on this. I think Protel could provide
better multi-channel support by allowing use to include a component
renumber entity on a schematic sheet that would allow the sych/netlister to
know how many channels there are and by what increment or what
prefix/suffix should be added to each net/component. This would allow the
system to keep track of the sch/pcb hidden handles and prevent the need to
flatten the design.)
>1) Can someone explain what these port attributes do?
> Style
The shape of the port - no electrical effect at all, ignored by ERC. Would
usually be used when laying out the sch to indicate the direction of signal
flow. We use the bevel as an arrow that indicates signal flow.
> I/O Type
Used by ERC.
> Alignment
Text alignment within the port. No electrical or ERC effect.
>2) In this context, does "input" mean that the port acts as an input; i.e., I
>should be driving it with a signal on this sheet, with the destination on
>another sheet? Or does it mean that the signal is an input to this sheet,
>connected to one or more input pins on the sheet, and driven by some other
>sheet? Your perspective completely reverses the interpretation when you're
>looking at a port.
You can choose how you want it to behave - you just need a naming
convention and muck about with the ERC matrix possibly. Personally I think
of an input port as having to be driven by an output port. An output port
blows a signal to one or more input ports and an input port must be driven
by another port. An input port would drive an input pin on the same
sheet. An output port is driven by an output pin on the same sheet. (Yes
yes yes passive pins can drive output ports etc but I am skimming over some
derails.)
So for me, I would usually have an output port on the right of a sch sheet
with Style=Right (the bevelled edge acting as an arrow showing signal
flow), I/O Type=Output and Alignment=Centre.
>3) What determines which end of the port is the electrical hot spot? Both
>ends seem to be active.
Both are active. You only need wire to one end. Don't worry about the
unused end. I do not know what would happen if you wired to both with
disjointed wires? Doing a quick test suggests that both electrical hotspots
are logically connected (makes sense).
>4) With a netlist setting of Ports Only Global, is there any requirement to
>wire up the sheet entries on the next level up?
No. Port names are used to match nets across sheets with Ports Only
Global. We usually do a top level sheet and usually, but not always, wire
up the interconnections as it is useful to be able to show signal flow and
destination sheets clearly. (This is one area that being able to collect
random net names into a bus or "collection" of some sort would be useful as
top level are usually more cluttered than they need be due to all the
single nets that need to be pumped about but many of which can be grouped
into a set of peripheral control signals for instance.)
You should be aware the a net with a Port on it but no net label anywhere
will not take the name of the port as a net label. When you come to do the
PCB this can cause some pain. As the net is labelled with a automatically
generated name rather than a useful name. So I suggest that all nets that
have a port interconnections should also have a net name somewhere on them.
We would usually create a netlist or do a pcb synch with the tightest
netlisting option possible and confirm that the netlist is the same as an
everything global netlist/synch. We will always try very hard to use
unique net names throughout the design - it simplifies debugging and
test/repair heaps for us at least.
>5) Is it smarter to just use power objects instead of ports, and avoid all
>these issues?
No - at least I do not think so.
(I just noticed that ports can be vertical now - used only be able to be
horizontal - I think this is new in SP6, is that right?)
Hope there is something of use here,
Ian Wilson
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To 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]
*
* Browse or Search previous postings:
* http://www.mail-archive.com/[email protected]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
