Design Rule Check

Because the checkers are too stupid when used on "analog" circuits. I.e. anything that is not the board full of TTL the software was originally designed for.

E.g. I tend to decouple most supplies to chips with a RC or LC (bead). So nearly all the power pins are flagged with errors, since they must be driven from a "power source". i.e. a regulator output or "power rail".

Similarly "inputs" must be directly connected to "outputs". More often than not there are other parts in between and so these are all flaggged too.

I think the only thing I have found useful is the unconnected pin / single pin nets checks.

We have our own parts library, evolved over the years. We have a form to fill out to create or modify a part, and we attach the relevant pages of the data sheet to the form. My PCB guy creates the part, and we check all new ones. We file the forms.

With the new P+P machine, on my big board we will try some new footprints to reduce tombstoning and head-on-the-pillow defects.

I did some ovalized pads (rounded corners) for a high-voltage thing, but that's not a new part in PADS, it's just something you do.

The only thing a CAD schematic check does for me is find single-ended nets.

We manually check and design review schematics really hard, for

We do impedances/trace widths manually. I suppose some people+tools automate that.

We never autoroute.

I run both checks (ERC DRC). ERC hardly ever finds anything, but it gives me a warm fuzzy feeling. (That will soon disappear when the pcb comes back with some logic/ layout/ flipped sign error. :^)

George H.

What I have found useful is the "net list" where every distinct net on the schematic can be individually, manually checked in strict sequence. It takes quite a long time but does often let me find some design errors.

Huh, I don't know that function. Does it exist in Eagle?

George H.

I expect so but I use Altium currently. Traditionally the netlist is the output of the "schematic capture" program and the input to the "PCB layout" program used to create the artwork. In the schematic editor in Altium you can display a list of all "nets" in the design. Click on a net and it is highlighted everywhere it exists on the schematic, along with the pins it connects together. You can then think about each pin on this signal.

I think the reason it is useful is that it forces me to to focus on each signal systematically and in a different way than I do during the initial design / schematic entry phase. YMMV.

I got the principle from this video (long, about Altium). You might be able to skip through it to get the idea.

Ahh OK the "show" button in Eagle does that. (I have to click each node.)

George H.

I don't know how to do that in PADS. I tend to use zero or low-ohm resistors to effectively rename a net, for Kelvin things.

If one of the sense lines is ground, and it needs vias to get to where it's going, PADS layout will nail every via to the ground plane, resulting in a half-Kelvin connection.

Visually highlighting individual nets from the netlist on the PCB can give some useful insights as well.

--sp

What does "digital" have to do with DRC/ERC? No one makes large digital schematics? What do you consider "large"?

Nonsense.

You're missing the boat.

They will still find single-ended nets and often, shorted nets. It's not like it's a lot of work to run.

So you don't do the checks?

Who's dumb enough to short outputs together?

I guess you're admitting you do..?

That's a strange thing to conclude, when the statement implyies he /does/ run the checks...

In Altium, the check runs automatically when you compile the design (which resolves schematic objects --> netlist and stuff). You literally cannot update the PCB without compiling the project, so it runs, dozens of times, automatically. (You can disable various warnings and errors, so for validation purposes, you'd want to check that the project is set up properly. But as long as you aren't actively trying to defeat yourself, it's there.)

As John mentioned, it mostly catches intended "warnings", or stuff that's not actually a problem, and not worth the time to "fix" (like R terminators with passive instead of input and output type pins).

I think the most numerous warnings I get are "net has multiple names", and some power supply related warnings. But that's specific to Altium, not general ERC.

Speaking of terminators: hell, you can't even use ERC to assure that a terminator (source, load or both) is placed properly, just that it's the right way around (input, output, ground). Worse yet, it breaks bidirectional buses (which should generate a multiple-driving-source /warning/ but not error), or so on. A lot of that is PCB-dependent anyway (like physical position), but that's where IBIS comes in.

Tim

Yes, true, I do that too. Especially useful for supply rails / pours.

Yes, they are useful for single pin nets and unconnected pins as mentioned below. Leaving much else enabled always results in a lot of spurious warnings, so I turn off the other stuff. I insist on zero warnings from any of the checking tools, same as with programming. Otherwise there is too much risk of something serious getting "lost in the noise" IMO.

For programming one can correct the errors or programming "style" to remove the warnings, leading to *better* code. With PCB design there is no equivalent, you just have to ignore the dozens of useless warnings or switch them of, AFAICT.

Sure, but most of the "functionality" is effectively disabled. This is for Altium, YMMV for other systems. It seems to be standard practice judging by their forum comments, e.g. advice to "set all pins to passive" during symbol design.

Duplicate net names, asshole.

No, the implication is that there is no point.

...and your point?

Again, your point?

Since a schematic entry tool isn't a physical design tool, none of that is surprising. What was your point, again?

The design I was referring to, above, had tens of single-pin nets (well over 10% of the nets). The designer didn't run any ERC. It was "too hard". Even if ERC only checks signal names, it's worthwhile.

I'm with you on "lost in the noise". I had that problem with early FPGA tools. Millions of useless warnings hiding the real gems of the disaster world.

Certainly there are no standards in tools but the fact that some checks can't be done doesn't mean the whole process is useless.

So what's your point?

Agreed.

Tims original statement was "I largely ignore schematic ERC" (for non-digital, i.e. analog). I was providing the reason why I do that too. I do largely ignore it. Most of the "functionality" is disabled, but not all.

It seems we were just having a disagreement over the meaning of "largely ignore". ;-)