[Xcircuit-dev] Tutorial notes

R. Timothy Edwards tim.edwards at multigig.com
Fri Apr 21 19:40:16 PDT 2006


Dear Dave,

> I am going through the tutorials and trying to understand how to use 
> XCircuit to draw schematics and create net-lists specifically for PCB 
> layout. I am taking notes that I intend to use to facilitate hands-on 
> training of engineering staff. Here is what I think I know about XCircuit. 
> Does this sound correct? If not, any help in correcting my 
> misunderstandings would be very much appreciated.
> 
> #Parts
>      Parts (devices) are represented by symbols drawn from "Library Objects"
>      - a symbol is an instance of a Library Object
	Yes, although a library object does not necessary have to be a symbol;
	it can also be a piece of a schematic.

>      - symbols are copied from libraries, placed in pages and
>        connected with wires to form schematics
	Yes.

>      - symbols are drawn on pages and then saved into libraries
	Sort of;  elements (lines, arcs, instances, text) are drawn on pages,
	and when collected together with the "make" command, they become a
	symbol in a library.
> 
>      Symbols have pins
>      - symbols may be interconnected by drawing wires or busses
>        between pins
>      - interconnected pins form 'networks'
	Yes.
> 
>      Symbols have 'info' labels
>      - PCB info labels (PCB:U1 etc.) are used to define unique PCB
>        part designators
>      - other info labels designate various object and symbol values
	The "info label" has the express purpose of precisely defining the
	output format.  "info labels" MUST start with a key (e.g., "pcb:").
	If you write a PCB netlist, only info labels beginning with "pcb:"
	are parsed, and any others are ignored.

	Various object and symbol values (often called "properties"; e.g.,
	resistor value, package type, etc.) are defined by (in xcircuit)
	"Parameters".  The whole parameter thing is very complicated and
	goes way beyond info labels.  Parameters show up in info labels
	often, though, because they tend to be part of the netlist.  For
	PCB output, though, they tend to be part of the BOM, which is why
	it might be a really good idea to define an additional netlist
	type "bom" defined by info labels beginning with "bom:" (this only
	just occurred to me.  You'll have to pardon state of PCB netlisting
	in XCircuit---I use XCircuit for VLSI netlists myself).
> 
> #Textual Elements
>      Text
>      - informational only
>      - does not result in data being added to netlists
>      - may be placed on pages or in symbols
	Yes.

>      Pins
>      - designate the unique points where symbols may
>        be inter-connected
	Partly.  A pin label on a symbol defines a connection point.
	A pin label on a schematic names a net.
> 
>      Labels
>      - designate the values for a given symbol
>      - are used to generate PCB and Spice netlists
>      - labels in library objects may contain variables
>      - PCB instance variables (such as PCB:U?) are replaced
>        with instance numbers (such as PCB:U1) as parts are
>        placed on pages
	This is a bit confused.  Info labels (as mentioned above)
	define the output format.  They may contain parameters or
	variables as needed in the netlist output file.  The
	parameters themselves are independent;  a list of parameters
	appears if you select an object instance and press "control-p".
	Parameters are defined by key:value pairs.  The object itself
	contains the default value of each parameter.  Each instance
	may inherit the object's default value, or it may define its
	own instance-specific parameter value.  In the info label
	"PCB:U?", there is an embedded parameter.  The parameter key
	is "idx", and the default value is "?".  When the netlist file
	is written, the default value is replaced by a number.  However,
	this number can also be set manually by changing the value of
	parameter "idx" for the instance, or manually in batch by
	selecting menu item "Netlist->Auto-number components".

	Because the PCB netlist format is simple, about the only thing
	that can be defined is the component name ("U1") for each
	component instance.
> 
> #Libraries
>      Library objects may be graphic images
>      Library objects may be graphic images that contain schematics
>      Library objects may be sub-schematics that have no graphic image
	I use the term "graphic image" to refer to elements that are
	formed by reading PPM bitmap files, very useful for embedding
	chip photographs, scope traces, etc. in the schematic drawing.
	I use it to create wire bonding diagrams for chips.  I assume
	that by "graphic image" you mean drawing elements that are not
	part of a netlist.

	Libraries are collections of symbols.  I differentiate library
	"files" from library "pages", since they do not necessarily
	correspond 1:1.  The symbols are usually just pictures made of
	non-network elements except for pin labels.  Library objects
	may be schematics;  that is, they contain wires and other
	object instances that become part of the netlist.  In this
	use, "pins" are determined from context.

	Symbols come in several distinct flavors:

	1) "fundamental" types have an info label and get translated
	   directly into netlist output.

	2) "trival" types don't appear in the netlist output, but do
	   something significant to the netlist, such as connecting
	   two nets together ("jumper") or defining a bus tap.

	3) "nonetwork" symbols are just drawing, with no significance
	   to the netlist at all.

	4) Anything that is not types 1, 2, or 3 is a normal "symbol",
	   that defines an instance of a subcircuit in a netlist.

	The types are not set in stone;  for instance, a "nand" gate
	would by necessity be a standard symbol for SPICE output,
	but would be a fundamental type in a PCB netlist.

+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim)   | email: tim.edwards at multigig.com     |
| MultiGiG, Inc.                 | web:   http://www.multigig.com      |
| 100 Enterprise Way, Suite A-3  | phone: (831) 621-3283               |
| Scotts Valley, CA 95066        | cell:  (240) 401-0616               |
+--------------------------------+-------------------------------------+



More information about the Xcircuit-dev mailing list