kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/13/2011 12:53 AM, Chris Giorgi wrote:
> On Mon, Apr 11, 2011 at 08:16, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>> This is turning out to be a real jewel, and will likely be one of the more
>> useful features of the new schematic part architecture.
>>
>> To facilitate it, it is necessary to require uniquely named schematic pins. This
>> is a departure from old school, but I think it is worth it. Most any prior need
>> to to have duplicately named schematic part pins is addressed by (pin_merge...)
>> itself.
>>
>> I realize this puts a wrinkle in smooth conversions from old school to new, but
>> automated tools should be able to do this duty. I solved a similar problem doing
>> the specctra export to Freerouter, where it wanted uniquely named pads.
>>
>> The sweet *.odt file is now up to date, as of this morning, and concisely
>> describes the (pin_merge) support. (The committed code does not yet match the
>> specification.)
>> I duplicate some of the specification here. But before getting into (pin_merge),
>> lets review the part's (pin) support:
>>
>>
>>
>> (pinTYPE SHAPE
>>
>> (at X Y [ANGLE])
>>
>> # Length of the pin in logical units. This is optional, depending on
>>
>> # SHAPE, which in some cases may imply a fixed length
>>
>> (length LENGTH)
>>
>> # Use signal to describe the purpose of the pin. Signals do not have to be
>>
>> # uniquely named within a part. Signal can be blank.
>>
>> (signal“NAME” (font[FONT] (size HEIGHT WIDTH) [italic][bold]) (visible YES))
>>
>>
>> # Use padname to uniquely identify the pin, according to the pin number
>>
>> # in the datasheet for the part. Padnames may not be blank and must be
>>
>> # be unique within the part.
>>
>> (padname“NUMBER” (font[FONT] (size HEIGHT WIDTH) [italic][bold])
>>
>> (visible YES))
>>
>> (visible YES)
>>
>> )
>>
>>
>> The main observations here are:
>>
>> 1) pin signals are not unique,
>> 2) pin padnames must now be unique.
>>
>>
>>
>>
>> So now we can understand the shiny new (pin_merge):
>>
>> # Pin merge is used to group a number of pins that are connected to the same
>>
>> # net and show only one pin symbolizing the group. The group is
>>
>> # called a merge set or merge group. It is typically used to hide all but
>>
>> # one power pin on parts that have a large number of power connections
>>
>> # such as FPGAs and micro-contollers. VISIBLE_PADNAME is the padname of
>>
>> # the one pin which remains visible within the merge set. Pins with padnames
>>
>> # listed within the (padnames...) element are all made invisible, and so
>>
>> # are are all pins which may have any of the signal names listed in the
>>
>> # (signals...) element. A pin may only exist within one merge group.
>>
>> # Any number of (pin_merge...) statements maybe made, including more than
>>
>> # one re-stating the same VISIBLE_PADNAME, which is the anchor pin for the
>>
>> # merge set.
>>
>> [(pin_merge VISIBLE_PADNAME
>>
>> [(padnames HIDDEN_PADNAME1 …)]
>> [(signals HIDDEN_SIGNAL1 …)]
>> )]
>>
>>
>> This means that in just one line of SWEET, you can group all your VCC pins
>> together with something as simple as this:
>>
>> (pin_merge 5 (signals VCC))
>>
>> This may gather up 10's of pins (all that have signal == VCC) and put them under
>> the umbrella of pin 5, saving you connection time.
>>
>>
>> Reasonably SWEET.
>
> Hi Dick,
>
>   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 as
> microcontrollers. 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):
>
> (part mfr/ST/STM32F100/rev01
>   (name "STM32F100")
>   ...
>   (block "PA"
>     (function "PA0" (type "GPIO"))
>     (function "PA1" (type "GPIO"))
>     (function "PA2" (type "GPIO"))
>     ...
>     (function "PA14" (type "GPIO"))
>     (function "PA15" (type "GPIO"))
>     (symbol (include "GPIO_16"))
>
>   )
>   (block "PB"
>     (function "PB0" (type "GPIO"))
>     ...
>     (function "PB15" (type "GPIO"))
>     (symbol (include "GPIO_16"))
>   )
>   (block "GPIO"
>     (include "PA")
>     (include "PB")
>     (include "PC")
>     (include "PD")
>     (include "PE")
>   )
>   (block "I2C1"
>     (function "I2C1_SCL" (type "I2C_SCL"))
>     (function "I2C1_SDA" (type "I2C_SDA"))
>     (function "I2C1_SMBA" (type "I2C_SMBA"))
>     (symbol (include "I2C_SMBus"))
>   )
>   (block "I2C2"
>     (function "I2C1_SCL" (type "I2C_SCL"))
>     (function "I2C1_SDA" (type "I2C_SDA"))
>     (function "I2C1_SMBA" (type "I2C_SMBA"))
>     (symbol (include "I2C_SMBus"))
>   )
>   (block "POWER"
>     (function "VSS" (type "POWER_VSS"))
>     (function "VDD" (type "POWER_VDD"))
>     (function "VBAT" (type "POWER_VBAT"))
>     (symbol
>       (draw (rectangle) (from -20 0) (to 20 30))
>       (draw (power_input "POWER_VSS") (at 0 0 90))
>       (draw (power_input "POWER_VDD" ) (at 20 5 0))
>       (draw (power_input "POWER_VBAT") (at 20 25 0))
>     )
>   )
>
>   ...
>   (configuration "low_density"
>    ( pin "VBAT" (function "VBAT"))
>    ( pin "PC13-TAMPER-RTC" (function "PC13" (alternate "TAMPER" "RTC")
>     ...
>    ( pin "PB10" (function "PB10" (remap "TIM2_CH3" "CEC")) (spec "FT"))
>    ( pin "PB11" (function "PB11" (remap "TIM2_CH4")) (spec "FT"))
>    ( pin "VSS_1" (function "VSS"))
>    ( pin "VDD_1" (function "VDD"))
>    ( pin "PB12" (function "PB12" (alt "TIM1_BKIN")) (spec "FT"))
>     ...
>     ( pin "PB5" (function "PB5" (alternate "I2C1_SMBA" "TIM16_BKIN")
> (remap "TIM3_CH2" "SPI1_MOSI")))
>     ( pin "PB6" (function "PB6" (alternate "I2C1_SCL" "TIM16_CH1N")
> (remap "USART1_TX")) (spec "FT"))
>     ( pin "PB7" (function "PB7" (alternate "I2C1_SDA" "TIM16_BKIN")
> (remap "USART1_RX")) (spec "FT"))
>     ...
>   )
>   (configuration "medium_density" (inherit "low_density")
>     ...
>     (pin "PB10" (function (alternate "I2C2_SCL" "USART3_TX")))
>     (pin "PB11" (function (alternate "I2C2_SDA" "USART3_RX")))
>     (pin "PB12" (function (alternate "SPI2_NSS" "I2C2_SMBA" "USART3_CK")))
>     ...
>     (pin "PB6" (function (alternate "TIM4_CH1")))
>     (pin "PB7" (function (alternate "TIM4_CH2")))
>     ...
>   )
>
>   (pinout "TQFP48"
>     (pad "1" "VBAT")
>     (pad "2" "PC13-TAMER-RTC")
>     (pad "3" "PC14-OSC32_IN")
>     (pad "4" "PC15-OSC32_OUT")
>     ...
>     (pad "8" "VSSA")
>     ...
>   )
>   (pinout "TQFP64"
>     (pad "1" "VBAT")
>     (pad "2" "PC13-TAMER-RTC")
>     (pad "3" "PC14-OSC32_IN")
>     (pad "4" "PC15-OSC32_OUT")
>     ...
>     (pad "12" "VSSA")
>     ...
>     (pad "18" "VSS_4")
>     (pad "19" "VDD_4")
>     ...
>   )
>   (pinout "TFBGA64"
>     (pad "B2" "VBAT")
>     (pad "A2" "PC13-TAMER-RTC")
>     (pad "A1" "PC14-OSC32_IN")
>     (pad "B1" "PC15-OSC32_OUT")
>     ...
>     (pad "F1" "VSSA")
>     (pad "G1" "VREF+")
>     ...
>     (pad "C2" "VSS_4")
>     (pad "D2" "VDD_4")
>     ...
>   )
>   (pinout "TQFP100"
>     (pad "6" "VBAT")
>     (pad "7" "PC13-TAMER-RTC")
>     (pad "8" "PC14-OSC32_IN")
>     (pad "9" "PC15-OSC32_OUT")
>     ...
>     (pad "19" "VSSA")
>     (pad "20" "VREF-")
>     (pad "21" "VREF+")
>     ...
>     (pad "27" "VSS_4")
>     (pad "28" "VDD_4")
>     ...
>   )
>
>   (device "STM32F100C4T" (configuration "low_density") (pinout
> "TQFP48") (package "TQFP48")
>     (attribute "SRAM" "4KB") (attribute "Flash" "16KB"))
>   (device "STM32F100R4T" (configuration "low_density") (pinout
> "TQFP64") (package "TQFP64")
>     (attribute "SRAM" "4KB") (attribute "Flash" "16KB"))
>   (device "STM32F100R4H" (configuration "low_density") (pinout
> "TFBGA64") (package"TFBGA64")
>     (attribute "SRAM" "4KB") (attribute "Flash" "16KB"))
>
>   (device "STM32F100C6T" (configuration "low_density") (pinout
> "TQFP48") (package"TQFP48")
>     (attribute "SRAM" "4KB") (attribute "Flash" "32KB"))
>   (device "STM32F100R6T" (configuration "low_density") (pinout
> "TQFP64") (package"TQFP64")
>     (attribute "SRAM" "4KB") (attribute "Flash" "32KB"))
>   (device "STM32F100R6H" (configuration "low_density") (pinout
> "TFBGA64") (package"TFBGA64")
>     (attribute "SRAM" "4KB") (attribute "Flash" "32KB"))
>
>   (device "STM32F100C8T" (configuration "medium_density") (pinout
> "TQFP48")  (package"TQFP48")
>     (attribute "SRAM" "8KB") (attribute "Flash" "64KB"))
>   (device "STM32F100R8T" (configuration "medium_density") (pinout
> "TQFP64") (package"TQFP64")
>     (attribute "SRAM" "8KB") (attribute "Flash" "64KB"))
>   (device "STM32F100R8H" (configuration "medium_density") (pinout
> "TFBGA64") (package"TFBGA64")
>     (attribute "SRAM" "8KB") (attribute "Flash" "64KB"))
>   (device "STM32F100V8T" (configuration "medium_density") (pinout
> "TQFP100") (package"TQFP100")
>     (attribute "SRAM" "8KB") (attribute "Flash" "64KB"))
>
>   (device "STM32F100CBT" (configuration "medium_density") (pinout
> "TQFP48") (package"TQFP48")
>     (attribute "SRAM" "8KB") (attribute "Flash" "128KB"))
>   (device "STM32F100RBT" (configuration "medium_density") (pinout
> "TQFP64") (package"TQFP64")
>     (attribute "SRAM" "8KB") (attribute "Flash" "128KB"))
>   (device "STM32F100RBH" (configuration "medium_density") (pinout
> "TFBGA64") (package"TFBGA64")
>     (attribute "SRAM" "8KB") (attribute "Flash" "128KB"))
>   (device "STM32F100VBT" (configuration "medium_density") (pinout
> "TQFP100") (package"TQFP100")
>     (attribute "SRAM" "8KB") (attribute "Flash" "128KB"))
> )
>
> We could easily allow for a direct generation of a schematic symbol
> with pins laid out according to their physical orientation, which is
> very useful when making pin-choices to simplify routing of traces.
> Pins of the same type can swap within a block by default (add a
> (noswap flag?)), and blocks can swap all pins with other blocks having
> the same types of pins. For the UI, I would envision a few options
> similar to the current 'unit' option for making selections. The user
> may either place a whole device, or select blocks to place. When shown
> as a device, the user should be able to click on a pin an select which
> function (or possibly functions) they wish to utilize on that pin.
> With a little additional thought, I suspect DRC could be made much
> stronger by allowing pins to have their limits specified and avoiding
> connecting 3v logic inputs to 5v signals. I realize that providing
> this much flexibility increases the complexity of the grammar, but
> would find that much preferable to having to make dozens of additional
> parts. If this approach sounds feasible, I'll put some time into
> writing a real spec. What I have thus far is off the top of my head,
> so there are probably some conceptual issues to address before trying
> to implement any of these features. Please let me know if anything
> doesn't make sense, and sorry for rambling on.
>
>
> Take care,
>     ~~~Chris Giorgi~~~


Chris,


I look at what the s-expression stuff you wrote, and I cannot find a part in it
easily.  Looks more like a database to me, than a description of parts.

Its too late and I am not interested in changing the current path to this extent.


*SWEET is not a part generation language.*
*SWEET is a part description language.*

SWEET is intended to convey the *description* of a part in a way that is:

1) human readable, and
2) human writable


