kicad-developers team mailing list archive

[Chris Giorgi <chrisgiorgi@xxxxxxxxx>]

Several years ago (20110412) on this list, I attempted to start a
discussion on this topic with Dick, but gained no traction at that time. In
hopes of providing some context in reconciling the physical vs. logical
representations and associated nomenclature, here's a repost of the main
text of my original message:

--
"  I have some thoughts that might be relevant to this discussion. I frequently
find myself dealing with parts that come in multiple variants and with
multiple packages available, such asmicrocontrollers. These ICs are good
examples of where some additional flexibility would be desirable. I'll use
the STM32F100 as an example. They are available in 4 different packages
(LQFP48, LQFP64, TFBGA64,and LQFP100), 4 different memory configurations,
and 2 levels of peripheral support.

 It would be tedious and error-prone to have to create separate parts for
each valid configuration, and frequently the choice of which package or
variant isn't decided until layout has begun. In many cases, pin functions
can be swapped or remapped to ease layout, and many peripherals have their
functions overloaded on the pins. For me, it would be ideal to treat each
interface or peripheral as a sub-part and connect signals to functions
rather than to pads; DRC could then warn if you attempt to use a pin for
more than one function.

  To provide disambiguation for the necessary functionality, I suggest a
nomenclature that allows separation of the functional view of the part from
the physical view. The terms that I have been using are:

  *part - the abstract representation
  *symbol - a schematic representation
  *device - a physical device representation
  *component - a particular device as placed on a board

  *package - the package type for a device
  *footprint - the board layout to accept a device

  *pin - a unique electrical connection to a device
  *pad - the physical pad where a pin connects to the board through a solder
joint
  *pinout - the mapping from pins to pads for a given device

  *function - an abstract representation of functionality or connectivity
  *type - the logical representation of a physical interface
  *signal - a specific electrical representation of functionality or
connectivity

  *block - a related set of functions grouped together
  *bus - a consistent collection of signals for interconnecting blocks

  *configuration - a mapping of functions to pins


Using these terms, we could assign an arbitrary number of functions to a
pin, map pins to pads for any available package, easily allow pins to be
swapped (PC3 for PB2) as well as entire function blocks (I2C1 for I2C2).
For example, something like the following structure (with details omitted):"

--snip-- (Lengthy example omitted, please see the archives for the full
text)

Obviously, some of this has been been decided and codified in the
intervening time, but I think the basic distinctions are still valid.
Without addressing the interplay between physical and logical design, it
will be nearly impossible to specify physical requirements for DRC relating
to a given set of pins based on their function, not physical location on
the package. I2C busses and Analog Input signals require very different
design rules, but may be available on the same physical pins on a
micro-controller. As for utilizing different symbols for the same part,
think about all of the ways an op-amp can be used in a circuit, and the
specific symbols used in each case in an analog signal processing chain.

   ~~~Chris Giorgi~~~

On Thu, Jan 15, 2015 at 9:14 AM, Andy Peters <devel@xxxxxxxxx> wrote:

>
> > On Jan 14, 2015, at 7:46 PM, Fat-Zer <fatzer2@xxxxxxxxx> wrote:
> >>
> >> Sorry about accidental send previous message.
> >>
> >> 2015-01-14 18:53 GMT+03:00 Andy Peters <devel@xxxxxxxxx>:
> >> > 2. Different images of the same schematic component.
> >> > There are already such variants for some common components like CP,
> also there are "small" variants for some components.
> >>
> >> Who cares about a symbol variant? Pick the one you prefer and use it.
>
>
> > yep, but for user can be able to easily chose it, kicad library should
> provide them out of the box... And I propouse a way to store them in
> library more straightforward IMO.
>
> I guess I don't see the point. How many components have different symbols?
> Perhaps passives, where resistors can either be a rectangle or the v^v^v^v
> we all know and love?
> >
> >>
> >> > In both such cases we can keep information about the component in
> single symbol.
> >> > Also as a bonus we can easily support both IEC and US symbols and use
> it in some other cases.
> >>
> >> Why? I think that a lot of advanced users will choose one symbol type
> and leave it at that, and not go the route of switching between one symbol
> variant and another.
>
> > yep, but it's a suggestion in case of open hardware environment. It may
> be usefull in case you are reusing somebody's else workarounds. but it's
> not a first goal, just a suggestion for a bit more distant future...
> > By the word, I'm not really experienced in that and may be totally wrong.
>
> If you are reusing someone else's work, the simplest path is to just use
> whatever symbol that person chose. Why complicate matters, to little, if
> any, benefit?
>
> >> > 3. To store pin number of component in additional field.
> >> > Now cvpcb guesses pin number according to the pins displayed on the
> schematics. Which is wrong if some pins are not connected/not present in
> the schematics at all.
> >>
> >> That problem is solved by not using CvPCB at all, and doing as I
> suggest above.
> >
> > Yep... From your words the getting rid of cvpcb sounds great... if you
> can handle such a work (taking in mind that schematic and footprint library
> are nearly two different pices of data for now) I, personally, will
> appreciate it... and I believe it will be appreciated by a lot of other
> members of the community... I won't have enough time and (honestly
> speaking) skills to do that on my own...
>
> That the symbol libraries and footprint libraries are separate doesn't
> bother me at all. In fact, I think that it makes perfect sense. How many
> parts use an SOIC-8 footprint? A zillion. So why carry the footprint around
> with each of these zillion parts, when each part can just point to a
> library and a footprint?
>
> I honestly don't see how setting up library _COMPONENTS_ (defined as a
> marriage between a symbol, a footprint, and something that points to, or
> is, an orderable part number) just once is more difficult that drawing a
> schematic with generic symbols and then using an intermediate tool to marry
> a symbol with a footprint _for each symbol_ and _for each new design_.
> Sure, the _component_ is "represented" by a symbol in the schematic
> library, but in most designs the schematic is the master (the "source
> code," if you will).
>
> >> OK, I realize that the point is to somehow improve library sharing. I
> think that's an excellent goal. But I also think that at some point, it
> breaks down. Unless all shared libraries adhere to the same standards,
> inevitably you have problems. And I know you can't please everyone, so
> perhaps the correct way to go is to support the hobbyists who don't want to
> create a complex library system for a small design, and the
> advanced/professional users will build company/vetted libraries.
> > Yes, that is... IMO the main audience of the kicad will be hobiest and
> some more experienced people from openhardware world for the nearest
> future. So the idea to support there needs doesn't sounds so crazy, isn't
> it? ))
>
> I'm not sure the main audience for Kicad is hobbyists. I can't be the only
> "do it for a living" EE who needs a quality EDA package and would like to
> buy Altium but can't afford it and just simply hates EAGLE.
>
> oh, and for what it's worth, I don't give a shit about the whole Open
> Hardware movement. I mean, I think it's cool, and I think it's great that
> hobbyists are interested in electronics. (And my 6-year-old son is turning
> out to be quite adept at soldering the couple of things he got from
> Adafruit for the holidays!) And I certainly am not opposed to throwing a
> design or two out there to the community to do with what they will. I just
> don't want to get caught up in the whole support aspect; I don't have the
> time.
>
> (I participate in this mailing list because I am truly interested in
> helping the developers get the OS X port functioning as well as possible,
> so I test the patches and do what I can. I'm not a deep applications
> programmer so I don't delve into the code.)
>
> ---------
>
> If anyone is still reading this far down, you may have noticed that I keep
> saying that I my schematic symbols include both the footprint pointer AND a
> custom field called "PN." This is my "in-house part number." I have created
> a simple spreadsheet, organized by PN, which takes the PN and maps it to a
> vendor and vendor orderable part number. For each part number I also list
> the schematic symbol, the footprint, the libraries in which both can be
> found, a quantity-25 price, and how many of the parts I have on hand.
>
> I export this parts list as a CSV. Then I export a BOM for the design from
> eeschema. A python script reads the parts list and the BOM and spits out a
> CSV file which contains total number of each part, vendor and vendor P/N, a
> list of reference designators for each, and a total BOM cost for the design.
>
> At some point I will add a feature which creates an order sheet to buy
> parts that I don't have in stock. (This is all really veering off into MRP
> world, isn't it?)
>
> The spreadsheet is in Apple's Numbers format. The goal is to figure out
> how to read the spreadsheet directly in an OS X program, but that's a
> project for when I have absolutely nothing else to do. And I wish I was
> clever enough to somehow embed a link to DigiKey or Mouser's price for each
> part, so then the BOM cost would be more accurate.
>
> If anyone wants a copy of the spreadsheet and the python script, hit me
> off-list.
>
> -a
>
>
> _______________________________________________
> 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
>