Custom DRC Rules - more granular control for ECSS specifications

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.

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…

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:

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.

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

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?

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…

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