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

> 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
> 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
> 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
> 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
> 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
> 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
> presence of out-of-workspace primitives: Select All and then Move All.
> 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
> 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:
* 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