Board DRC - Supposed to Generate Errors/Warnings on Unrouted Nets?

On 09/10/10 20:56, Michael Sansom wrote:

I just noticed that I have two unrouted nets on my board layout (i.e.

the ratsnets lines are visible but no copper tracks connect) and the DRC

isn't generating any errors/warning.  Is this correct?  What am I doing

wrong, I've never seen a DRC that wouldn't flag unrouted signals.

If the DRC were to warn about unrouted signals, it would ave to

run a complete RATSNEST (including processing all polygons) every

time the DRC is run. Clearly this is not desirable.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

On 09/10/10 20:56, Michael Sansom wrote:

I just noticed that I have two unrouted nets on my board layout (i.e.

the ratsnets lines are visible but no copper tracks connect) and the DRC

isn't generating any errors/warning.  Is this correct?  What am I doing

wrong, I've never seen a DRC that wouldn't flag unrouted signals.

If the DRC were to warn about unrouted signals, it would ave to

run a complete RATSNEST (including processing all polygons) every

time the DRC is run. Clearly this is not desirable.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

"Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> wrote in message

news:i6kke9$d83$1@cheetah.cadsoft.de...

If the DRC were to warn about unrouted signals, it would ave to

run a complete RATSNEST (including processing all polygons) every

time the DRC is run. Clearly this is not desirable.

It should say "warning: Ratsnest has not been done. There might be

airwires."

This also touches a similar subject (Topic "ERC/DRC rerun?").  I suggested

some indicator to show that ratsnest is needed.

So if Eagle knows there has been changes after last ratsnest, it should warn

in the DRC window. If there are no changes, it should report if there are

airwires or not.

I like it the way it is.

It is good to run a RATSNEST to verify that you are done.

It is also good to be sure that any hidden airwires are accounted for too.

If this does get added to DRC I would want to be able to skip this check.

I run DRC periodically while routing and there would be unrouted airwires.

"Morten Leikvoll" <mleikvol@yahoo.nospam> wrote in message

news:i6kmn1$nsi$1@cheetah.cadsoft.de...

"Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> wrote in message

news:i6kke9$d83$1@cheetah.cadsoft.de...

>> If the DRC were to warn about unrouted signals, it would ave to

>> run a complete RATSNEST (including processing all polygons) every

>> time the DRC is run. Clearly this is not desirable.

>

It should say "warning: Ratsnest has not been done. There might be

airwires."

This also touches a similar subject (Topic "ERC/DRC rerun?").  I suggested

some indicator to show that ratsnest is needed.

So if Eagle knows there has been changes after last ratsnest, it should

warn in the DRC window. If there are no changes, it should report if there

are airwires or not.

>

On 9/13/2010 2:38 AM, Klaus Schmidinger wrote:

On 09/10/10 20:56, Michael Sansom wrote:

>> I just noticed that I have two unrouted nets on my board layout (i.e.

>> the ratsnets lines are visible but no copper tracks connect) and the DRC

>> isn't generating any errors/warning.  Is this correct?  What am I doing

>> wrong, I've never seen a DRC that wouldn't flag unrouted signals.

>

If the DRC were to warn about unrouted signals, it would ave to

run a complete RATSNEST (including processing all polygons) every

time the DRC is run. Clearly this is not desirable.

>

Klaus Schmidinger

You say that Clearly this is not desirable, but I think you are somewhat

hasty with that declaration.  Clearly other PCB layout packages do check

for unconnected nets during the DRC.  Also, your engine is pretty fast

at processing polygons, so I suspect that Eagle doing a RATSNEST during

a DRC is still probably going to be faster than your competition (I know

you would be faster than Allegro).

In the end, I'm fine with doing a RATNEST outside of the DRC, though it

is not what new Eagle users moving over from other tools are going to

expect.

That said, if I were you I'd really think about adding a feature that

lets you quickly locate unconnected nets on the layout after you run the

RATNEST command.  I know now that there is a ULP that helps with this,

but in my opinion this functionality is generally expected to be

integrated in the software as it ships.  Before I was told that a ULP

