sch-rnd-aux knowledge pool

 

Symbol design checklist

sym_chk by Tibor 'Igor2' Palinkas on 2023-06-05	Tags: howto, symbol, footprint, spice, model, pinout, pin numbers
node source

 

Abstract: Checklist for symbol design to help users creating full featured, universal symbols that can be easily reused when distributed.

 

Symbol design checklist

• Generic: symbol quality
  • For slotted devices decide about slotted symbols and/or monolithic alternative
  • fill in attribute -sym-copyright
  • fill in attribute -sym-license-dist
  • fill in attribute -sym-license-use
  • fill in attribute -sym-source
  • avoid the following attributes:
    • portmap
    • ordering information (unless the symbol is private, not distributed)
• Generic: terminals
  • all terminal endpoints are on a 4k grid point
  • Symbolic name for all terminals
• DRC and metadata
  • (TODO)
• PCB workflow
  • think over the symbol's PCB pin number policy
  • think over the symbol's PCB footprint policy
• SPICE workflow
  • think over the symbol's SPICE pin number policy
  • in slotted symbols, use the spice/shared terminal attribute on shared (internally connected) pins, e.g. opamp's V+ and V- supplies
  • set spice/prefix on priority 31050
  • unless the symbol is very specifically for a single SPICE model file, avoid using these attributes:
    • spice/params
    • spice/portmap
    • spice/model
    • spice/model_card
    • spice/model_card_uname
    • spice/model_include
    • spice/bridge/* (on terminals)
  • unless the symbol is a spice control symbol, avoid using these attributes:
    • spice/file_header
    • spice/command
  • if your slotted device is drawn as a monolithic symbol (e.g. dual opamp with both slots in a single symbol with 2 output terminals), provide either a subsheet (TODO) or a SPICE model, because a stock SPICE model (e.g. opamp) won't work
• BOM and metadata
  • (TODO)

Best practices

Standard symbol attribute conventions

Always try to fill in the following symbol attributes:

• -sym-copyright: (C) year author's name
• -sym-license-dist: name of the license that applies when the symbol file is distributed as a symbol file, separately, or as part of a symbol lib
• -sym-license-use: name of the license that applies when the symbol is distributed as part of a sheet (either in sheet local lib or as embedded copies)
• -sym-source: preferably an URL and/or other info about the source(s) used for constructing the symbol; typically datasheets

Note: these attributes names start with a dash so the attributes are not propagating to the abstract model.

Name terminals

Terminals should have symbolic names and not named by pin numbers. For two terminal parts that have polarity, use P and N (for positive and negative). For more complex parts, use functional names; e.g. for an opamp in+ and in- for the input pins.

The only exception is very simple parts where all terminals are equal in all regards. For example a two terminal resistor or unpolarized capacitor or inductor may have terminal names 1 and 2.

Pin numbers for the PCB flow

Preferably do not assign pin numbers, use symbolic terminal names and let devmap handle it. Provide a devmap file.

An exception is when the device has a single package from a single vendor so that the pinout is static and there is a high chance alternative packaging won't appear. This is rarely the case with diodes, transistors, MCUs, CPUs, memories, most ICs. Some sensors or highly specialized ICs may fall in this category.

Even if you need to assign pin numbers, make sure to use pcb/pinnum ( not plain pinnum) and preferably use priority 31050, so that a devmap/portmap can still override it.

Footprint for the PCB flow

Similar to the above considerations: in the common case, do not specify a footprint attribute. The footprint attribute with priority 31050 (for devmap override) may be considered if the device has only one vendor and comes in only one package.

Pin numbers for the SPICE flow

For common devices like diodes or opamps when there is a long established convention on SPICE "pinout", it is reasonable to specify spice/pinnum attributes on terminals. Preferably use priority 31050, so that a devmap/portmap can still override it in case a macromodel is used that happens to have a different "pinout".

spice/prefix

Look up what spice model type goes with the symbol in the most typical use case. For example this is D for a diode or M for a mosfet. Set this in spice/prefix at priority 31050. The low priority is very important: this lets target_spice override the prefix with X in case it detects the model is a subcircuit.