kicad-developers team mailing list archive

[Vesa Solonen <vesa.solonen@xxxxxxxx>]

05/04/14 12:29, Nick Østergaard kirjoitti:
> 2014-04-05 11:09 GMT+02:00 Vesa Solonen <vesa.solonen@xxxxxxxx>:
>> 05/04/14 01:23, Heiko Rosemann kirjoitti:

>>> I came to kicad from Eagle some years ago and I still believe
>>> distinguishing between symbol-package-device to be the best
>>> solution for this problem.
>>
>> Second that. The implementation inside Kicad is not there yet. The
>> symbol is somewhat hard linked to the footprint (because symbol have
>> to contain matching pin numbers) and even the alias system can not
>> solve the issue.
> 
> I never really started to use eagle beacuse of its wierd library. I do
> like that the symbols are seperate from the footprint in kicad. (Or at
> leat tries to)

Neither me. I used to think the same as it looked such by the first
glance. Someone on this list explained the real situation. Eagle just
presents the library that way to the user, but the data behind it is
smarter. (IIRC)

Kicad way is just more flexible in the sense that one use it in both ways.


>> Device 2
>> DDD: Device: SS3H10
>>      symbol: Diode
>>      footprint: DO-214AB
>>      pin-pad-mapping: (K,1),(A,2) [no permutations]
>>      manufacturer: Vishay
>>      function: Surface Mount Schottky Rectifier 100V
>>      keywords: schottky, rectifier, diode
>>      data_sheet: http://www.vishay.com/docs/88752/ss3h9.pdf
>>
>>
>> Pin-pad-mapping is expected to contain all gate and pin swap
>> permutations for devices that allow it, simple devices like
>> bidirectional TVS zeners and resistors would just have x as a pin name
>> for interchangeable ones.
> 
> I have a hard time visualising this workflow. I like the idea of your
> DDD, but how or where is the pin-pad-mapping defined? Is this defined
> in a cvpcb-like step? I see that the pin-pad-mapping definition
> elliminates a bunch of the same symbols ans footprints with each of
> their all possible pin combinations.


The pin-pad-mapping is defined when the device library is built. Say,
some contributor wants to add the latest and greatest TO-247 silicon
carbide mosfet in. Said contributor just sends the DDD file. No need to
check if the symbol or footprint have been modified.

The pin-pad-mapping is instantiated (put to use) in Cvpcb-like step
which may be automated during schematic creation if an user so wishes.

Everyone can easily have the kind of symbol set they want to see, even
though the devices may change. The current state of mixed symbol styles
is not going to fly in professionally policed projects.

The extensive DDD is needed for automatic pin and gate swap for
(semi)automatic routing and placement. The current push and shove router
would be extremely useful with pin/gate level P&S. Not to mention added
degrees of freedom for autorouters like Freerouting.

The main thing for the whole separation is data management. We can not
do it in any other sensible way when the pile of data grows large
enough. Too many possibilities for errors and too much manual checking.
This applies to users and library managers. It seems Dick has gotten
more than his share of grief too, because of these exact issues. I've
also twisted some TO-220 leads to make the ordering correct and I really
don't want that to happen any more.

I've also promised to put effort in the library management, but I need
more than pen and paper to do it well enough ;)

Workflow possibilities:

1.
One can pick devices while drawing schematic, by searching with an exact
device "C2M0160120D" and the rest (choosing a symbol and a set of
possible footprints, showing pin and pad names as requested) is done
automatically. The footprint may have at least three versions for
TO-247: vertical, horizontal heat_sink_pad towards board or horizontal
heat_sink_pad away from board. This is something one must choose (in
Cvpcb or elsewhere), but we could have one as a default.


2.
One designs the whole schematic with just symbols and gets net data and
working logic (for brains or machine simulations). NMOS is just NMOS,
not necessarity from Cree or made form SiC. Pad numbers are not there as
there are no real devices (with pads) yet.

The implementation phase then picks whatever components they get to fit
in using Cvbpcb or the same functionality in the schematic editor.


-Vesa