existed for this function I was reduced to turning off all layers except

the Unrouted layer and turning off grid dots just to see these small

no connects.

Let me add one final thing.

Clearly you could add a check box to the DRC options that says "Check

for unrouted nets".  You've got several options for the DRC

configuration as it stands now and this one would fit nicely under the

"Misc" tab.  That way your user could decide if checking for unrouted

nets was something that he wanted to do in the DRC or not.  If a

customer thought that checking for unrouted nets was slowing down his

DRC too much, he could uncheck this option and it would work as it does

now.  However if the customer was accustomed to having the DRC check for

unrouted nets, this would give him the option to continue to do so in

Eagle as well.

-Michael

On 9/13/2010 12:38 AM, Klaus Schmidinger wrote:

On 09/10/10 20:56, Michael Sansom wrote:

>> I just noticed that I have two unrouted nets on my board layout (i.e.

>> the ratsnets lines are visible but no copper tracks connect) and the DRC

>> isn't generating any errors/warning.  Is this correct?  What am I doing

>> wrong, I've never seen a DRC that wouldn't flag unrouted signals.

>

If the DRC were to warn about unrouted signals, it would ave to

run a complete RATSNEST (including processing all polygons) every

time the DRC is run. Clearly this is not desirable.

>

Klaus Schmidinger

I think it does not need to process the RATS, just warn that changes

were made and RATS has not been run yet, or that not all layers were

included in the DRC.

As discussed before, if there are DRC errors, it doesn't matter, it can

be skipped. It's just that misleading "No Errors" that is the problem.

Just one line of output.

And why does it need to run RATS anyway, don't you have a running tally

of unrouted nets in the status line? If this <>0 then you have unrouted

signals.

Klaus Schmidinger wrote on Mon, 13 September 2010 03:38

On 09/10/10 20:56, Michael Sansom wrote:

I just noticed that I have two unrouted nets on my board layout

(i.e.

the ratsnets lines are visible but no copper tracks connect) and

the DRC

isn't generating any errors/warning.  Is this correct?  What am I

doing

wrong, I've never seen a DRC that wouldn't flag unrouted signals.

 

If the DRC were to warn about unrouted signals, it would ave to

run a complete RATSNEST (including processing all polygons) every

time the DRC is run. Clearly this is not desirable.

I'm not sure it's so clear.

I think that there are actually two usage cases for the DRC:

a quick test at design test to make sure that the just placed features

don't create design rule issues

a complete test a design review time to ensure that the board that is

manufactured meets the intended design criteria

There may be more usage cases.

What I would like to see is the ability to configure the DRC engine to turn

on and off a bunch of different checks.  So for the first case above I

would care about things like clearances and trace widths, etc but not

things like off-angle, text and mask clearances, ...  And because I do that

so often it would save me a huge amount of time.

However, for the second case I definitely want to know if there is a signal

not routed--that board isn't going to be manufactured to the intention of

the schematic.  And if this takes 3 minutes I don't really care--thorough

is good in this case.  And it should also run the ERC as well since this is

pertinent information.  Think of a board design review--any information

that you'd want to see there should be in the report.

Maybe you could pass a DRC configuration name to the command and it would

run with those settings.  Then we could have numerous different levels of

DRC checking.  And there should be a switch to run on all layers no matter

what is displayed.

Altium has a similar feature where they have a configuration window where

you can turn off individual checks in both their online DRC and the batch

DRC.  That's sort of the idea but why not make it more generic so that the

user can just create a configuration and run it--no need to limit to 2.

The other big shortcoming of the DRC is that there is no reporting facility

other than on-screen display.  A typical design review process would be to

attach the DRC report from the CAD tool for a record of any issues that the

CAD tool had flagged (preferably none).  It should show the name of the

design, the timestamp of when the test was run, and a list of all the

errors and warnings (approved or otherwise).

It would be good for the CAM processor to create its own report as well

since that is as much of the design process as anything else--any error or

warning there could mean the board won't work too.

Cheers,

James.

--

James Morrison  ~~~  Stratford Digital

Specializing in CadSoft EAGLE

