At 06:53 PM 2/16/2003, you wrote:
Certainly in that case you must use Netlists. Otherwise the synchronizer (Update process) is generally superior.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.
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.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 don't know how DXP works on this, I've been a bit out of the loop lately....
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.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.
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 Oscillotory effect isnt really a bug the way I see it.
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.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.
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.)
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.There is a bug with the syncronizer , its called time. Clear takes 1 minutes vs .....taking a smoke break for the syncronizer to crunch.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
