Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
At 09:07 PM 2/21/2003, Mike Reagan wrote: 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
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
Regardless of the board size the synchroniser DOES take more time than just generating a netlist import to PCB in the same design. My designs are not physically big, but pretty dense, and made out of many SCH sheets as we heavily re-use a lot of sheet 'blocks' for system level re-design block re-use. I have seen the synchroniser work well with most, but the bigger the amount of data it has to handle, worse it gets. I think it would be fair to say that the time difference indicates some more 'intensive' processing or query in data (as it looks up SCH database PCB database at the same time?) and this would be increased with design size and would get to a point that it would become unusable. The synchroniser also has other quirks (like it handling of 'unmatched' components, or especially renamed nets on ECO's) which cause it to choke, then eventually come back with an error. I like the synchroniser as a tool, but frequently after some failed ECO's using it, I still have to create a discrete netlist load into the pcb (without errors!) after that the synchroniser will be happier. The difference in behaviour of the synchroniser and the straight netlist method, as well as the additional parameters that can be set using the synchroniser would say to me that they are quite different tools. One parsing a netlist AND performing additional processing tasks (does not matter what they are really) so needing more environment resources, when the generate netlist method is purely a report tool. In any event I always generate a discrete netlist regardless of the forward/back annotation method used. Generating a discrete netlist also gives me the choice to use OTHER layout tools instead of Protel as sometimes Protel just cannot do the deed efficiently enough (auto jumper insert, autoroute, large designs to name a few). Best Regards John A. Ross RSD Communications Ltd 8 BorrowMeadow Road Springkerse Industrial Estate Stirling, Scotland FK7 7UW Tel +44 [0]1786 450572 Ext 225 (Office) Tel +44 [0]1786 450572 Ext 248 (Lab) Fax +44 [0]1786 474653 GSM +44 [0]7831 373727 Email [EMAIL PROTECTED] WWW http://www.rsd.tv == -Original Message- From: Mike Reagan [mailto:[EMAIL PROTECTED] Sent: Saturday, February 22, 2003 2:07 AM To: Protel EDA Forum Subject: Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6. back and forth, so the following is more likely to reflect on Mr. Regan's unfamiliarity with the synchronizer, .. Abdul 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. We even killed Spectra with two designs. Further, the clear process is unnecessary. Our Clear, load, connect, run drc method has come to us thru long coffee breaks while waiting for Protel to catch up. I'm not knocking the program, because I have never used any other program for designs this large therefore, I don't know how they would respond either. I would imagine any program would be slow, its alot of stuff to remember. Both the netlist load and synchronizer, will go off to Thailand before the pc responds to any options, We cant tolerate that as we have lost too many man hours waiting. We hit Cntl ALT Del then tried another way in until I found out four step recovery program (joke)I found clear to speed things up, the difference in load times dropped from minutes vs hours on medium size boards with maybe 1500 components Connect Copper... WellYou are sort of right .. you may have to do a little work , re-assign split planes and polygons, when you use the connect copper command. The DRCs will catch it, it is the last of my four steps to recovery. 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. Mike Reagan * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
I am more interested in whether you think everyone should always use netlist import. Ian, If you don't ever have to port to third party tools then the netlist isn't important, I guess. But on the other hand I made a good case how useful it is to trouble shoot a designs for single nodes, broken nets, split busses, defining differential pairs. But then if used a little program to scrub my netlistthat would be third party tool isn't it? Mike * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
At 09:27 PM 2/20/2003, Mike Reagan wrote: . 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. Nah, Nah Abdul Clear will not wipe out any of your work. Load the netlist again, run connect copper, run drcs. Mike, read what I wrote -- and you quoted -- again. Connect copper will not assign the net to the described primitives. What is it supposed to do, read your mind? Connect looks at copper primitives in contact with pads; if the pads are assigned a net, Connect will assign that net to them, and it does this recursively until all contacted primitives are assigned the net. Since there are kinds of primitives which may not be explicitly connected, but rather are connected through a plane -- which depends on net assignment -- these primitives, upon clear, will lose and not regain their net assignment. Stitch vias and grounded mounting holes are two examples. You might place the mounting holes on the schematic and make them footprints -- I usually do -- but only a maniac would place stitch vias on a schematic. If a copper pour is connected to a plane with stitch vias only, well, see below. The regular plane vias would also lose their assignments except that they are connected to component pads and so, with Connect, pick up the net assignment from them, plus Protel does not really clear out all net information; the names, and, apparently, the net assignments of inner planes remain, and these names are used to reassign the planes to the same net. Every wonder why the Stack Manager names the planes, at least by default as, for example, GND (GND). You can name the planes differently from the net which is assigned to them, however; and the plane still recovers its original net, so it must remain in the database (I haven't checked what happens if the file is saved and reloaded). Net-based rules created within PCB could also be a problem. They also seem to recover their nets if the net list is reloaded. Remember the reported bug with copper pours, that there seemed to be some kind of memory of previously assigned nets? This might well be the source of that. In order to maintain the rules and plane assignments, it appears that Protel does retain some net information after Clear. This *might* allow poured copper to recover its net, I have not verified that. But unattached primitives do not recover their nets. You could design around this by using free pads instead of vias and giving them the net name as a pad number, global edit would then restore them. Free copper, i.e., track, will never have a net assignment of its own if unconnected to a pad (or net-assigned via), so it is only free pads and vias which could be a problem here. Further, the clear process is unnecessary. Clearing out the net assignments of pads is sufficient, i.e., (Global edit all pads to NoNet)/Load Netlist. The basic function of this process is to ensure that there are (1) no deleted components and (2) no oscillating assignments due to duplicate pad names. Other than that, we would not need to do any of this. If no macros are created, it is not necessary to reconnect copper, which, by the way, can be time-consuming with a complex board. It is not necessary because nothing has been changed! These four steps will outperform the synchronizer 1000 out of 1000 times. at least in 99SE. If you must load the net list, perhaps. There are a number of synchronizer settings, I have not seen nor verified the long synchronizer times, so I can't confirm the report, but neither can I deny it. But simply to confirm a design at the end, the synchronizer works fine; i.e., if no macros are created, no problem, the schematic matches the PCB. The synchronizer carries exactly the same information, as far as I know, as a netlist, it is merely that the netlist is not explicity written. It is much faster, going back and forth, so the following is more likely to reflect on Mr. Regan's unfamiliarity with the synchronizer, since he can't use it with customer-supplied netlists or netlists from other CAD systems. I was a netlist maniac before discovering the synchronizer. I'm sorry, but in most circumstances, *if you are working with a Protel schematic*, the sychronizer substantially outperforms the netlist load process. Large designs *may* be an exception, but I think this is only for original load, if at all, not for resynchronization. I also disagree with you the synchronizer works better for the following reasons:I use the netlist to trouble shooting errors, change footprints on the fly, find single nodes, we run utilities to find broken busses, find duplicate signals, broken nets, we run utilities to automatically ID pairs for paired routing so that we can extract a do file. I can also view gnds, Ana gnds , E gnds, etc and discuss gnd issues with my customers, if
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
back and forth, so the following is more likely to reflect on Mr. Regan's unfamiliarity with the synchronizer, .. Abdul 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. We even killed Spectra with two designs. Further, the clear process is unnecessary. Our Clear, load, connect, run drc method has come to us thru long coffee breaks while waiting for Protel to catch up. I'm not knocking the program, because I have never used any other program for designs this large therefore, I don't know how they would respond either. I would imagine any program would be slow, its alot of stuff to remember. Both the netlist load and synchronizer, will go off to Thailand before the pc responds to any options, We cant tolerate that as we have lost too many man hours waiting. We hit Cntl ALT Del then tried another way in until I found out four step recovery program (joke)I found clear to speed things up, the difference in load times dropped from minutes vs hours on medium size boards with maybe 1500 components Connect Copper... WellYou are sort of right .. you may have to do a little work , re-assign split planes and polygons, when you use the connect copper command. The DRCs will catch it, it is the last of my four steps to recovery. 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. Mike Reagan * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
. 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. Nah, Nah Abdul Clear will not wipe out any of your work. Load the netlist again, run connect copper, run drcs. These four steps will outperform the synchronizer 1000 out of 1000 times. at least in 99SE. I also disagree with you the synchronizer works better for the following reasons:I use the netlist to trouble shooting errors, change footprints on the fly, find single nodes, we run utilities to find broken busses, find duplicate signals, broken nets, we run utilities to automatically ID pairs for paired routing so that we can extract a do file. I can also view gnds, Ana gnds , E gnds, etc and discuss gnd issues with my customers, if we both have a netlist. We even modify the netlist sometimes to make it connect to duplicate pins on BNCs, I have cut.pasted, and appended netlists.A netlist is very useful tool if nothing else. Like I mentioned it is the only port to third party tools. Just today, I had an EMI house require a specific breakdown of critical nets. I wont define critical here but you get the picture, I need a netlist to provide him the information. I cant provide this information on a system that is not netlist driven. Mike Reagan EDSI * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
At 09:27 PM 20/02/03 -0500, you wrote: Just today, I had an EMI house require a specific breakdown of critical nets. I wont define critical here but you get the picture, I need a netlist to provide him the information. I cant provide this information on a system that is not netlist driven. Mike, I agree that the netlist has a place for many users and is often the most sensible way for some users. I don't see the link, though, between using the synch and not being able to provide a netlist to a third party. You can easily use the synch and provide the netlist to others. Actually, the synch is netlist driven, it is just that the netlist is not created and saved on disk. If someone using the synch needs a netlist it is easily able to be generated. For many of us doing boards that are not as large as what you are doing then the delay in using the synch is much less than the delay in doing the steps you undertake. As the designs get bigger then the human element of the process becomes a smaller percentage and so the speed advantages of the netlist import become more significant. (Have you set up a macro to do the import and update free primitives from pad?) Mike - are you suggesting everyone should use the synch? Or are you pointing out that it is not appropriate for everyone? I would suggest that users would be well served by using the synch and only if they find, in their current circumstance, it is becoming a significant drag on their productivity should they look at netlist import. Note that drag on their productivity can be defined in many ways not just time of actually updating a PCB, it could include ease of dealing with 3rd parties. I am more interested in whether you think everyone should always use netlist import. Regards, Ian Wilson * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
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://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
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: *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
Any chance of placing large rectangular fills to do the bulk of the pours and then adding smaller pours around the edges to fill in. This would definitely speed things up. Or place a big pour covering most of the area, or less dense areas, with a huge track size (and grid=0) and then use a finer pour on the more complex areas? What about using a internal plane and an signal layer as a pair and get a photo merge done? Oh yeah - you are using every single layer. How thick is the board? 6mm? Ian , Yes it was over 6mm , We thought about using merged files, but we loose control over the gerber files, and don't have any method of checking DRCs.So we scrapped that idea.I just posted a solution for copper pours in my last email using the No Hatch method. I have been working with some board houses on this one. Mike Reagan EDSI * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
On 07:38 PM 13/02/2003 -0500, Mike Reagan said: John You are welcomed...but I should practice what I preach. I have been using this method with 99SE SP6 and have had flawless designs. Ok until last week , we got a board back with power and gnd were not connected to the input connector.The original ECO was a minor change, I imported a netlist, and since I knew what the ECO was, made the quick changes. Ran DRCs and sent gerbers. The problem was.the footprint for the power connector had duplicate pin numbers. A second import of a netlist in Protel causes all of the pins to disconnect, at third import will cause only one of the pins to connect. Every subsequent import will cause differnet results . I already was aware of it but didnt see the connector. This will not show up as an error when you import the netlist either. Had I stuck with my fool proof method and not taken a shortcut ( because I made an assumption) I wouldnt have had mud in my face. Clear the netlist, import the netlist , connect copper, run drcs .100 percent of the time and you will never have a problem. So said the fool of the week only because I made an assumption. A solution to this issue, for some at least, is to use Update PCB (the synchronizer) rather than netlist load. 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. Ian * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
Ian, Time works against me.Some boards of which I have Protel schematics, I have found the synchronizer to take hours. As much as 4 hours to use the synchronizer or to reload a netlist on top of one.If you use my crazy method, (clear netlist) not only is it fool proof, but it the entire process can be over and done with in 5- 15 minutes on large designs. The synchronizer is fine on small boards. We have one backplane, a designer recently took 4 hours to load a netlist. Using the synchronizer would have taken a week. Mike Reagan EDSI Frederick MD - Original Message - From: Ian Wilson [EMAIL PROTECTED] To: Protel EDA Forum [EMAIL PROTECTED] Sent: Friday, February 14, 2003 12:14 AM Subject: Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6. On 07:38 PM 13/02/2003 -0500, Mike Reagan said: John You are welcomed...but I should practice what I preach. I have been using this method with 99SE SP6 and have had flawless designs. Ok until last week , we got a board back with power and gnd were not connected to the input connector.The original ECO was a minor change, I imported a netlist, and since I knew what the ECO was, made the quick changes. Ran DRCs and sent gerbers. The problem was.the footprint for the power connector had duplicate pin numbers. A second import of a netlist in Protel causes all of the pins to disconnect, at third import will cause only one of the pins to connect. Every subsequent import will cause differnet results . I already was aware of it but didnt see the connector. This will not show up as an error when you import the netlist either. Had I stuck with my fool proof method and not taken a shortcut ( because I made an assumption) I wouldnt have had mud in my face. Clear the netlist, import the netlist , connect copper, run drcs .100 percent of the time and you will never have a problem. So said the fool of the week only because I made an assumption. A solution to this issue, for some at least, is to use Update PCB (the synchronizer) rather than netlist load. 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. Ian * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
The synchronizer is fine on small boards. We have one backplane, a designer recently took 4 hours to load a netlist. Using the synchronizer would have taken a week. Yeow! I wonder if the netlist load and sync algorithms are one of those n^2 problems. You know, the ones where you double the complexity, the time to solve goes up by 4. I had some fairly large designs before that loaded the netlist in a few seconds (on a dual PIII 1GHz). If your design was more complex by a linear factor, then it would have been 3600x as complex as mine. Somehow I doubt you had 108,000 chips on one PCB ;-) So maybe you had 60x as many chips as my board (still 1800 chips!). I'd hate to do a clearance check on your board ;-) Best regards, Ivan Baggett Bagotronix Inc. website: www.bagotronix.com - Original Message - From: Mike Reagan [EMAIL PROTECTED] To: Protel EDA Forum [EMAIL PROTECTED] Sent: Friday, February 14, 2003 9:18 AM Subject: Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6. Ian, Time works against me.Some boards of which I have Protel schematics, I have found the synchronizer to take hours. As much as 4 hours to use the synchronizer or to reload a netlist on top of one.If you use my crazy method, (clear netlist) not only is it fool proof, but it the entire process can be over and done with in 5- 15 minutes on large designs. The synchronizer is fine on small boards. We have one backplane, a designer recently took 4 hours to load a netlist. Using the synchronizer would have taken a week. Mike Reagan EDSI Frederick MD - Original Message - From: Ian Wilson [EMAIL PROTECTED] To: Protel EDA Forum [EMAIL PROTECTED] Sent: Friday, February 14, 2003 12:14 AM Subject: Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6. On 07:38 PM 13/02/2003 -0500, Mike Reagan said: John You are welcomed...but I should practice what I preach. I have been using this method with 99SE SP6 and have had flawless designs. Ok until last week , we got a board back with power and gnd were not connected to the input connector.The original ECO was a minor change, I imported a netlist, and since I knew what the ECO was, made the quick changes. Ran DRCs and sent gerbers. The problem was.the footprint for the power connector had duplicate pin numbers. A second import of a netlist in Protel causes all of the pins to disconnect, at third import will cause only one of the pins to connect. Every subsequent import will cause differnet results . I already was aware of it but didnt see the connector. This will not show up as an error when you import the netlist either. Had I stuck with my fool proof method and not taken a shortcut because I made an assumption) I wouldnt have had mud in my face. Clear the netlist, import the netlist , connect copper, run drcs .100 percent of the time and you will never have a problem. So said the fool of the week only because I made an assumption. A solution to this issue, for some at least, is to use Update PCB (the synchronizer) rather than netlist load. 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. Ian * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
Ivan, I had one design with those little itsy bitsy tiny logic chips amounted to 4500 chips. The Backplane it fit into was 24x 36 , only one fabricator in the country was able to make it. It used every layer both signal and planes that Protel had. Then on top of that, the backplane designer had poured copper on the outer layers. We are working with a board house now to allow them to do the copper pours on the exterior. The copper pours are killing us for time. Mike Compare and Partially Matched Nets. Protel 99SE SP6. The synchronizer is fine on small boards. We have one backplane, a designer recently took 4 hours to load a netlist. Using the synchronizer would have taken a week. Yeow! I wonder if the netlist load and sync algorithms are one of those n^2 problems. You know, the ones where you double the complexity, the time to solve goes up by 4. I had some fairly large designs before that loaded the netlist in a few seconds (on a dual PIII 1GHz). If your design was more complex by a linear factor, then it would have been 3600x as complex as mine. Somehow I doubt you had 108,000 chips on one PCB ;-) So maybe you had 60x as many chips as my board (still 1800 chips!). I'd hate to do a clearance check on your board ;-) Best regards, Ivan Baggett Bagotronix Inc. website: www.bagotronix.com - Original Message - From: Mike Reagan [EMAIL PROTECTED] To: Protel EDA Forum [EMAIL PROTECTED] Sent: Friday, February 14, 2003 9:18 AM Subject: Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6. Ian, Time works against me.Some boards of which I have Protel schematics, I have found the synchronizer to take hours. As much as 4 hours to use the synchronizer or to reload a netlist on top of one.If you use my crazy method, (clear netlist) not only is it fool proof, but it the entire process can be over and done with in 5- 15 minutes on large designs. The synchronizer is fine on small boards. We have one backplane, a designer recently took 4 hours to load a netlist. Using the synchronizer would have taken a week. Mike Reagan EDSI Frederick MD - Original Message - From: Ian Wilson [EMAIL PROTECTED] To: Protel EDA Forum [EMAIL PROTECTED] Sent: Friday, February 14, 2003 12:14 AM Subject: Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6. On 07:38 PM 13/02/2003 -0500, Mike Reagan said: John You are welcomed...but I should practice what I preach. I have been using this method with 99SE SP6 and have had flawless designs. Ok until last week , we got a board back with power and gnd were not connected to the input connector.The original ECO was a minor change, I imported a netlist, and since I knew what the ECO was, made the quick changes. Ran DRCs and sent gerbers. The problem was.the footprint for the power connector had duplicate pin numbers. A second import of a netlist in Protel causes all of the pins to disconnect, at third import will cause only one of the pins to connect. Every subsequent import will cause differnet results . I already was aware of it but didnt see the connector. This will not show up as an error when you import the netlist either. Had I stuck with my fool proof method and not taken a shortcut because I made an assumption) I wouldnt have had mud in my face. Clear the netlist, import the netlist , connect copper, run drcs .100 percent of the time and you will never have a problem. So said the fool of the week only because I made an assumption. A solution to this issue, for some at least, is to use Update PCB (the synchronizer) rather than netlist load. 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. Ian * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
On 09:18 AM 14/02/2003 -0500, Mike Reagan said: Ian, Time works against me.Some boards of which I have Protel schematics, I have found the synchronizer to take hours. I assume you are not using the Assign Net to Connected Copper option within the synchronizer - I have found this to slow things down heaps. I have not noticed a dramatic slow down of the synch with design size but probably the biggest design I have done is quite modest by your standards. Mike, I am not surprised you have good reason for doing what you were doing. I was mainly pointing out to others (and for the web searcher) that the synch doesn't have this particular issue. I was quite sure you had good reason not to use it in this case (though the cost and time spent turning the PCB again would be more than the cost in your time doing using the synch - in this case, I'd guess. So all you have to do is figure out when you are about to make a mistake and spend the time doing the synch instead of netlist load ... simple, eh! Ian * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
On 12:05 PM 14/02/2003 -0500, Mike Reagan said: Ivan, I had one design with those little itsy bitsy tiny logic chips amounted to 4500 chips. The Backplane it fit into was 24x 36 , only one fabricator in the country was able to make it. It used every layer both signal and planes that Protel had. Then on top of that, the backplane designer had poured copper on the outer layers. We are working with a board house now to allow them to do the copper pours on the exterior. The copper pours are killing us for time. Any chance of placing large rectangular fills to do the bulk of the pours and then adding smaller pours around the edges to fill in. This would definitely speed things up. Or place a big pour covering most of the area, or less dense areas, with a huge track size (and grid=0) and then use a finer pour on the more complex areas? What about using a internal plane and an signal layer as a pair and get a photo merge done? Oh yeah - you are using every single layer. How thick is the board? 6mm? Ian * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
John, You really don't have to do a netlist compare. I see designers doing this all of the time. This may have developed because of a mistrust of other programs they have used because DRCs couldn't be trusted. The bottom line is the DRC netlist checking in versions 2.8 - 99SE SP 6 work and work quite well. As far as I know the errors that the program will not check for is : 1 if you deleted a component2: duplicate pins., 3 it will miss split plane problems once in while. To address your real question, the differences could be attributed to several things, 1: the netlist generated from the board does not accurately represent the board because of a Protel issue ( I don't call this one a bug because the DRC wasn't designed to work this way) . 2 A second netlist generated from the schematic may have different names for nets which we not names. 3. Other parts, or pads on the netlist which you have connected are now in the netlist, 4: Plane information is not accurately generated.In any case this is not a good method of verification A Fool Proof method for verification: Clear all nets, Load netlist again Update free primitives from pad Run your DRCs. Review your DRCs , if you have everything set up right it should all read 0 I will guarantee this is 100 percent fool proof. Good Luck Mike Reagan EDSI Frederick Md About Netlist Compare and Partially Matched Nets. Protel 99SE SP6. Hello All, Have a PCB design that is completely routed. The board information report and DRC report state that everything is 100% routed with no violations. OK great. In the schematic side I generate a Netlist. Now I go to the PCB side and from Netlist Manager I export the Netlist from PCB. I then do a Netlist compare and everything is good. I then go to the schematic side again and do a Netlist compare with the same two files. The report states that I have 2 Partially Matched Nets. How can this be? What exactly is a Partially Matched Net? To me it sounds like parts of the net in question are not completely routed. Has anyone out there had this experience? Do I have a problem with my design or is this a Protel bug - feature? Any information that you can give me will be greatly appreciated. Thank you for your time and have a nice day. John Branthoover: Electrical Design Engineer : Acutronic R D:Phone (412) 968-1051 640 Alpha Drive :Fax(412) 963-0816 Pittsburgh PA 15238 :Email [EMAIL PROTECTED] USA :WEBhttp://www.acutronic.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
Hello Mike, I tried your fool proof method and everything works great. Thanks for taking the time to help me out. Take care and have a nice night. -Original Message- From: Mike Reagan [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 2:26 PM To: Protel EDA Forum Subject: Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6. John, You really don't have to do a netlist compare. I see designers doing this all of the time. This may have developed because of a mistrust of other programs they have used because DRCs couldn't be trusted. The bottom line is the DRC netlist checking in versions 2.8 - 99SE SP 6 work and work quite well. As far as I know the errors that the program will not check for is : 1 if you deleted a component2: duplicate pins., 3 it will miss split plane problems once in while. To address your real question, the differences could be attributed to several things, 1: the netlist generated from the board does not accurately represent the board because of a Protel issue ( I don't call this one a bug because the DRC wasn't designed to work this way) . 2 A second netlist generated from the schematic may have different names for nets which we not names. 3. Other parts, or pads on the netlist which you have connected are now in the netlist, 4: Plane information is not accurately generated.In any case this is not a good method of verification A Fool Proof method for verification: Clear all nets, Load netlist again Update free primitives from pad Run your DRCs. Review your DRCs , if you have everything set up right it should all read 0 I will guarantee this is 100 percent fool proof. Good Luck Mike Reagan EDSI Frederick Md About Netlist Compare and Partially Matched Nets. Protel 99SE SP6. Hello All, Have a PCB design that is completely routed. The board information report and DRC report state that everything is 100% routed with no violations. OK great. In the schematic side I generate a Netlist. Now I go to the PCB side and from Netlist Manager I export the Netlist from PCB. I then do a Netlist compare and everything is good. I then go to the schematic side again and do a Netlist compare with the same two files. The report states that I have 2 Partially Matched Nets. How can this be? What exactly is a Partially Matched Net? To me it sounds like parts of the net in question are not completely routed. Has anyone out there had this experience? Do I have a problem with my design or is this a Protel bug - feature? Any information that you can give me will be greatly appreciated. Thank you for your time and have a nice day. John Branthoover: Electrical Design Engineer : Acutronic R D:Phone (412) 968-1051 640 Alpha Drive :Fax(412) 963-0816 Pittsburgh PA 15238 :Email [EMAIL PROTECTED] USA :WEBhttp://www.acutronic.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6.
John You are welcomed...but I should practice what I preach. I have been using this method with 99SE SP6 and have had flawless designs. Ok until last week , we got a board back with power and gnd were not connected to the input connector.The original ECO was a minor change, I imported a netlist, and since I knew what the ECO was, made the quick changes. Ran DRCs and sent gerbers. The problem was.the footprint for the power connector had duplicate pin numbers. A second import of a netlist in Protel causes all of the pins to disconnect, at third import will cause only one of the pins to connect. Every subsequent import will cause differnet results . I already was aware of it but didnt see the connector. This will not show up as an error when you import the netlist either. Had I stuck with my fool proof method and not taken a shortcut ( because I made an assumption) I wouldnt have had mud in my face. Clear the netlist, import the netlist , connect copper, run drcs .100 percent of the time and you will never have a problem. So said the fool of the week only because I made an assumption. Mike Reagan Hello Mike, I tried your fool proof method and everything works great. Thanks for taking the time to help me out. Take care and have a nice night. -Original Message- From: Mike Reagan [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 2:26 PM To: Protel EDA Forum Subject: Re: [PEDA] A Question About Netlist Compare and Partially Matched Nets. Protel 99SE SP6. John, You really don't have to do a netlist compare. I see designers doing this all of the time. This may have developed because of a mistrust of other programs they have used because DRCs couldn't be trusted. The bottom line is the DRC netlist checking in versions 2.8 - 99SE SP 6 work and work quite well. As far as I know the errors that the program will not check for is : 1 if you deleted a component2: duplicate pins., 3 it will miss split plane problems once in while. To address your real question, the differences could be attributed to several things, 1: the netlist generated from the board does not accurately represent the board because of a Protel issue ( I don't call this one a bug because the DRC wasn't designed to work this way) . 2 A second netlist generated from the schematic may have different names for nets which we not names. 3. Other parts, or pads on the netlist which you have connected are now in the netlist, 4: Plane information is not accurately generated.In any case this is not a good method of verification A Fool Proof method for verification: Clear all nets, Load netlist again Update free primitives from pad Run your DRCs. Review your DRCs , if you have everything set up right it should all read 0 I will guarantee this is 100 percent fool proof. Good Luck Mike Reagan EDSI Frederick Md About Netlist Compare and Partially Matched Nets. Protel 99SE SP6. Hello All, Have a PCB design that is completely routed. The board information report and DRC report state that everything is 100% routed with no violations. OK great. In the schematic side I generate a Netlist. Now I go to the PCB side and from Netlist Manager I export the Netlist from PCB. I then do a Netlist compare and everything is good. I then go to the schematic side again and do a Netlist compare with the same two files. The report states that I have 2 Partially Matched Nets. How can this be? What exactly is a Partially Matched Net? To me it sounds like parts of the net in question are not completely routed. Has anyone out there had this experience? Do I have a problem with my design or is this a Protel bug - feature? Any information that you can give me will be greatly appreciated. Thank you for your time and have a nice day. John Branthoover: Electrical Design Engineer : Acutronic R D:Phone (412) 968-1051 640 Alpha Drive :Fax(412) 963-0816 Pittsburgh PA 15238 :Email [EMAIL PROTECTED] USA :WEBhttp://www.acutronic.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