• Online Sales to North America

• Electronic Design Services

• EAGLE Enterprise Toolkit

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

On 09/13/10 22:27, Gary Gofstein wrote:

...

And why does it need to run RATS anyway, don't you have a running tally

of unrouted nets in the status line? If this <>0 then you have unrouted

signals.

If the drawing has been modified since the last RATSNEST, airwires

might have become obsolete or new airwires might be necessary, due

to modifications to signal polygons.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

On 9/14/2010 2:46 AM, Klaus Schmidinger wrote:

On 09/13/10 22:27, Gary Gofstein wrote:

>> ...

>> And why does it need to run RATS anyway, don't you have a running tally

>> of unrouted nets in the status line? If this<>0 then you have unrouted

>> signals.

>

If the drawing has been modified since the last RATSNEST, airwires

might have become obsolete or new airwires might be necessary, due

to modifications to signal polygons.

>

Klaus Schmidinger

If you run a DRC without doing a RATSNEST first, do you run the risk of

missing spacing violations because the polygons are old and haven't been

updated?

On 9/13/2010 5:19 PM, James Morrison wrote:

Klaus Schmidinger wrote on Mon, 13 September 2010 03:38

>> On 09/10/10 20:56, Michael Sansom wrote:

>> > I just noticed that I have two unrouted nets on my board layout

>> > (i.e.

>> > the ratsnets lines are visible but no copper tracks connect) and

>> > the DRC

>> > isn't generating any errors/warning. Is this correct? What am I

>> > doing

>> > wrong, I've never seen a DRC that wouldn't flag unrouted signals.

>>

>> If the DRC were to warn about unrouted signals, it would ave to

>> run a complete RATSNEST (including processing all polygons) every

>> time the DRC is run. Clearly this is not desirable.

>

>

I'm not sure it's so clear.

>

I think that there are actually two usage cases for the DRC:

>

>

a quick test at design test to make sure that the just placed features

don't create design rule issues

a complete test a design review time to ensure that the board that is

manufactured meets the intended design criteria

>

>

There may be more usage cases.

>

What I would like to see is the ability to configure the DRC engine to turn

on and off a bunch of different checks. So for the first case above I

would care about things like clearances and trace widths, etc but not

things like off-angle, text and mask clearances, ... And because I do that

so often it would save me a huge amount of time.

>

However, for the second case I definitely want to know if there is a signal

not routed--that board isn't going to be manufactured to the intention of

the schematic. And if this takes 3 minutes I don't really care--thorough

is good in this case. And it should also run the ERC as well since this is

pertinent information. Think of a board design review--any information

that you'd want to see there should be in the report.

>

Maybe you could pass a DRC configuration name to the command and it would

run with those settings. Then we could have numerous different levels of

DRC checking. And there should be a switch to run on all layers no matter

what is displayed.

>

Altium has a similar feature where they have a configuration window where

you can turn off individual checks in both their online DRC and the batch

DRC. That's sort of the idea but why not make it more generic so that the

user can just create a configuration and run it--no need to limit to 2.

>

The other big shortcoming of the DRC is that there is no reporting facility

other than on-screen display. A typical design review process would be to

attach the DRC report from the CAD tool for a record of any issues that the

CAD tool had flagged (preferably none). It should show the name of the

design, the timestamp of when the test was run, and a list of all the

errors and warnings (approved or otherwise).

>

It would be good for the CAM processor to create its own report as well

since that is as much of the design process as anything else--any error or

warning there could mean the board won't work too.

>

Cheers,

>

James.

>

I would vote for real time flagging of clearance and width issues rather

than running DRC on small areas.

And to not lose sight of my main point, DRC report, when there are no

errors found, should at least mention that RATS has not been run since

the last change and that some layers were not checked.

On 09/14/10 16:24, Michael Sansom wrote:

...

If you run a DRC without doing a RATSNEST first, do you run the risk of

missing spacing violations because the polygons are old and haven't been

updated?

No. The polygons are always calculated according to the same parameters

as used by the DRC. So it doesn't matter whether they are calculated or

not when the DRC is executed.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________