Abdul, I have no doubt the syncronizer works but it doesnt work for me when my 70 percent of my customers are using Orcad and the rest are using Viewlogic. I have no use for the syncornizer. I am really screwed because they took this capabiltity away in DXP now the program works like PADs. These programs are like buying a Porche look alike for the same price, why dont I buy the Porche. Yea I know Im going to hear it from everyone how well it works in DXP. Well we can take that discusion offline at [EMAIL PROTECTED] It dont work good. I have , or run into many situations where duplicate pins are neccessary ie Dual patten parts and BNC connectors, pin 1 is signal then four other pins become gnd (pin2), Personally, I dont like to use them either, but I need flexibity to output a design without alot of hassle. Cheap, Fast, and Good. So once in a while, duplicate pins are required. I avoid them at all cost because, Spectra doesnt like them either.
The Oscillotory effect isnt really a bug the way I see it. The way I see it , Protel has their documentation wrong. If it said " clear the nets" before you load another one , there would be no effect hence no bug. There is a bug with the syncronizer , its called time. Clear takes 1 minutes vs .....taking a smoke break for the syncronizer to crunch. Mike Reagan EDSI > 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://email@example.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *