kicad-developers team mailing list archive

[Chris Giorgi <chrisgiorgi@xxxxxxxxx>]

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.

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.

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

    (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.

  )

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

    (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.

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

  (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.

)
**********

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.

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.

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.


~~~Chris Giorgi~~~