> -----Original Message-----
> From: Abd ulRahman Lomax [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, May 06, 2004 5:08 PM
> To: Protel EDA Forum
> Subject: Re: [PEDA] Connectivity - Netlist issues
> 
> At 07:14 PM 5/5/2004, John A. Ross [RSDTV] wrote:
> > > 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.

More or less, I had already translated 14 designs througout last year,
some a lot bigger than this one to DXP7.x, then 2004.

I had already encountered the multiple sheet entry > one port (many to
one) but thought I would ask if anyone had a smart workaround to get
that working in DXP as re-drafting is a pain and potential point for
error.

However this design threw me a curve ball with this connectivity issue.
I really do reckon that the connectivity may be OK, but the net name is
somehow being introduced twice with same nodes or partial matches and
that is the error rather than broken connectivity which is just the
result of the badly loaded netlist. I am being cautious here as I have
found the ERC and Netlist load process seem to treat the netlist
differently.


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

Nope, tried that already
 
> 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.

I never like to see any errors, I also disagree with turning any
warnings off including single pin nets. 

For single pin issues in 99SE I usually just placed a 0.5x0.5mm SMT test
pad on those net, so no warnings :-)  Taking them out the BOM was a
pain, but better than an error

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

Don't quite get that one.

As you picked up from the other message I can be 'excessively neat' and
the whole reason for me attacking the issue was to get to the bottom of
it.

The workaround of connecting power rails using ports/sheet entries is in
theory harmless, and actually only adding redundancy to the connectivity
model of global power ports. 

But you are right, I guess looking back, I did more or less sweep the
power port connectivity issue under the carpet on this one due to a
successful workaround, not good practice at all really. 

Trust me, that's not normal for me you can be sure.

> snip <

> >  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.)

There a few designs like this, not all of them exhibit the same
behaviour.

I can run some macros and scripts on the netlist to strip it down, if I
can follow the sheet order I think ill at least get the right area as
all my sheets follow a common annotation methodology. Perhaps I should
explain that one. If I have say an output stage for a video buffer
terminated in a BNC connector, that sheet may be annotated x50-x99, the
video output device or encoder feeding it might have x100-x129
allocation, the audio DAC might have x130 to x149 allocation. All nets
are named on these sheets, that way I can drop them into any design and
reuse the PCB blocks as well. So hacking at the netlist is not so hard
when it is not full of $000156 type net names.  

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

If I find the part then traceability is no problem througout other
designs.

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

Where did I give the impression that I suppress warnings? Or am I
reading to much into a simple statement?

If I have a SCH with errors it will stay on my desk till its fixed, now
or later.

You will see from the top sheet I took a screenshot of that I always add
a netlabel to the connecting wires & buses, although you did not see all
the child sheets you eill find a net label as well for every port as
well (just like id key.sch).

But ill find it, that's for sure, if the designs been altered then Ill
find out who did it also. Just a matter of time....


John



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

Reply via email to