The four steps work without failure, every time. I do not trust a netlist load without clearing first because as we all know we don'ts know which cycle even or odd the load is on.
Sure we do. Just look at the macros. If they all remove net nodes, ywe have a correct netlist loaded, do not execute the macros. If they all add net nodes, we should execute the macros. This will be *much* faster than Clear/Load.
If there are some adds and some removals, we have mixed assignments, and we should either edit them manually to the identical state, then confirm with another netlist load to macro stage, or we would use Clear/Load. But the former is probably much faster. (Note that we can simply set all the involved pads to No-Net, by selecting them all and using global edit, then load and execute the macros.)
Even if we wanted to reload the entire net list, we could avoid the problem of the unassignment of nets to non-pad primitives by Clear by globally editing all pads to No-Net, then loading the netlist and executing. We would very likely avoid having to run Reconnect. (and we would know, because if we needed to do this, there would be errors on DRC; if we have DRC set to stop with a modest number of errors, we could test for this condition before running the full DRC, which can be time-consuming with large designs.)
Mr. Reagan seems to have responded often in this thread as if I was telling him that (1) he should use the synchronizer, and (2) he is not familiar with the synchronizer. The first I have never said; for one thing, he often does not even have the option, and if the sychronizer is too slow with very large designs, the netlist load option may indeed be the best even if he does have a Protel schematic, in which case the bulk of what I have written, which is about *how* to use it, would be relevant. The second assertion may or may not be true; it was stated as a possibility consistent with what he has written, not as a fact; and the cause of this unfamiliarity, I would speculate, would be his need to use Netlist Load for most designs.
The possibility remains that, even with large designs, the synchronizer would work more quickly under conditions that might be controllable by the user. I don't know. We only know that it was slow under the conditions of use by Mr. Reagan. It also seems that it is slow only on initial load, but that too is speculative for me, based on my recollection that Update is very fast when there are only a few changes.
I would be glad to provide you with a very large design that chokes Protel and makes snails pace look like a rabbit. Viewing time for a backplane pcb takes upwards of 1 hour just to bring it up on a 600 Mhz machine, Of course upgraded our pcs just handle large designs like these. A fresh netlist import can take 4 - 6 hours. After using the synchronizer on medium designs , we gave up on that avenue about a year ago. I m not shaking my doodads by stating my boards are bigger than anyone else's but I do know the synchronizer, will choke for days when we attempt to use it. Simply reloading the netlist over a current netlist will take an entire day maybe until the next morning. We cut that time down to about 4 hours by clearing first. I am not exaggerating as I would be glad to provide you with as many different designs as you would like to attempt to load.
I'd love to look at some examples. Mr. Reagan probably knows this, but any database should be cleaned up before zipping it up and sending it. I.e., empty the trash and compact the database. I will appreciate it if the file is zipped, and I would prefer it to be available by ftp rather than as an attachment. Really large attachments *might* have difficulty with my service provider. If necessary, I'll create some public ftp space or make other arrangements.
Mr. Reagan also knows that I learn more when I am wrong....
But I just tested the synchronizer on a 1000 pad design (yes, I know that this is *much* smaller than what Mr. Reagan is faced with) -- which was fully loaded already --, and it took a fraction of a second to operate to the macro stage. Executing two macros took no visible time. (The two macros were oscillating, but not like what we have been discussing, there was an Add and a Remove macro generated for the same pad and net. This appears to be harmless, but I have never found what causes this.) I had most of the options disabled except for Update Component Footprints and Delete Components. If large designs take a long time, I would speculate it would be because they exceeded a certain threshhold, perhaps due to available memory or some other difficulty. If the computer starts paging to disk, it's going to take forever! If his designs are large enough, he might need a *lot* of memory.
Now, Update Free Primitives is going to take a long time, so it should be avoided if possible. It is often possible to avoid it if there are only a few changes.
I used Load Netlist for the same design and it seemed to take about the same time to discover that "Netlist has not changed."
I then Cleared out all nets and reloaded the netlist. It took about three seconds to load. Then I ran the necessary "Update Free Primitives..." command and it took about thirteen seconds plus another few seconds "Anaylzing Ground." This is a process that I would expect to take a long time with large designs, it may be exponential. But Mr. Reagan is forcing himself to run that process by clearing and loading....
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *