Need some guinea pigs for a rule-based DRC <<PROTOTYPE>>

[hildogjr]

Three questions to guide my design:

I am design a board with some options to assembly the power regulation (linear or switching). To save board space and force only one to assembly, I am using one footprint over other in the board region.

1. Is it possible to use a rule to disable the courtyard check for one specific component?

I am also using hierarchical page design and thinking.

2. Is it possible to propagate a rule to all different instances of one part in each hierarchical sheet / group? (I imaged that not, but just to hear some discussion/possibility).

In case of re-annotation / change of reference values of some.

3. May I need to be concern if this part compose some rule declaration? Os is there some update procedure such the ${foo:REFERENCE} variables.

[craftyjon]

I’m not sure about the courtyard question, @JeffYoung?

@hildogjr

Is it possible to propagate a rule to all different instances of one part in each hierarchical sheet / group? (I imaged that not, but just to hear some discussion/possibility).

Not directly (this is somewhat related to the Rooms feature planned for V7). I think the only way to do this in V6 would be to use special symbol fields unless Jeff can think of another.

@hildogjr

May I need to be concern if this part compose some rule declaration? Os is there some update procedure such the ${foo:REFERENCE} variables.

Yes you need to be concerned about this, there is no automatic way to update if you have a rule referencing U10 and you reannotate it to U20. Then again, this has also been my experience with commercial tools If you like to reannotate parts after you start layout, I recommend not writing rules that use part references personally (there is usually another way)

[JeffYoung]

@hildogjr

Is it possible to propagate a rule to all different instances of one part in each hierarchical sheet / group? (I imaged that not, but just to hear some discussion/possibility).

No, but you can exclude the error. Just run DRC, right click on the error, and select “Exclude this violation”.

[hildogjr]

I am design some resistive voltage divisor for measurement

I want to put a progressive track-to-* clearance restriction with exception of the next voltage point (e.g. v0+ to v1+, that have a lesser voltage diference). The aggravating situation if that I use few of this circuits inside hierarchical blocks. So, the rules that I designed use * operator and are:

(version 1)
(rule measure_v0
	(constraint clearance (min 2.5mm))
	(condition "(A.Net == '*v0+' && B.Net != '*v1+') || (A.Net == '*v0-' && B.Net != '*v1-')")
)
(rule measure_v1
	(constraint clearance (min 2mm))
	(condition "(A.Net == '*v1+' && B.Net != '*v2+') || (A.Net == '*v1-' && B.Net != '*v2-')")
)
(rule measure_v2
	(constraint clearance (min 1.5mm))
	(condition "(A.Net == '*v2+' && B.Net != '*v3+') || (A.Net == '*v2-' && B.Net != '*v3-')")
)
(rule measure_v3
	(constraint clearance (min 1mm))
	(condition "(A.Net == '*v3+' && B.Net != '*v4+') || (A.Net == '*v3-' && B.Net != '*v4-')")
)

Does this make sense? If I understood correct…

How to use this rule to make those net distances to other elements? (board edge, etc).

[JeffYoung]

Looks correct to me, though I haven’t tried it…

[aaron]

@JeffYoung it great to see new rule-based DRC. Way back we discussed BGA escape routing. I am not clear on this in the new rule-based system. Is it possible to have an area around a BGA with one set of rules, and then another set outside that area? For instance, traces at 3/3 under a BGA, then 3/5 outside the BGA area.

Different DRC for different layers

Others may know better, but I do not believe this is possible at the moment. I have a board with a 0.8mm BGA requiring differential escape routing with different DRC rules within the BGA footprint than outside of it per the PCB house process. I had to bounce the nets between two classes. It would be nice to setup DRC per region or layer. Off to look if there is a feature request posted for this…

[craftyjon]

@aaron

Is it possible to have an area around a BGA with one set of rules, and then another set outside that area? For instance, traces at 3/3 under a BGA, then 3/5 outside the BGA area.

Yes. We renamed “keepouts” to “rule areas” in 5.99 precisely for situations like this: you can now create a rule area, give it a name, and reference it in DRC rules (those rules don’t necessarily have to be keepout rules)

[eelik]

@eelik

@eelik

but is there a way to ignore a clearance completely? Now there are constraint min, max, opt. There’s no obvious way to set it to be ignored so that for example I could create a rule area inside a castellated footprint which would allow having tracks over the edge.

I still don’t have an answer to this.

And still this is unanswered. Here’s an example:

Here’s the rule:

