kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 4/13/2011 1:00 PM, Chris Giorgi wrote:
> On Wed, Apr 13, 2011 at 06:56, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>>
>>> So you have to think out of the box to really get the large vision here.  I do
>>> not want EESCHEMA to be the sole source of part generation, or to be honest, not
>>> even the main source of part generation.
>> SWEET has succeeded when EESCHEMA can focus on *using* parts, not creating them.
>>
>> Because that is the productivity boost that SWEET and the distributed library
>> management design seek.  You become more productive when the part you need to
>> use already exists, or one close to it.
>>
> 
> Hi Dick,
> 
> I guess I wasn't very clear about the intended purpose behind my
> suggestions. Auto-generation of parts is not the goal, it might be a
> nice feature to support, but is not central to the functionality I
> propose. Let me see if I can put my thoughts in terms that are a
> little clearer.
> 
> The problems I'm trying to solve are for the user of the parts, not
> the creators. Currently, I'm doing the following when I need to use a
> microcontroller in a schematic:
>   - Create a part for the microcontroller I intend to use, with pin's
> names being used for the pin-number.
>   - Create alternate units in the part for each peripheral; the
> pin-number is the pin's name and the pin-name is the signal. The
> pin-numbers are unique within a unit, but have multiplicity within the
> part.
>   - Lay out the schematic, placing units for the peripherals I need.
> This is currently frustrating because the unit labels are limited to
> A,B,C, etc. and have no way of indicating which peripheral they're
> referring to.
>   - Create a footprint for each variant of the part, using pin's names
> rather than number for pads.
>   - Lay out board, playing with package selection by interchanging footprints.
>   - Produce output files and send to a board house.
>   - Test.
>   - Debug board failure.
>   - Curse when I realize that I used the same pin for two different
> functions or used a pin not available in the package and DRC didn't
> warn me.
>   - ECO and revise layouts.
> 
> What I would like to do is:
> - Create a part for a microcontroller and all it's peripherals.
> - Lay out the schematic, placing the blocks I need. Warn if I try to
> use a pin that has already been assigned.
> - Lay out the board, using standard footprints.
> - Produce output and send to board house.
> - Test.
> - Sign off on board.
> 
> To get there, we would need to represent the part and its variants in
> a manner that can clearly define what those variations are and allow
> DRC to identify potential mistakes.
> 

Chris,

Have looked at the SWEET syntax document eeschema_part_sexp_format_EN.odt?
Most of the issues you raise seem be covered by the proposed format.  Take a
close look at the 7400 example and I think you'll see how inheritance addresses
most your suggestions.

> Here's a break down of the logic behind the grammar I suggested:
> 
> **********
> (part REF
> -- The part identifier.
> 
>   (block "NAME"
> -- This is more or less equivalent to a "UNIT" in current parlance.

A block is a group of parts similar to a group of gates in the 7400 example.
Parts can inherit from other parts.  You should be able to define groups
(blocks) of parts any way you see fit and then create your top level part that
inherits from all the lower level parts.

> 
>     (function "NAME" (type "FUNCTIONTYPE"))
> -- This indicates that this block uses the given function of a given type.

This seems like it could be addressed with properties.

> 
>     (symbol SYMBOLDEF)
> -- This is where the symbol for this unit is drawn. SYMBOLDEF would
> allow inclusion of a pre-existing standard symbol from the library, or
> an in-place definition for non-standard symbols. We should only need
> one SPI port symbol in our library, regardless of how many SPI
> interfaces we have.

Symbol is synonymous with part.

> 
>   )
> 
>   (configuration "NAME"
> -- This defines which functions are mapped to which pins and so forth.

Inheritance gives you the ability to remap pins.

> 
>     (pin "NAME" (function "FUNCTION" (alternate "FUNCTION") (remap
> "FUNCTION")) (spec SPECDEF)
> -- Defines a pin with a primary function, and alternate function and a
> remapped function. Subsequent appearances of a pin act additively, a
> means of replacement or removal would also be desirable. A
> specification field would allow annotations that the DRC can use to
> warn of electrical mismatches.
>   )
> 
>   (pinout "NAME"
> -- This defines a particular pin-out that the part is available in.

Once again inheritance solves this problem...

> 
>     (pad "NAME" "PIN")
> -- Assign a pin to a physical pad.

and again here.

>   )
> 
>   (device "NAME" (configuration "CONFIG") (pinout "PINOUT") (package
> "PKG") (attribute "NAME" "VALUE"))
> -- Define an available device with a configuration, pinout and
> package. Allow attachment of named attributes for things such as
> memory or clock speed to display for the user and possibly use for
> DRC.

This is the one issue that SWEET doesn't address.  I agree Dick's suggestion
that this is a higher level concept and could be implemented as part of the
schematic file format.

> 
> )
> **********
> 
> The grammar above is not complete by any means, rather a framework to
> integrate with the rest of the existing grammar; I haven't reiterated
> things such as drawing primitives.
> 
> Here's what a user would see:
> 
> In the component chooser, they would select the desired part. They
> would have the option of specifying the particular device at that
> point in time, but would most likely not. Once they've chosen the
> part, they can select which block to place, much as the units are
> handled now; perhaps a dialog would allow them to select all of the
> blocks they need in a single operation. They lay out the schematics
> using the blocks, receiving warnings if a connection to a pin
> conflicts with an existing one in another block. Once the schematic is
> laid out, they select a device that supports all of the required
> peripherals in a package that fits the application. This choice can be
> changed either from the schematic or from the board layout, as
> desired. Running DRC would warn about possibly problematic
> connections, such as a 3 volt MCU connected to a 5 volt logic chip.
> DRC errors would be corrected, and board layout would ensue.

Properties can be used for ERC parameters.  We already have reserved properties
spice modeling.  I see no reason why we couldn't reserve some properties for
more advanced ERC.

> 
> To obtain maximum reuse, perhaps it would be worth considering
> separating the symbol library from the part library? Capacitors come
> in many sizes and shapes, but are represented by only a small handful
> of symbols. There are a few common logic symbols, but a plethora of
> parts implementing them. I would be perfectly happy to create only one
> SPI port or modem interface symbol and simply include the appropriate
> symbols when creating new parts having that functionality. Things that
> are largely invariant shouldn't be duplicated if it can be avoided.
> One 100 pin TQFP is essentially the same as any other, the only
> difference is which pins do what, not where those pins are drawn.

I know it's getting redundant but inheritance covers this as well.

> 
> As to human readability and writability, I've tried to make the
> grammar straightforward and intuitive, but would welcome any
> suggestions or thoughts you may have. For the fragment I generated I
> went straight off the datasheet for the part. It took me a few minutes
> to put together, but I'll admit it would take a fair while to define
> an entire part with 100 pins and several times that number of
> potential pin functions. This is a place where further fragmentation
> through inheritance may make a lot of sense.

I think if you take a careful look at the SWEET documentation that most of your
issues are already addressed.  With your proposal you still have to define all
variations of a component in order to be able change them on the fly.  I don't
see how much of an advantage that gives you over SWEET if your parts are well
designed.  That becomes an issue for the part designer.  I could have just as
easily made the 7400 in the example a flat part but the goal of that example
was to show the power and flexibility of inheritance.

Wayne

> 
> 
> ~~~Chris Giorgi~~~
> 
> _______________________________________________
> 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
>