On Sun, Aug 15, 2010 at 01:11:15PM -0500, John Griessen wrote: > Andrew Poelstra wrote: > > >So here is my proposal for structuring DRC rules. > . > . > >Each rule is composed of a Filter, to choose which parts the rule applies to, > >and a Rule, to specify the parameters these parts must conform to. Both the > >Filter and the Rule will be the same data structure: let's call it a Range, > >to choose a word at random. > > > >A Range: > > 1. Can be composed of other ranges, by AND, OR and NOT operators, or > > 2. Is composed of: > > o A textual attribute name that makes sense for the given components > > o An operator: <, <=, ==, >=, >, %, "matches", "is present" (unary) > > o An integer value for the integral operators > > o A string value for the "matches" operator > > > >The string value would support the wildcards ? and * for single- and multi- > >character matching. > > Sounds good. Do you imagine constructing a set of objects, (a LISP list > maybe), > that belong to a range after the filters are done, and then doing operations > on it such as sum up number values of capacitance?
Hmm. The only "persistent" use for ranges I was considering, was to build views out of them in PCB. By default, we will create an "everything" view, along with views for each functional block - since functional blocks will be assigned by a simple functional-block attribute. There will be nothing stopping the user from making views to filter on any attribute. > If you maintain these ranges > between times and only change them as an object is added or edited, you don't > need > to "run DRC on all" very often... good for DRC as you go with low > cost of computer power. > For a real-time DRC, it would be very smart to keep ranges around and only manipulate them when necessary, as you say. I think that will be enough to keep a real-time DRC running cheaply - only starting up will be slow. Andrew _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
