Custom DRC Rules - more granular control for ECSS specifications

Layout
#1

I am currently working on implementing the design rules for the ESA Spec ECSS-Q-ST-70-12C in custom DRC rules for a project.

I’m running into some specific cases that the custom drc rules don’t seem to be able to cover completely, however this is not a complete list:

  1. Minimum clearance for vias from SMD pads, which is dependent on the track width. My best workaround so far is this:
(rule distance_via_from_smd_pad
	(constraint physical_clearance (min 0.25mm))
	(condition "A.Type == 'Via' && B.Pad_Type == 'SMD'")
	(severity error))

(rule track_length_smd_pad
	(constraint length (min 0.25mm))
	(condition "A.Type == 'Track' && A.Width < 0.3mm && (B.Pad_Type == 'SMD' || B.Type == 'Via')")
	(severity error))

(rule track_length_smd_pad_wide_tracks
	(constraint length (min 0.7mm))
	(condition "A.Type == 'Track' && A.Width >= 0.3mm && (B.Pad_Type == 'SMD' || B.Type == 'Via')")
	(severity error))

However, this feels like a hack, and doesn’t properly cover the case. Is there a better solution?

  1. Different clearances for component and solder side for through holes. Is there a way to match on the side a component is placed on for a pad constraint?

  2. Constraints dependent on values of items under test. E.g. requirement 14.3.5:

The track width connecting to soldering pad of PTH shall be maximum half of the diameter of the pad.

This doesn’t seem to be possible:

(rule maximum_track_thickness
	(constraint track_width (max "B.Diameter / 2"))
	(condition "A.Type == 'Track' && B.Pad_Type == 'Through-hole'")
	(severity error))

Are there solutions to those, or are those rules maybe not meant to be that granular?
Of course I could just assume the largest clearances etc, but that will likely lead to space problems later on and doesn’t feel clean.

#2

I think your solution to (1) is about the best you’re going to do.

You can check which side a footprint is on, but there’s no way to get from the pad to properties of the parent footprint. I’ve recently introduced a memberOfFootprint(foo) function, but to use that you’d have to have a policy of using different reference-designators for back-side components or something, which clearly isn’t ideal.

(3) is sort of the same problem as (1). You could again introduce a stepped set of rules, but it’s not a direct match.

Log a feature request on GitLab for “A/B references inside constraint expressions”, and I’ll look into whether or not it would be a huge effort to add…

#3

Thank you for your reply. I have created the issue:

Relating to (1): I have realised the issue is more complicated than this.

The rule

(rule track_length_smd_pad
	(constraint length (min 0.25mm))
	(condition "A.Type == 'Track' && A.Width < 0.3mm && (B.Pad_Type == 'SMD' || B.Type == 'Via')")
	(severity error))

can’t ensure a minimum distance, it would need a constraint similar to free_segment_length or so:

free_segment_length
free_segment_length721×304 30.1 KB

Conversely, the rule

(rule distance_via_from_smd_pad
	(constraint physical_clearance (min 0.25mm))
	(condition "A.Type == 'Via' && B.Pad_Type == 'SMD'")
	(severity error))

Can’t have knowledge of the track width. I would need to be able to access connected items to A, something like this:

(rule distance_via_from_smd_pad
	(constraint physical_clearance (min 0.25mm))
	(condition "A.Type == 'Via' && B.Pad_Type == 'SMD' && B.ConnectedItem('Track').Width < 0.3mm")
	(severity error))

The more I think about this, the more I personally like the idea of a DRC scripting interface in python.

#4

Indeed, it’s going to be difficult to squeeze a case like this into a declarative rules language…

#5

So I’ve been digging around a bit, correct me if I’m wrong, but there doesn’t seem to be a straight forward way to place a DRC marker from the python api?
The PCB_MARKER class is accessible through python, but the DRC_ITEM class doesn’t seem to be accessible, which (if I understand it correctly) needs to be constructed for a valid marker.

Would it be enough to make DRC_ITEM accessible to place a marker, or would there be the need for more in depth changes to make this possible?

#6

If you generate a report it’s also going to expect the DRC_ITEM to have a DRC_TEST_PROVIDER (returned via GetViolatingTest()). The only thing needed from the DRC_TEST_PROVIDER API is GetName(), but it would be nice to have some way of returning the name of the Python script there…

#7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.