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=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=qoNq5GVeWidqtDwVzP+WhBdqvmvIENKM1nGyfNX46bs=; b=Udb/UF4uivXAZGJ+F27PCoORE6pmKQoHfP657iwdk4bGlI87fSi+NRd8vlDtlH5VaX uB8C/gJrw97h+38NjXIUwDU2/DWySZpZwUfwjRmAFX+YXOsM6GpRiAitSbh10ZT/WW3p Yzj4twX1U1RZfsCqCKbGfL2J+1yhHNzif4QUFyGPXt/FWYWZYVGYyWEER8z3iQU9USJ+ plO8PAx3muWj9FSr6sBqYn2sAMOz4SwtgAeuKKLvAZ415Znil3e1jTQ40j1sAgKiO5xj jpRJXAtWnfe6bWGJO+UobmJVqIP1bBQ6G50OvXr9dmNY7Ku4Qikasl9xATk3+zNNnSHb hDsA== X-Received: by 10.28.65.193 with SMTP id o184mr29765170wma.15.1451173342052; Sat, 26 Dec 2015 15:42:22 -0800 (PST) Date: Sun, 27 Dec 2015 00:42:20 +0100 From: "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] A fileformat library (DRC clearance value storage) Message-Id: <20151227004220.58af03f12477adc4bc25781d@gmail.com> In-Reply-To: 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> X-Mailer: Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 > ... > 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. I would say DRC clearance and copper width should be stored in the netlist. As separate data structure where values are given for the nets would of course also work. > ... > 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? For a given net there would a need to know clearance distance to each other net. If for a net there where a default clearance and it where possible to add a list of clearance values to other nets, clearance distance to each other net would be known. If it works for one net it could be simply be applied for each other net. It would be much simpler to work with if there where net classes or similar but I think they could be implemented more or less as a variable. To store copper width for a net should not be a problem but it would also be good with copper width possibility for copper width per segment. I think it would also be useful with support for a named variable instead of giving the value directly. Nicklas Karlsson