← Back to team overview

kicad-developers team mailing list archive

Re: Library structure recap.


Le 02/10/2010 16:03, Wayne Stambaugh a écrit :

On 10/2/2010 6:30 AM, Vesa Solonen wrote:
On 01.10.2010 23:42, Wayne Stambaugh wrote:

5) Drop support for creating components with alternate body styles (DeMorgan).

Would this mean we also lose the possibility of representing a component
with multi part symbol and combined symbol? For example some
microcontrollers fall in between where representation with one symbol is
almost too difficult, but port level splitting is not always needed. How
about opamps and comparators with or without power pins? Also style
flexibility, like IEC / old ANSI / user defined style, etc. Embedding
multiple versions of symbols to the library would be a very useful
feature. Otherwise we need to define a policy how and when to split very
large components regarding symbols. Just to mention I hate policies very
much, but like flexibility. Naturally I'm willing to make compromises if
flexibility means too much complexity or implementation cost. I may not
understand everything correctly here, so please feel free to advice ;)

There would be no change in defining multiple parts per package symbols
for components such as op-amps and logic gates.  I am proposing that we
split the current libraries with alternate body styles (DeMorgan) out
the into two libraries.  One library with the standard symbols and one
with the alternate symbols.  I'm not sure but this may only effect the
This is useful for other libraries which handle gates (CMOS4000, CMOSIEEE...) and some components that include gates (some translators and drivers ...)
But alternate bodies cannot be stored in an other library,
but only as an alternate body of the *same* component, exactly like the other parts in multiple parts per package.
There are some reasons:
- changing the shape must be easy. This is not the case if the alternate shape is an other component (meaning delete and reload components).
- but mainly this is needed because when a component has multiples parts per package (most of gates) these parts *must be*
grouped in one package (= one footprint) when possible.
But if 2 identical gates (for instance 2 74ls00 ) are used, one with a body, the other with an alternate body,
and if these two 74ls00 come from 2 different libraries, Annotate is unable to merge these 2 gates in the same physical component,
and therefore there will be 2 footprints for only 2 gates (and 6 unused gates).

So for many reasons, I believe using different libraries for alternates shapes of the *same component* could create serious annotation problems.

So, I am not sure having alternate bodies in an other library is a good idea.

  My reasoning is that when you open a library and view a
component, you expect to see how the component will be drawn in your
schematic.  In the current design, you must enable displaying the hidden
alternate body style.  It isn't ready obvious to a user that this other
body style even exists.

It is easy to display both bodies on screen. This could be an improvement of Viewlib.
(My very old Orcad schematic tool did it).

I would rather open a library named
74xx_demorgan.lib and see the components displayed the same as they will
be when I place one in my schematic.

Before I submit the new file format document for comment, would you prefer a
more readable but larger file format:

( arc
   ( start_point 1000 1000 )
   ( end_point 1500 1500 )
   ( start_angle -45.0 )
   ( end_angle 45.0 )
   ( unit 2 )
   ( line_width 1 )
   ( fill_type none )

or a less readable but more compact file format:

( arc ( 1000 1000 ) ( 1500 1500 ) -45.0 45.0 2 1 unfilled )

I like the compact approach, but maybe a "doc header" could contain the
library grammar. Would it make sense to define a non parsed comment
area? Is pin and functional block swap is one level deeper, so it was
left out from this discussion?

I'm pretty sure adding a comment block at the top of library file can be
accommodated.  I just chose to show an arc as an example.  Once I finish
up the file format document, the rest of it will make more sense.  We
can discuss comments, pins, and functional block when I publish it.  I
just wanted to get a feel for what everyone's preference was so I can
finish up the document.

Thanks Wayne, for reworking the library. It's the cornerstone you
mentioned and will enable lots of usability enhancements.

Thank you for your input.



For other proposals, I agree.
For file format, I prefer by far the more readable but larger file format.
Because it is easy readable, one can expect:
 less mistakes (for instance for guys who create files format converters,
 easier changes in the future.

Thanks for your great work.

Jean-Pierre CHARRAS

Follow ups