kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.

> 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.


> 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.


> * 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".


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
>