> 1) The way DRC currently works in PCB. I didn't find a c file detailing any > DRC related functions, for example, except possibly line.c.
Mostly in find.c, see DRCAll(). It shares a lot of code with find, because they both have to do connection checking. If we did the net-tag-everything project, we could probably move DRC to its own file. > 2) To what extent the issue of graphically representing the errors should > fall to the GUI. My original thought was, I'd like to be able to choose between, say, a tree view where the failures are grouped by type, and a layer view with a spot on each failure. Or a printed report of the failures, which I could grep through for specific ones I'm interested in. To cover all these, DRC needs to produce some data structure that has the X,Y,Z of the error, some information about the error, and references to the objects involved. Once that structure is in place, we can offer a variety of ways to display it to the user. > >1. The "non-copper layers" one. Basically, each layer needs to have a > type and position associated with it, so you can say "this layer is > a paste keep-out for the top" etc. This change is a prerequisite > to a number of other enhancements we're hoping to get to. > > Are you familiar with Eagle at all? A little. The non-copper layers project allows DRC to create a new layer (or layers), tag them as non-copper "drc" layers, associate them with copper (or other) layers, and populate them with drc-related stuff. Then, the user can just delete or hide that layer when it's no longer useful. > 3) Layers in PCB. I understand there work going on to change the way > layers are handled, for example to allow using more than 8 > layers. Will this effect coding these layer based solutions? We're already done with the more-than-eight-layers change. The default maximum is 16, but we can easily change it to more if we want. We can add a drc-to-layer function now, and change it later if the layer API changes. I don't think that would be a big deal. The layer *structure* won't change, just the functions that work with them, like the drawing functions and the autorouter. > Could you elaborate on "script" please? Are you referring to the > idea that gsch2pcb will be executing a series of pcb commands, > rather than running the code itself. pcb's internals are driven on "actions", much like Xt translations. We tie key presses, mouse movement, internal events, etc, to actions. This allows us to, for example, tell pcb to run a script. The script consists of many actions. Currently, gsch2pcb parses and manipulates the .pcb file directly. This is bad. What we want is for gsch2pcb to write a script, and invoke pcb to run the script. That way, pcb is the only one manipulating the .pcb file. > What's the element attribute table? Does this already exist? Each element, and the board itself, has a table of attributes. It's just a (string,string) pair table, so we can store arbitrary stuff like author and copyright in it. They exist. > It strikes me that if gsch2pcb is communicating with PCB to perform > it's task, two-way communication through D-BUS might make > sense. Gsch2pcb could essentially become a full conduit between > gschem and PCB. What do you think? I think there's more to the gschem-pcb communications than the parts that gsch2pcb cares about. But, if pcb's dbus were finished, the commands that pass over dbus would be... actions. Thus, gsch2pcb could use dbus as a way of giving the script to pcb, or could invoke pcb directly, using the same set of commands. > 2. Keeping track of which nets each object on the board (trace, pin, > > polygon, etc) belongs to. Currently, we have to calculate > > connectivity the hard way - by checking for overlaps. This has > > many drawbacks. What we should do is have every object have a > > "netlist pointer" or something, so comparing pointers is all you > > have to do to see if two things should be connected or not. > > This seems relatively straightforward, assuming that a "pointer" to the > netlist for each object is all that would be required. Ah, the trick is that there's a lot of code that needs to *know* what the net is. That would all need to be changed. DRC, find, autorouter, optimizers. Plus the drawing code would need to maintain the pointers each time a change is made to the copper objects. > On 21/03/07, Dan McMahill <[EMAIL PROTECTED]> wrote: > > > > I'm in favor of a hash signature based on some canonicalized version of > > the footprint. I guess you'd want to embed the hash when the footprint > > was first instantiated. > > Which would be the canonicalized version? The footprint file itself? Keep in mind that the footprints are modified through placement and rotation on the board, plus they can be modified to some extent (like renaming pins, or resizing solder masks). So, it's not the element we have *now* that we need to hash, it's the element as it was when we loaded it. The hash would need to ignore, for example, the name, refdes, description, order of pin statements, etc. Simple rearrangement of the syntax of the file should not change the hash of the element. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
