kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 3/29/2011 7:15 PM, Dick Hollenbeck wrote:
> On 03/29/2011 01:57 PM, Wayne Stambaugh wrote:
>> Before I get started on the new schematic file format I want to get some
>> feedback to avoid heading down the wrong path.  I have compiled a list of
>> potential changes that need to be discussed before work can begin on the new
>> schematic file format.
>>
>> 1) Since the new part library source for parts in the schematic is going to be
>> included in the new file format, should links to external part library sources
>> be specified in the schematic file or should they be pushed up to the schematic
>> editor level?
> 
> Both.  There is to be a personal lib_table and a schematic resident lib_table.
> 
> For the schematic lib_table, simply plan on having a (lib_table...) in there.
> 
> Taking from sch_lib_table.h:
> 
> 
>  * The applicable library table is built up from several additive rows
> (table fragments),
>  * and the final table is a (conceptual) merging of the table fragments. Two
>  * anticipated sources of the rows are a personal table, and a schematic
> resident
>  * table.  The schematic resident table rows are considered a higher priority in
>  * the final dynamically assembled library table. A row in the schematic
>  * contribution to the library table takes precedence over the personal table
>  * if there is a collision on logical library name, otherwise the rows simply
>  * combine without issue to make up the applicable library table.
> 
> We really don't have to lock down the (lib_table ...) format, since parsing
> of that element
> should be handed off to the LIB_TABLE::Parse() function in a nested fashion.
> 
> The only change I had contemplated to (lib_table...) was to add a
> *description* field.  But again, simply placing a "(lib_table...)" in the
> schematic should suffice for now.
> Class LIB_TABLE decides what that is.  The function header comment to
> LIB_TABLE::Parse() has a current grammar example, another one exists in
> test_sch_lib_table.cpp
> 
> 
> The lib_table in the schematic does NOT have to hold all the LIBs used in
> the schematic, the balance must come from the personal table, or the world
> global table if we want such a thing.

I'll include support for external library sources in the file format.

> 
>> 2) Include meta-data type information such as file creation date, last modified
>> date, file format version, etc. similar to the first line in the old file
>> format?  If so what information to include?
> 
> Roughly what we have now, I cannot help much here.  Suggest encapsulating it
> all into a class object so the parsing of it can be done by a nested parser
> with separate keyword space.  The more we an divvy up keywords into separate
> "spaces" the faster the loading will happen, even with the binary search
> currently used in DSNLEXER.  A hashtable or gperf looms, but having separate
> keyword spaces is prudent and sensible.
> 

I'm thinking the properties keyword would be appropriate here.  A name/value
pair for defining properties makes sense but there may be better ways to
address this.

> 
>> 3) Eliminate layers since they are not really used in EESchema other than for
>> defining the display color of the object?  Adding wire and bus classes would
>> eliminate the need for layered line objects.
>>
>> 4) Provide support for schematic editor settings that can be restored between
>> schematic editing sessions?
> 
> YES!  It would be cool to have basically *all* the settings in there.  I see
> value to even recording the current sheet in view, maybe even the mouse
> pointer setting, colors, what not, so that a user can pass a schematic file
> to a support person and actually convey what he/she is seeing and how it looks.
> 
> 
>>
>> Here are a few ideas I would like to see in EESchema that would require some
>> additional concepts in order to support.
>>
>> * Use system fonts instead of the custom line drawn fonts since they don't need
>> to be accurately converted to gerber files as in PCBNew.
> 
> "system fonts" needs to be better defined.  The goal is probably achievable,
> but to maximize portability of schematic files, we have to be careful about
> this.  AUTOCAD can do this, so we know it can be done.  But maybe relying on
> a set of publicly available, cross platform system fonts that *must be
> installed* is a middle ground.  If we base it on some kind of font
> technology that can be assumed present on all supported platforms, maybe TTF
> or something.  See what wxWidgets offers WRT fonts.  I hope we can avoid the
> problem of font mapping when the referenced font is not present.  It would
> be ideal if we could assume it is present.  Otherwise you get pushed into
> font mapping unconditionally, and that is large problem space in my opinion.

We've seen good examples of how not to handle fonts.  Initially I figured we
would stick with what we have now but the underlying file support would be
there when/if we decide to implement this feature some time in the future.

> 
> 
>> * Support adding images either as file links and/or embedded in the schematic.
> ok
>> * Support custom legends, title blocks, and title block fields.  Corporate
>> users tend to have strictly defined requirements when it comes to documentation
>> formatting.
> ok
>>
>> If you can think of anything else, please bring it up now so we get the new
>> schematic file format as well defined as possible up front.  Please try to keep
>> the discussion limited to the schematic file format.  I see a lot of potential
>> for this discussion to spiral out of control.
> 
> You had said that we can duplicate the notion of instantiation of sheets by
> using instantiation of parts as a reference.  I disagree.  Parts are wired
> by netlist.  The nestlist is separate from the parts.  I think we need to do
> better than that WRT sheets.   More like verilog, or an annotated binding on
> the sheet's I/O parameters.  I did something like this in a past life, I can
> dig it out if nothing comes to you.  This concept is reusable later because
> if taken far enough you can then "arbitrarily fragment" your schematic into
> reusable blocks, blocks which might not necessarily be "sheets".  Aw sheet,
> I just made a lot of work for somebody.
> 
> Here's some verilog I just wrote today:
> 
> off_delay #(5) od1(
>     .clk_i          ( clock ),
>     .rst_i          ( !enable ),
>     .bit_pulse_i    ( bit_pulse ),
>     .enable_i       ( state==STATE1 ),
>     .off_delay_o    ( enable1 )
> );
> 
> 
> The clk_i is an input parameter defined within module off_delay.  od1 is the
> instance name, and here we are binding od1's clk_i to our outer clock.  The
> conversation subject I think is best called "sheet bindings".

I agree with your assessment on sheets.  I was thinking that a sheet is an
instantiation of another schematic (or what ever we call it) embedded in the
root schematic (I'm operating under the assumption that we are doing away with
external schematic files).  Each sheet contains the instantiated part
references (in the same way that a schematic part is an instantiation of a
library source part) for each part in the schematic the sheet references
instead of the external path implementation we have now.  This creates a
natural hierarchy which can be descended and ascended without any external
requirements for handling the references.  You could even force this behavior
on simple hierarchies and the root schematic/sheet pair so that you always have
consistent file definitions no matter what the type of schematic hierarchy.
These are details that will definitely need to be hammered out.

This does raise the question of sharing schematics (circuits may be a more
descriptive term) across projects.  We may need to implement a circuit source
similar to a library source for sharing circuits across projects.

Wayne

> 
> 
> Dick
> 
> 
> 
> 
>> Thanks,
>>
>> Wayne
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>