(rule ldsfkj
(condition "A.insideArea('castellated') && A.Type == 'pad'")
(constraint edge_clearance (min 0.0mm))

Basically it should work (at least according to my personal logical intuition) but it doesn’t.

EDIT: not allowing overlap for two copper items of different nets makes sense. But it should be possible for copper/edge. Maybe a new keyword for edge_clearance, for example ‘allow_overlap’ or ‘ignore’ or ‘none’?

(constraint edge_clearance (allow_overlap))

[craftyjon]

Basically what you are asking for is to create conditions where some checks are completely disabled. This is useful for a number of scenarios but I think is not yet possible.

For 6.0 your best bet will be to mark these violations as ignored, I think.

[eelik]

Unfortunately it also means I can’t conveniently route castellated pads. This can be very counterproductive. One castellated edge can have tens of pads and each one has to be routed using highlight collisions mode.

[craftyjon]

@JeffYoung are there any easy fixes here?

I think this is “kind of” a regression, as the router didn’t look at edge clearance before. Can we easily change it so that clearance <= 0 allows collisions?

[JeffYoung]

Well, 0 might have meaning (“no clearance required, but collisions not OK”).

It would be very easy to have < 0 disable the edge-clearance test, but it sets a precedent that it might work elsewhere (and it might be much harder to implement for the copper-clearance rule). I was sort of hoping for some flash of inspiration that didn’t require “magic” numbers…

[craftyjon]

That’s true. I think the best way would be to add a new keyword and allow you to say (constraint edge_clearance disabled) but I’m not sure how invasive that would be.

[JeffYoung]

I have committed a change which will interpret a negative clearance as disabling the checks for:

• copper clearance
• edge clearance
• courtyard clearance
• hole clearance
• silk clearance

Report bugs in the usual place…

[JeffYoung]

The syntax for recognising unconnected nets has changed. Instead of:

A.NetName == 'no_connect*'

you’ll need to use:

A.PinType == '*no_connect'

This will also ensure that it only applies to pads (and not other members of the net).

For those curious, the PinType property of a pad has the following values:

input
output
bidirectional
tri_state
passive
free
unspecified
power_in
power_out
open_collector
open_emitter
no_connect

Pins that have been annotated in the schematic with a “no connect” symbol will look like:

passive+no_connect
output+no_connect
etc.

(Thus the requirement for the * at the beginning of the match if you want the rule to match on both no_connect pins and no_connect schematic annotations.)

[eelik]

@JeffYoung

Report bugs in the usual place…

I.e. here… (OK, I’m willling to report bugs in gitlab, but here are some quick notes.)

That’s great, now it’s possible to create castellated pads/footprints. Here’s my final rule:

(rule 'castd'
(condition "A.insideArea('castellated') && (A.Type == 'pad' || A.Type == 'track' || A.Type == 'zone')")
(constraint edge_clearance (min -1mm))
)

Here’s the footprint on a board:

There are a couple of problems.

• It doesn’t work for zones, although it doesn’t matter in this case because the zone reaches the pad anyways. And it’s questionable what it should co in case the zone would be poured beyond the edge cut.
• The track doesn’t stop at the pad center but at the edge cut. This may be a problem because the global edge clearance constraint isn’t obeyed by the pns router, it stops all tracks in the same way. So, if there’s a more general bug in track/edge clearance, it may cover another possible problem in this local area rule.

This was routed with Shove but DRC gives an error.

Here’s the project, it should be easy to do tests with it. suppress_edgeclearance.zip (14.6 KB)

[JeffYoung]

It’s also not going to do what you think for zones because A.insideArea() means the whole copper zone would need to be inside the castellated rule area. So you’d need to have a separate “castellated connector” zone that you reference by name to set its edge clearance to -1.

[eelik]

@JeffYoung

A.insideArea() means the whole copper zone would need to be inside the castellated rule area.

But pads and tracks don’t need to. That’s a bit confusing.

If I change the condition to

(condition "A.insideArea('castellated')")

It seems to take also the edge.cut graphics as A and if it’s a continuous shape (rectangle) the constraint overrides the global constraint for all the edge cut, even if only a tiny bit of it is inside the rule area.

I didn’t realize earlier that rule area doesn’t mean that some rules are used inside that area, but only that some parts of items are inside the area. Doesn’t that create problems because for example track segments can continue far away from the area and then the minimum values can’t be controlled outside the area?

[craftyjon]

@eelik

Doesn’t that create problems because for example track segments can continue far away from the area and then the minimum values can’t be controlled outside the area?

The typical scenario I think about with track widths and rule areas is constraining an area of tighter width/clearance so that the cost impact is lower.

So, maybe in most of the board I want 0.2mm width / 0.2mm space, but near a BGA I need to let it be 0.1mm / 0.1mm.

If I have a rule area for this, that means that a segment that crosses outside the rule area would have part of its body in the default clearance area, so it needs to meet the 0.2/0.2 rule. It would be incorrect to let that whole segment be 0.1/0.1 just because part of it was inside the rule area.

[eelik]

@craftyjon

It would be incorrect to let that whole segment be 0.1/0.1 just because part of it was inside the rule area.

I understand that, but isn’t it contrary to what I demonstrably see in my example? I need stricter rule, i.e. larger clearance for most of the copper/edge contacts – just like larger clearance is used for most of the tracks on the board. Then I need it to be ignored in one place – just like smaller clearance is used for a BGA. But what I see is that the stricter rule is relaxed also outside the rule area if the segment continues outside it.

That’s of course what I actually want and need for the castellation, otherwise the stricter rule (keep the normal edge clearance) would be kept inside the rule area, too, when routing inside the area. That would be cumbersome.