> From: Abd ul-Rahman Lomax [mailto:[EMAIL PROTECTED] [...]I also assume > that you have verified that the problem does not exist in the > 99SE version of the design. If [this is] not true, please correct me!
No, this is in the 99SE design I am preparing for DXP2004 import.
Okay, let's see if I've got it right now. If there is a bug, it is a 99SE bug. You have a 99SE schematic that, *in 99SE*, generates ERC errors and which assigns the power nets contrary to expectation (i.e., it splits them, as if they were local, not global). You also have problems when you try to import the schematic due to multiple sheet entries with the same name on the same symbol.
When opened in DXP, the compiler chokes because of the power port connectivity issues (assumes
demotion to local net for power) and also chokes on the multiple sheet entries.
The top sheet can be easily rewired to remove the sheet entry issues but the connectivity issue is
driving me nuts.
Of course, fixing the sheet entry issues *might* fix the other problem, though the connection would be obscure. Nevertheless, that is what should be done.
If my new assumptions are correct, this is a good example of why it is important to (1) set the ERC matrix to show all possible error conditions and warnings, (2) suppress single-pin net warnings where the single-pin condition is intentional, and (3) track down and eliminate all errors, even if they might seem to be harmless. Sometimes an engineer will look at an error, say "I don't see anything wrong here" and so they pop a No-ERC directive on the error, thus suppressing it. Very bad idea. Even if it seems arbitrary, it is much better, i.e., safer, to satisfy the ERC by how one designs.
If you are in a hurry, understand that haste makes waste and if you decide to barge ahead anyway, at least don't suppress the error message! Leave it, there is no law that a schematic must be free of error markers, and the marker and message next time ERC is run are a reminder that the paperwork is not done. Using a No-ERC marker to suppress the error or not-clearly-understood warning is like spraying perfume instead of cleaning up the mess....
I actually enjoy these challenges but when time is against you it takes the fun out of it :-)
Absolutely. But it is important to do it right. At the start, if possible, that is much easier. Leaving messes for later just creates more work later, usually more work than it would have been to do it right in the first place. If you gotta do it, you gotta do it.
I have been collecting some notes, caveats and precautionary tactics to move the last of these 99SE
designs I have to DXP2004 (about 60 or so) which is why I have been re-evaluating my workaround of
wiring up power nets on the top sheet (thus bypassing the assumed 'global' power connectivity). The
end document will be formed to a procedure for others to follow and it is a lot faster and easier to
edit / prepare it in 99SE than in DXP2004.
The problem with the workaround is that if it is removed later by an unsuspecting designer, the problem will reappear, this time with a new person who might not be expecting it. It might be years from now. It might even be you, having forgotten the details.
Although I have had to put this aside for the moment, currently my train of thought is that a wire
label or other additional net naming object is present or exists on some other sheet than the id
key.sch one, possibly hidden or moved under a component with the POE touching a pin / wire which is
already connected to a power object.
This would make sense to me.
Sure. The suggestion I made of chopping down the schematic until you get a single schematic or set of schematics with a minimum number of objects on them that still show the problem is *very* likely to discover the cause. As it is, you have large numbers of objects to deal with, and, as you note, the error marker is not necessarily placed at the location of the true error (but may be placed at the location of another object which *becomes* an error because of the first object's condition). As an easy example, if you have duplicate reference designators, ERC doesn't know which one of them is wrong, so it marks the second one it finds, I think.
It is not the first time I have seen the error markers in 99SE placed at the conflict target
position and not the source (due to position in netlist).
Yes, it is pretty common, actually.
So I intend to pick through the netlist first then all sheets one at a time.
That should not be necessary. Since you have an obvious test for the error condition, you can delete whole sheets; if the error condition remains, you have not deleted the problem condition, so you don't need to even look at the sheet you deleted. (Of course, if there is more than one instance of the problem, you might have deleted one of them, but you'll find that out later, and at that time you'll likely know exactly what to look for.)
Then, when you have a minimum set of sheets, you can start going into sheets and deleting components and wires. The most efficient way to do this, typically, is to delete about half of what is present on a sheet at at time, then test. (i.e., do a binary search.) You'll create a pile of errors due to the creation of unconnected pins, but you can temporarily set your error matrix to ignore those -- unless you must have that report as part of your error condition test.
If this problem is common to many of the designs you are converting, there may be a single piece of IP that has been re-used. So finding the problem once may make dealing with the whole set of designs easy. It might seem like a lot of work *just for one design* but that's not all you are dealing with.
Even if you were only dealing with one design, you would be well-advised to find and fix the problem, because it might be coming from a design practice that should be avoided. Fixing it now could avoid hosts of problems in the future.
I think it is important for a designer to know thoroughly how the schematic process treats connectivity, there should be no mysteries left. Quirks of the program, yes, those *have* to be left because the designer does not control the program. So if the program requires that you put a net label on a bus running between bus entries on different sheet symbols in order to get the proper connectivity and no ERC markers, even though it is explicit without the net label, put the label there! Getting a clean ERC without suppressing whole categories of errors is *extremely* important.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *