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:content-transfer-encoding; bh=gWBBjUN5Jo+xyPJka/fDcqrq4GJc6PVkU4+ncnnbup8=; b=j28yGN3EoUlROaCNfakX4Jg3C5xLu7a8VtAh5nDRAwJT9HIZahYxJKhsd840p9IbaS 6A6F47/+T/9xitYF+0lGmTDCX2nSeTQQfSCjjBUbuvENiqYyqtB+VwgZzTPy6FG16yF9 O93EteyIkMPIAvovFAC4tuk/PXJzBgYf4FZdv8Qe1MuilUXz8m+dBwkdJQLYVugTP44U xbTnwrb4SQYSXhlPaXezIe7SOAtVx3UgvSiKRpocrZrYjKO16RWzkDJHWb2me8pd8rpu NsOX1L+BOn9XXnqpD4CpyagaQ3i3Wz24p0JyyBN6G1uD/9sNTXhg2xtBU2C6YUEy1f1X Ldsg== MIME-Version: 1.0 X-Received: by 10.60.232.231 with SMTP id tr7mr1053025oec.27.1450816069510; Tue, 22 Dec 2015 12:27:49 -0800 (PST) In-Reply-To: <20151222204233.0ccc392762ac3ee53ed6bad0@gmail.com> References: <20151221030451 DOT 02399163eb3e40f21c622c41 AT gmail DOT com> <20151221203331 DOT 20837 DOT qmail AT stuge DOT se> <20151222002012 DOT a88d7fe32a9336855eccd1d0 AT gmail DOT com> <201512220412 DOT tBM4CJxb018546 AT envy DOT delorie DOT com> <20151222153828 DOT 28d3996c10f3182c5efc780a AT gmail DOT com> <20151222204233 DOT 0ccc392762ac3ee53ed6bad0 AT gmail DOT com> Date: Tue, 22 Dec 2015 20:27:49 +0000 Message-ID: Subject: Re: [geda-user] Proposing a New Hierarchical Data Structure? 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id tBMKRrk4006425 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 On 22 December 2015 at 19:42, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > What we arguing about is usually not real problems or any problems at all, usually it is the best method to implement something ... > Only real problems I could find is copper overlap and clearance. What pcb really lack is different clearance between different nets. Implementing stuff like selection of clearance and trace width from net attributes or similar should be straight forward although their may be a lot of arguing about best method to implement. How PCB works this out, is by bloating individual net elements, and checking to see if by enlarging the track by the minimum DRC clearance, whether or not it changes the netlist connectivity. (E.g. if this track were fatter by 0.5mm, would it change the netlist -> clearance must be <0.5mm). Actually working out the minimum distance would take some more creative algorithms I think - although should not be overwhelmingly different. Regarding net-classes and clearances... this has LONG been on my wishlist... I would love if you wanted to implement it. The case I'd have was PSUs, where you might have line-side connected nets, and secondary-side connected nets. You would then specify a clearance between the groups (derived from the regulatory rules). Alternative use-cases, HV multipliers - nets tagged with nominal voltages, or pair-wise net data on differential voltages. (And a rule to translate maximum voltages into a minimum clearance). Noisy / clean signals might also be interesting to track. For me: Step 1 is figure out how to specify the driving data. Step 2 is add this to the internal data model Step 3 is provide ways to load (and possibly save) the data Step 4 is provide a DRC check to test against the data Step 5 is update / tweak online DRC checks to show / enforce clearance requirements during actual tracking Let me know if I can be of any help if you decide to proceed. Its been a while since I braved PCB's DRC code, but I was at one point familiar with it. Peter