kicad-developers team mailing list archive
Mailing list archive
Re: Library structure recap.
Le 02/10/2010 22:10, Wayne Stambaugh a écrit :
On 10/2/2010 11:45 AM, jean-pierre charras wrote:
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
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,
In my case they would no longer be alternate body styles, they would be
stand alone components drawn with the alternate body style extracted
from the old library format. In other words the normal body style for a
7400 would be in 74xx.lib and the DeMorgan version of the part would be
a separate component in 74xx_demorgan.lib.
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
I hope people are not doing this in their schematics.
I hope people are doing in their schematics.
Alternate shapes are *never* chosen for aesthetic reason, but because the schematic is more easy to understand.
ANSI or European symboles (sometimes called ANSI or IEEE representation, but this is not exact) can be chosen for aesthetic
reason. This is a choice.
But Alternate shapes is not a choice.
I explain (I hope...)
Gates have only a shape found in their doc.
For instance a 7400 is always shown as a "AND" symbol and a 7402 a "OR" symbol.
For this reason they are called AND gate and OR gate.
But both gates can be used in a logical schematic diagram to combine 2 input signals using a AND or OR logical function.
This is depending on active level input signal (and also the active level output signal).
A guy want to create a schematic to activate a led connected between the output of a 7002 gate and the GND,
from 2 input signals (2 push-buttons connected to ground and the 2 inputs of the gate) that *must* be both activated (AND logical
He must choose the alternate "deMorgan" representation of the 7402 gate to show:
- that a AND condition is needed
- input signals are active low.
- output is active hight.
And the schematic diagram is understandable.
And perhaps in the schematic, an other 7402 gate will be drawn with a OR symbol to explain (to reader) a OR condition is needed.
Using and mixing both shapes for gates can be see as a graphic method to synthetise logic blocs in a schematic.
For designers working on logical diagrams, a very good support of de Morgan representation is mandatory to create undestandable
Without a good "de Morgan" support,these diagrams are *not* understandable.
Imagine an analog schematic drawn by a guy who use a SM0806 footprints for both resistors and capacitors to build the design.
And because resistors and capacitors have the same footprint, he uses the same symbol in schematic.
(Understand: because I use a 7402 I use the same symbol everywhere)
Of course one say: Resistors values are in ohms and capacitors are values are in pF, so no problem to understand the schematic.
But I am not sure this is true.
Designers working on logical diagrams also are not sure using the same symbol to do different logical conditions is understandable.
I would think
most folks would choose one body style or the other. I wouldn't be to
happy looking over a schematic where half of the gates of a 7400 were
drawn in the default style and the other half were DeMorgan. Does
anyone actually do this? If so, why?
When using a gate, we want to show the logical condition between input and output signals and their active level values,
and never the physical component like it appears in docs.
I remember schematics of the first computer I worked on: a PDP11 (well: 1972... a lot of years).
It was sold with the it schematic (A lot of sheets...)
All schematic diagrams used extensively the De Morgan representation.
All Flip flops in schematic where drawn having an active hight and an active low output for the same pin.
this means the Q output pin was drawn twice
- one with an active hight output symbol
- one with an active low output symbol
This was the same physical pin, but depending on the purpose of the output signal,
schematic used the active low or the active hight symbol pin (or both) to drive the connected logic.
This approach for flip flops is very near the De Morgan approach that is used only for gates.
For experienced guys this kind of diagram was very easy to understand.
And i never have a problem to understand these schematics (I was not alone): I built some boards for this computer.
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
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).
This solves the visibility problem but does not address the underlying
complexity to the library objects required to support alternate body
styles. I'm not saying that we cannot continue to support this the way
we already do. I'm trying to find a way reduce some of the internal
complexity of the source if possible. Splitting out the alternate body
styles into a separate library is just one possible solution. There may
Thanks for your input.
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
more readable but larger file format:
( 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.
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