On 11/6/07, Dave N6NZ <[EMAIL PROTECTED]> wrote: > > Steve Meier wrote: > > > What do we expect the schematic DRC to catch? > > The problems that apply to *my* situation and *my* technology. Also, > violations of the in-house design style guides that only I use -- for > instance, require a partnum attribute whose value exists in the > purchasing database. > > In other words, generic DRC is largely pointless. DRC should be > implemented as a DRC engine and a rules database. Of course, one hopes > that a (or two or three) good, reasonably generic rule sets can ship > with the release. End users can start with that and tweak to their own > needs. > > The trick, it seems to me, is to come up with a clean and readable > syntax for the rule set. The language needs to be declarative at its > core, and allow user plug-ins written in C (so that I can run SQL > queries against my parts database, for instance.)
Have you looked at Prolog? It is an interesting language. A Prolog program is a set of patterns and actions. For example to write a sortting program you could give as a pattern "x[i] >x[i+1]" and the action would be the exchange x[i] and x[i+1]. In Prolog data and program have the same syntax For DRC in Prolog, one way would be to first "facts" about the devices and the pins. These "facts could be written in Prolog and stored with the symbol. Rules would be patterns. These are declaritive and would say things like Power inputs must by connected to power sources. Source must be able to drive loads,.... One of the nice things about adopting an existing language is that there are existing interpreters and impotently books and tutorials. People have written very complex programs in Prolog, several so called "expert systems" and it would be agood way to implement features like autoplacement and autorouting. -- ===== Chris Albertson Redondo Beach, California _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user