Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.

[Abd ul-Rahman Lomax]

At 12:14 AM 2/14/2003, Ian Wilson wrote:
I know, Mike, that you get netlists often rather than P99SE sch so this is not always a solution, but the synch deals with the duplicate pins correctly, I think. I don't use duplicate pins (as it I don't like the risks), but I think others have stated that the sycnh is OK but netlist load has the oscillatory connect/disconnect behavior.

Yes, the oscillatory behavior has been discussed many times here, it is a known bug. The synchronizer does not suffer from this bug, it correctly handles duplicate pins (that is, duplicate pins are assigned the same net).

Protel probably did not catch the bug because the net list load works perfectly, same as the synchronizer, but only the first time the nets are loaded.

It's fairly easy to understand how this came about. The original netloader, as I recall, would assign a single node the net if there were duplicate nodes. We asked for the feature that duplicate nodes would all be assigned the same net. This is useful, for example, if you have an SMA connector with a 2-pin schematic symbol and the actual part has four ground pins.

So Protel gave it to us. Unfortunately, they did not look at what happens when the net list is reloaded. There was probably some routine in there which looked for duplicate pins and removed redundant connections. Anyway, reloading the net list causes all net assignments for duplicate pins to be reversed.

DEFENSIVE STRATEGY. There is a strategy which will catch this problem as well as another vexing one, the situation if a component is accidentally deleted. Since the component is gone, there are no unwired nodes to show an error.... Before concluding that a board has no errors from a clean DRC, reload the netlist or run the synchronizer, being sure to preview the changes (this is automatic with the Netlist Load procedure, one must specify it with the Update command -- the synchronizer). If there are any changes which will take place, i.e., Macros are created, there is very likely a board error.

If one has used Netlist load for a board with duplicate pins, every load will generate macros. If you must stay with Netlist load, a macro should be seen for every duplicate pin that has a net assignment, removing the net. This is the desired and correct condition. If a macro is created to add any pin to a net, there is definitely an error. And, of course, if the routine wants to add a component, it is missing.

One remaining problem can be a little tougher: if a component is moved outside the workspace, and especially if the only nets assigned to the component are connected to power planes, I'm not sure about other situations, DRC may not find the missing connections. A quick check for the presence of out-of-workspace primitives: Select All and then Move All. When you pick up the selection and as it is dragged on the cursor, a box will appear that shows the extents of all moving primitives. If this goes to the edge of the workspace, you've got a problem.....

Does DRC now report as a warning primitives outside the workspace? It certainly should, there is no condition where that is not an error. (It would be a very bad design practice to deliberately move stuff outside the workspace and leave it there. Once in a while the fact that Protel *will* allow such primitives to be created can be useful, so I'd not want them locked out.)



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *