kicad-developers team mailing list archive

[Chris Giorgi <chrisgiorgi@xxxxxxxxx>]

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~~~