Here's our current documentation for this. Please let me know if it's unclear on any of the points that have been discussed.
http://www.protel.com/resources/learningguides/articles/ connectivityandmultisheetdesign.pdf
Connectivity is discussed, of course, in the 99SE manual and in Mr. Magennis's book. The document Mr Scribner has referenced, however, is clearer, in my opinion. Further, it introduces some nice DXP features, such as control over whether or not hidden power pins produce global or local nets and an Automatic scope that selects the scope based on the presence of primitives that demand a certain scope. This does address Mr. Velander's comment about how he wants a Sheet Entry to do something, not just sit there useless, if he has placed it. In Automatic scope, the placement of a Sheet Entry automatically sets the scope to Sheet Entry/Port Connections. If there are no Sheet Entries in the project, placement of a Port sets the connectivity to "Ports Only Global," and if there are no Ports, connectivity is set to "Net Labels Global."
"Net Labels and Ports Global" is kept in DXP as a scope for legacy designs, and a new primitive, called an Off-Sheet Connector, is introduced, which is kind of like a Port that connects across a group of sheets, not just to a single Sheet Entry above. The group of sheets is controlled by reference in the Sheet Symbol above, i.e., a single sheet symbol can now refer to more than one schematic sheet.
In theory, at least, it is well done. Frankly, these changes alone could be powerful motivators for some users to upgrade to DXP. I haven't upgraded, by the way.
Here are my comments, page references are to pages in the document.
p. 1. The term "net identifiers" to refer to the various relevant objects can be a little confusing. Some of these primitives do not establish a net name, rather they function like a wire. Ports and Sheet Entries do not assign any name to the net; what they do is to make a connection between primitives of the same name (in the case of Sheet Entry/Port combinations, the connection is restricted to connection between the Sheet Entry and the Port on the named sheet, not to other Ports of the same name that might be elsewhere in the project). They function just as if you ran a wire between the sheets; as you know, wires don't control the net name.
p. 2. Again, the explanation of Net Identifiers and Scope, first paragraph, is not precisely true. "the only way to pass signals between sheets in a project is with net identifiers." A person reading this casually will assume that a "net identifier" is something that names a net. Once we define "net identifiers" as pseudo-wires following certain rules, it becomes true.
"These are objects that will make logical connections with one another..." The difference between Sheet Entries and Ports should be explained. Sheet Entries do not "make logical connections with one another," but rather only with subsheet Ports, and only if the connectivity is set to Sheet Entry/Port Connections." Automatic scope takes care of this in DXP, but in 99SE, one needs to know this.
p. 3. There is a diagram here which is unclear. On a single sheet:
Diagram 1 shows three nodes connected together with wires.
Diagram 2 shows them connected together using Net Labels.
Diagram 3 shows them connected together using Ports.
Diagram 4 shows them connected together using Power Ports.
Diagram 5 shows one node connected to a Net Label, one to a Port, and one to a Power Port, all having the same name.
What is not explained explicitly is that the nodes are not all connected together in the net list which will be produced from Diagram 5. A Power Port creates a global net with the name of the Power Port, a Net Label creates a name likewise, but a Port never creates a name. So in diagram 5, the node connected to the Port ends up hanging unless that port connects to something somewhere else.
The text says that this diagram "illustrates a common misconception: that a net identifier will logically connect to a net identifier of a different type, so long as they share the same name. In fact, the opposite is true: different kinds of net identifiers may have distinct names, but still be wired together to form a single net." This is true, of course, but has been explained in an upside-down way.
What would make all this clear is an explanation of how net names are assigned. If one knows how net names are assigned, one should have a good understanding of what will be connected together, since if two net segments have the same name, they will automatically be connected together. How names are assigned depends, sometimes, on the connectivity scope.
(I'm just writing this without testing everything, for the most part, so if you are reading this to learn about connectivity, check to see if anyone has corrected me in subsequent posts.)
Power Ports are Global-Always Net Labels, so they always give the net their name. I'm assuming in this discussion that ERC shows no net-renaming errors. I haven't tested what happens when there is a conflict.
In a Flat Structure, with Net Labels and Ports Global:
If there is a Net Label anywhere on a net, the Net takes the name of the Net Label. If there is no Net Label and no Power Port, the net -- in 99SE -- is given a name derived from one of the nodes in the net, probably the one first encountered in processing. Older versions of Protel may have simply given such a net a number.
In a Flat structure, with Ports Only Global:
If there is a Power Port on a net, the net is given the name of the Power Port
If there is a Net Label on the topmost sheet containing the net, the net is given the name of the net label. If any Net Labels are only on subsheets, the net is named from a node on one of the sheets where it occurs.
To repeat this, in Ports Only Global, as in Sheet Entry/Port Connections, Net Labels do not name nets unless they are placed on the topmost sheet where they occur.
Note that Ports never give their name to a net, under any scope. Sheet Entries are the same, obviously (since Sheet Entries are only the top side of a Port in a hierarchy). Sheet Entries have no electrical or naming function in any scope other than Sheet Entry/Port Connections. This is why Altium was able to create an Automatic scope in DXP that sets Sheet Entry/Port Connections whenever a Sheet Entry is present in a project.
In a Hierarchical structure, with Sheet Entry/Port Connections: This is the same as Ports Only as far as naming is concerned.
A sheet entry can be though of as one end of a wire going from the sheet on which it is found to the sheet named in the Sheet Symbol which contains the Sheet Entry, where it connects to any Port with the same name. The net does not take on this name.
I remember some of us complaining about this, but it is absolutely necessary if Sheet Entry/Port connections are to function properly in all situations. If you want to name a net in a hierarchical schematic, put a Net Label somewhere on the net in its top-most occurrence. You could also put a Power Port anywhere on the net on any sheet. As long as you check for "Multiple Names on Net" in your error check, this would be safe.
(Note that Multiple Names on Net does not detect all multiple names, only those that create naming conflicts. For example, two different global labels on the same net.)
I have not discussed Off-sheet Connectors, having no practical experience with them, but the manual seems pretty clear. I'd assume that they are like Ports, they would not assign a net name but only establish connectivity according to their function.
Now, there is one more detail that is not well explained in the manual. The information is there, as is usually the case, but it is easy to misunderstand.
Here is the relevant paragraph, it is talking about a bus:
"Notice that the logical bus is created by the net label, not the bus primitive. The electrical function of the bus is to connect these net identifiers. Remember that net identifiers of different types do not automatically connect to one another, even if they have the same name. This holds true for net identifiers with bus syntax; a net label D[0..7] will not automatically connect to a port with the same name. The bus is required to connect them together.
"The rest of the bus -- that portion which extends towards the individual nets, is important for graphical reasons only...."
Now, many of us have stated many times that bus wires are eye candy only. The one exception is detailed here, and it has been very easy to overlook it, except that if you tried to use busses in hierarchical schematics and did not understand the exception, you probably have a dent in your wall the same shape as your forehead.
Remember, Ports and Sheet Entries do not assign a name. When one is placing wires to a Port, no problem. Wires establish connectivity indpendent of names. But when you are trying to use a Sheet Entry/Port device to connect busses, how are the Port and Sheet Entry primitives to know what bus to connect to? It is very, very easy to assume that it will connect to a bus of the same name, as established by a net label somewhere on the bus. But, remember, Ports and Entries don't use their name to connect to other primitives of the same name, except to each other. The device that connects a Port or Sheet Entry to a bus's net label is the bus primitive, i.e., one must draw a contiguous bus connecting to the Port or Sheet Entry and place somewhere on it the bus Net Label.
Note that this arrangement allows the renaming of a bus, since the bus will be named on the topmost sheet where it occurs. The name of the bus on subsheets is not used. This kind of connectivity control is crucial for good, flexible design re-use. You don't have to go over subsheets taken from different projects to make all the busses have the same names.
One subsheet could have a bus named DATA[0..7], it connects to a port/sheet entry combination that takes it up the hierarchy, and then it can be named [D0..7] there, and it can go down to another sheet with whatever name is used on the other sheet, such as [IN0..7] or [IN7..0]. In this case the nets will be named D0 through D7 in the net list. You can have another bus on another sheet where a designer used [D0..7] and this bus can be completely independent.
As has often been the case, we may carp about features of Protel that are really its strong points, if we but knew. All of which points to the necessity for good technical writing, an often undervalued skill. Altium has obviously put a great deal of effort into the new documentation, it is definitely improved, but it could be better still.
One way to improve it is to watch the lists and see what misconceptions have arisen in the minds of designers. Sure, often we haven't read the manual, but it would be possible to write a manual that lists only common misconceptions. With a good index. My problem with reading manuals is that I often go to sleep reading over the obvious, eventually I pass over something that I really didn't understand or fall asleep.
Understanding the nuts and bolts of a program can really help someone like me to remember how to use it. In this case, the rules by which net names are established are not explained in the documentation, at least not in the documentation that I have seen. And knowing those rules, which are really pretty simple, makes the connectivity issues obvious and thus easy to remember.
The documentation says "if you want to do such-and-such, do this." What it doesn't say in such depth, usually, is "if the program encounters this situation, it will do such-and-such." Yet, of course, the first depends on the second. Programs work in a certain way and then tech writers figure out how to explain to a user what to do to get what they want, and that is quite often more complicated that what the program actually does.
In this case, we have a really strong preconception that leads us to assume that a Port named with a bus name should simply connect to that bus unconditionally, particularly when we've thought for years that "bus lines are only eye candy, it is the Net Labels that establish connections through a bus." So we think that the Port D[0..7] should connect to Net Labels D0 through D7 on the sheet where the Port is found. I hope that no one reading this is still confused on this!
How about a document called "Ten easy ways to get confused about Protel"?
What else would go in it? (If you answer this question, I suggest renaming the thread with a new name).
One more comment: Protel ERC treats net renaming, such as what happens when you put two different Net Labels on a single wire, as an error. It does still wire the nets together, which is good. That it treats it as an error is also good. I remember a nightmare OrCAD schematic where a series of schematics from different projects were cobbed together by renaming the nets on the sheets. It was a nightmare because it *usually* worked, but this was a complex project and there were several dozen nets that were left broken. Why? I explained it in an earlier post in this thread. First of all, the rules by which nets were renamed were less than clear, and we had no way to predict how the net would be renamed. But the designer had tediously gone over the schematic to ensure that even if a net had more than one name, it would still have no name conflicts with other nets that should be distinct.
But what happened was that a net pair, say D0 and DATA0 on one page would go off the page as D0, and on another page it would go off the page as DATA0. And sometimes there were even more than two possible names. It was truly a nightmare to track all these down, it delayed the project by weeks. And, as I recall, there were no ERC warnings.
I don't know how Protel chooses names when there is a conflict, but it should not be necessary to *ever* do this. If you know, drawing the schematic, how the net will be named, you will know what will connect! And it will be explicitly controlled by you.
(When a Net Identifier does not control the name, Protel 99SE assigns a name based on an included node, which is nice; for the purposes of this discussion, however, it might as well be a random net number, as long as it is unique. Since node names -- like U5-10 -- are presumably unique, the names should presumably be unique. But if you connect, for example, a duplicate power pin of two different instances of the same component to two different net labels, what happens? -- I don't have time to check it now. Will you get a net renaming error or other error?)
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
