-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 04.09.2010 01:44, schrieb Andrew Poelstra:
>
>
>
> Hey all,
>
>
> I am working on the structuring PCB files in terms of functional blocks,
> and generalizing/extending the DRC rule format. (Things have slowed down
> as summer is ending but I am still working on this.)
>
> Mostly I am doing GUI work, since that is more-or-less stateless; I can
> spend 20 minutes reading docs or GTK code and not worry about making it
> work with PCB.
>
>
> But for the underlying logic:
>
> Naturally, I want to avoid any breaking changes to the PCB format, both
> to increase the chances of my code being accepted, as well as the obvious
> compatibility reasons.
>
> So I have a few thoughts:
>
> 1. Initially my plan was to tag every object in the PCB with a functional
> block. This would make attaching multiple tags easy, though it might
> bloat the file, and would be slow to initially parse and search.
>
>
> 2. Another idea would be to create functional blocks as "recursive PCBs".
> This has been mentioned a few times on the list, and creates all sorts
> of exciting possibilities - from importing recursive schematics to
> reusing layout parts to clearer source control of PCBs.
>
> However, this also brings the ability to edit PCB components
individually,
> which means that some parts could have different layers than others, for
> example. And then you have to deal with layer mappings and
stuff and it's
> a huge complicated mess, both for the user and in the code.
>
>
> What do you guys think I should do? What would require the fewest changes
> to the PCB format, if any?
>
> Generalized DRC rules at least could be tacked on anywhere and would be
> quietly ignored by old versions of pcb, right?
>
>
> Andrew
>
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
Andrew,
here are my thoughts about DRC:
There are (at least) 2 contributors to what should be checked by DRC:
1. The obvious one: The capabilities of the manufaturer, e.g. min trace
width = 4 mil, min distance = 4 mil, min drill .....
2. The usage pattern: Traces where you expect high current (Vdd, GND,
...) can't use the minimum trace width, while traces that carry high
voltages (and need to meet UL, VDE specs) can't have the minimum distance.
A conclusion of the above is that the DRC rules are on a net base
(potentially on a layer base, if you forece nets with a similiar DRC
requirement to the same layer (sharing the copper with otherlayers).
I see 4 roout styles in the defualt PCB, they could be used to work
around a net specific definition.
- From my point of view, there should be a way of defining net attributes
from geda (see thread wishful UI).
If you want to exetend the DRC capabilites things like handling of
differenatial pairs, comparing netlenghs of busses comes to my mind.
Going slightly off-topic, one goal would be to extract all physical
parameters of a board (RLC for each net segment) and feed that back into
a simulation (spice, gnucap, ...).
- --
Mit freundlichen Gruessen
Dietmar Schmunkamp
PS: I won't have internet access for ht next 2 days, I'll comment
responses on Tuesday.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAkyCyxIACgkQn22l+QvEah2PAwCeLQsgUm4urwLKxNah0S9uIciZ
TV8AoJiLd2dH/pZ/Fy+yWvSuoNdT+bZk
=Y576
-----END PGP SIGNATURE-----
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user