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: <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> <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: Subject: Re: [geda-user] A fileformat library From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" To: gEDA User Mailing List Content-Type: text/plain; charset=UTF-8 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 Precedence: bulk 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