Re: gEDA-user: Schematic Level DRC DIscussion

[Steve Meier <smeier@xxxxxxxxxxxxxxxxxxx>]

I think, (caution danger) that an api that is limited manipulating the
data structures in reasonable ways won't leave the database in an
inconsistent state. For example, if the api allows you to add net
segments to a schematic or add pins to a symbol and then limit you to
asking the library to generate the nets instead of allowing you to
directly add nets the nets would reflect the schematic and the symbols.

My guile api plan is. As I add guile functions I add to the documentation.

1) Support for guile scripts to read and write schematic files and
symbol files. (Reading of schematic files is now complete)
2) writting of guile scripts for both the stock geda and my non-stock
version.
3) function for displaying page structures. (completed)
4) Functions for controlling the swapping of symbols into schematic
pages. (C code exists)
5) Support for retrieving and modifying attributes to guile.
6) Control of the netlister functions. Generate page level netlists and
buslists. Generate project level flat netlists.
7) Fetching of nets or buses from the page or flat page.
8) Fetching of pins from a net
9) Fetching of parent devices from pins
and as each step progresses document document document.

I think that given a net list you should be able to ask each pin's
parent about voltage limits. The net should know the expected voltage
levels. Did we smoke? Similarily for signals I would like to ask about
logic families do we all agree. How about asking if there is multiple
drivers for a net? are they all tri-state?

Please think about the types of questions you would ask the data
structure? Where would the answers have to come from? pin, device, net?

Thanks,

Steve Meier

p.s. I am palning on dropping my netlister which had a flow of  read all
schematic files and needed symbols run the netlister functions write the
net out, in favior of my backnet program (look for a name change or
suggest one) which will read in files based upon an input script, run a
processing script and then write output files based upon an output
script. The reading and writting of all files will be through more
scripts.  I think this will support a range of functions from,
translating, updating, netlisting, embedding, back annotating and design
rule checking.


Dave N6NZ wrote:
> Dan McMahill wrote:
>   
>>  From my point of view.... if libgeda and the scheme binding were 
>> expanded to let you have a really full featured database access via 
>> scheme, you could do all sorts of things.  However, many of them may be 
>> specific to a particular person, project or company.
>>
>> You may decree, for example, that all instances have a company part 
>> number attribute filled in.  You may only allow certain vetted symbols 
>> from heavy libraries in your design.  Maybe you have a certain minimum 
>> grid size you refuse to go below.  Maybe you want strict error checking 
>> of pin types.  Perhaps you insist on each schematic having a certain 
>> sheet or every symbol having some specific attribute.
>>
>> I think there is no one size fits all or maybe even one size fits most 
>> solution.  With a full API though, you can make it not too hard to 
>> implement most any check.
>>     
>
> Well said.  I was trying ineptly to say the same thing, but you give a 
> very good list of examples.
>
> So, how far away is the code from having an API that allows full 
> functionality for data base access, with proper guards so that no API 
> call can leave the database in an inconsistent state?
>
> -dave
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
>   



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user