Period. 

*SWEET is not a part generation language.*
*SWEET is a part description language.*

Suggestion, go back and read the last two sentences again. 


In effect, the distributed library management and SWEET design opens the door to
your ideas, but at a higher level than SWEET:


========================================================================================

To address the needs of part *generation*:

1) I put a SWIG layer on the DLL, so that you can generate SWEET parts from any
higher construct that you want, including the one you describe. For example, an
editor may be written in any programming language you like, such as Python or
Java or C++ that generates or edits SWEET parts.  Or a part generator can be
written that lives in the cloud, and eats data formatted in your grammar and is
written by you. 


2) I put a well defined part retrieval API that retrieves parts expressed in
SWEET in there.  What is on the back side of that can actually be your cloud
mechanism, running in the cloud or in a process near you.  There is a query
mechanism to ask for parts matching any criterion you like.  The part can be
generated on the fly and constructed from magic expressed in your grammar.


3) The "distributed library management system" and SWEET are not even Kicad
specific.  Eventually this code will probably be made into a separate project. 
I doing so, I hope to attract industry wide contributors of parts.   
(Technical: you can see that I have used wxWidgets only in the PART layer,
nothing below that.)


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.


In effect, the design opens the door to your ideas, but at a higher level than
SWEET.


The only part "generation" support we have in SWEET are simple things that remain:

1) human readable, and
2) human writable.

such as pin_swap, pin_merge, inherits, and a few minor others.   These are part
tweaks, not real part generation power constructs.

Again, think of SWEET as a description of the minted part, not a procedural
mechanism to mint a part.

However, the parts_list is a place to do eleventh hour tweaks.  And because of
inheritance, I'm hoping that the parts found in the parts_list can consist of
*few* lines of code, and remain:


1) human readable, and
2) human writable

I don't see human readable or human writable in what you submitted.

Dick