kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/30/2011 08:17 AM, Wayne Stambaugh wrote:
> 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.


Suggest we use the term and classname COMPONENT for instantiated PARTs. 
PART is only in a LIB, COMPONENT is only in a schematic.

Clipboard support is something a modern tool should support.

With the s-expression technology, we get modularity of object descriptions
in a general sense.  This lets us use the clipboard in more clever ways,
since we can pass any s-expression through the clipboard and guess what, its
2nd token describes what it is.


Many objects will need 2 s-expression representations:

a) a concise form and

b) a self describing form, i.e. a full form.


The concise form is applicable when that object resides in an *enclosing*
s-expression container and can have access to the data outside itself yet
still in the same containing object.

The self describing form is applicable when it must standalone, say on the
clipboard or as a separate file.



A sheet is a good example.  For it to exist standalone, and be self
describing, it would need to have its own parts_list, otherwise if in the
schematic, it would share the single parts_list of the schematic.

There will be other cases where we find the need to have the "self
describing form" and a "concise form", both for objects.


I added a aControlBits arg to some of the newer Format() functions, which
holds bit flags that allow tuning of how the Format()ing is done.

If you were going to pass a sheet across the clipboard, and have it be
usable, you have to provide the subset of the parts_list that the sheet
uses, and this gives you the "self describing form" or "full form" of the
s-expression. 

Remembering:

The LPID's in COMPONENTS will not have to include logicalLibraryName since
we have this idea that all PARTs used in a schematic by COMPONENTs must be
in the parts_list.  The COMPONENT only needs to name the PART and know it is
in the parts_list.  There is no need or use for a logicalLibraryName in the
COMPONENT's reference to the PART, UNTIL any COMPONENT sees the light of day
outside its schematic.  Then we need either the parts_list fragment to come
along, or to use a full LPID.   But if LPID, that logical library must be
the schematic of origin, because the parts_list will probably have
customized the PART using inheritance, so in most cases including a small
parts_list is going to be a better path.


This is not as hard as it sounds, since we can put more than one path
through the Format() functions, and the Parse() functions.

Clipboard support is something a modern tool should support.