X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=EYUJFKfVXeKk0itsHksVkw2Lwa+oZv2hcZKKqF9x5Es=;
	b=ITe6Kl1LlKXSPAlUBK17GRmVpkSlDftsQ6n/5J+53yS4Sa/QRpl0JEc56bnfQ5UlIO
	tkzZnQWgfiA4kd5R3lf6o2p9BpP/ixP4wZ51LDfyLcaZvE5C+/zElJjuRkxNq9YK4BsX
	XIXDVFIkJ4hD8oPDxCx2mWSp63GyfdG4Wvum+0FX2SunHrYlvr7xpj92mZsMi6HyfTZh
	dgWI0sYTwhvlwefC9NfmVeKPpK1kwPd9guDr3iYzZ0Q3u5xvPhHEFuuHKSRyGg0feh9k
	ka59yKdp5k2Aoru3y53Nve7QEqX48ED9iEz7dYNgsRc+Cf78H52k6NI5MHwwzHiROJ25
	yf6g==
MIME-Version:	1.0
X-Received:	by 10.60.246.43 with SMTP id xt11mr22761146oec.48.1451166783661;
	Sat, 26 Dec 2015 13:53:03 -0800 (PST)
In-Reply-To:	<20151226220553.0cd2c0e5128a546fbfbec42e@gmail.com>
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1512230552520 DOT 9035 AT igor2priv>
	<FC796A30-DF21-42E0-89D4-48F3C202BCAE AT noqsi DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1512230648180 DOT 9035 AT igor2priv>
	<A6BF931F-181E-4B69-8B3E-E1BD202DE7C5 AT noqsi DOT com>
	<20151223194905 DOT 7676 DOT qmail AT stuge DOT se>
	<0AB5D926-731F-4A49-AA26-D06DAE7C2CB0 AT noqsi DOT com>
	<201512240626 DOT tBO6QuW0031998 AT envy DOT delorie DOT com>
	<s6negecytg1 DOT fsf AT blaulicht DOT dmz DOT brux>
	<CAJXU7q-La9qBqbt-x8G6LnWpxaQSYiVwngVLG9ScUFzzd1TWGg AT mail DOT gmail DOT com>
	<20151224124303 DOT GA22838 AT cuci DOT nl>
	<20151224142825 DOT 23916 DOT qmail AT stuge DOT se>
	<567EE79F DOT 7080603 AT ecosensory DOT com>
	<20151226220553 DOT 0cd2c0e5128a546fbfbec42e AT gmail DOT com>
Date:	Sat, 26 Dec 2015 15:53:03 -0600
Message-ID:	<CAJXU7q9oCKBB8sL+tt5S44Doi6HXg6ywTcmFo-v8-hcNmXDFcg@mail.gmail.com>
Subject:	Re: [geda-user] A fileformat library
From:	"Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	gEDA User Mailing List <geda-user AT delorie DOT com>
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Indeed...

1 & 2 relate to design, reuse, modularity etc..
3 & 4 I feel would fit into the category of DRC rule definition /
design intent capture.

PCB's data model isn't as bad as some would have you believe, but it
isn't pretty - and could (as many have noted) benefit from some
changes.


I would argue that the DRC definitions / design intent capture should
probably be designed to have the capability of standing alone from the
PCB layer geometry design file (even if they can also live inside it
too). We'll need a data-model, as well as (probably) an on-disk
representation / encoding of that information.

The design intent data may come in from external tools (with which
we'd need to interchange), be they tools to extract data from another
format (eg. schematic?), or an external editor to input such
information.


This is an interesting area for some design work... start to think of
how all these design rules can be formally defined. How would (ideally
all of) PCB's existing design rules be represented in this format?

Do some research (of publicly available information, tutorials etc..)
to see what the capability set of other tools out there is in this
regard. There will certainly be other cases that should be considered
for DRC rule specification.. some examples (off the top of my head),
could be differential pair spacing, maximum decoupled length, maximum
pair skew, ....  These may not be all that easy to define explicitly,
but we should try!


Peter

- Raw text -