kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/3/2010 8:05 AM, jean-pierre charras wrote:
> 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
>>>>>> (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
>>>> 74xx.lib.
>>> 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
>>> gates).
>>
>> 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).

My reasoning wasn't about aesthetics.  It was about consistency.  If I'm
looking at a logic block of AND gates where some are drawn in the
standard style and some in the DeMorgan, I have to keep shifting between
the two styles.  I already know the logic of a AND gate so changing the
symbol to represent the active logic state in the middle of the
schematic does not help me follow the logic any more clearly.  Obviously
other people prefer this method so it will have to be implemented in the
new file format.  It already exists in the component objects so there
isn't any reason to change that code.


> 
> For instance:
> 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 function).
> 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 diagrams.
> 
> 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?
> 
> In short:
> 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...)

Thanks, you're making me feel young;)  My first work computer in 1986
was an IBM PC that came with the schematics.  I wonder what the chances
of getting the schematic for your latest computer are?

Wayne

> All schematic diagrams used extensively the De Morgan representation.
> And more:
> 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
>>> idea.
>>> Sorry.
>>>
>>>    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
>> be others.
>>
>> Thanks for your input.
>>
>> Wayne
>>
>>>
>>> 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.
>>>>
>>>> Wayne
>>>>
>>>>>
>>>>> -Vesa
>>>>>
>>>
>>> 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.
>>>
>>> Wayne,
>>> 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
>>
> 
>