At 06:53 PM 2/16/2003, you wrote:
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.
Certainly in that case you must use Netlists. Otherwise the synchronizer (Update process) is generally superior.

    I  am really screwed because they took
this capabiltity away in DXP now the program works like PADs.
Tsk, tsk. Allowing and processing duplicate pins is a simple solution to a common problem. It is much more cumbersome to create extra pins in schematic to match multiple pins on the PCB.

   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 don't know how DXP works on this, I've been a bit out of the loop lately....

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.
A utility that would expand on duplicates might be useful. I used to use a program I had written that would take a netlist and modify it according to a list of changes (kind of like the Protel macro process). Very simple. But it meant that I could, for example, take a two-pin -- on the schematic -- SMA connector and expand it to the five physical pins with the appropriate net assignments. Because it was a set of changes made by a human-readable list, I then could say to the engineer, "The board has been checked to your netlist except for the changes found in the attached file. Please verify that all these changes are appropriate and, if possible correct the schematic." This same program and process was used to swap gates, etc.

The Oscillotory effect isnt really a bug the way I see it.
It's a bug because it is unexpected behavior. We expect two netlist loads with the identical netlist to generate two identical sets of pad assignments. They don't, not if there are any duplicate pins.

    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.
No, there would be a bug with a workaround. The program was obviously designed to allow you to load a netlist into a board which already has one. What happens, by the way, to stitch vias or grounded mounthing holes when you clear the nets? Nothing, if you load the netlist without clearing first. Via and track assignments are not changed by netlist load, only component pads. So the workaround is not satisfactory. Instead one should use netlist load, and then reload and check for oscillating macros. It is fast and easy. If no macros are created with the second load, you are home free. If they are, then you need to clear out all duplicate pad net assignments and reload the net list, that is probably the simplest way to do it without clearing all nets.

It would be easy to generate a pad list in the spreadsheet, sort the pads in ASCII order, and then set up equality formulas that will flag duplicates. It would also be easy to write a small utility to clear out the net assignments of all duplicate pads. Usually, however, there are so few of these that it is simpler just to select them and then globally edit them to NoNet. In fact, you could do this with all pads, and then load the net list. All component pads -- with 99SE -- are given the correct net assignment on the first load.

(If one pad is correctly assigned to GND, say, and another with the same name is NoNet, netlist load will flip the assignments.)

There is a  bug with the syncronizer , its called time.     Clear takes  1
minutes     vs  .....taking a smoke break  for the syncronizer to crunch.
Well, perhaps on large designs, I haven't seen any really large designs recently. But, as I mentioned, Clear can wipe out some of your work if you use any primitives with net assignments that are not explicitly connected with positive copper to pads with that net.



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

Reply via email to