#14 Schematic 'build' configurations

[Stephen Friederichs]

With the work I've been doing on the libraries I've pretty much broken everything down into several types of libraries:

Generic - Generic parts are for laying out a circuit and figuring out how it's going to work. If you don't really care what KIND of transistor yet, you place a generic NPN or PNP transistor and worry about it later

Simulation - These parts have SPICE models so you can simulate them. At this point you've figured out that your transistor should probably be a 2N2222, so instead of a generic transistor your schematic shows a 2N2222.

Specific - These parts have part numbers, prices, suppliers, packages, etc. This is a part I can go out and find on Digikey or Mouser. Once you know that your circuit works you can pick out specific parts, get an idea of cost with the BOM, figure out which manufacturer you're going with, etc.

Therefore, I think it makes sense to break the process of creating a schematic into several steps, several different schematic 'configurations':

Initial - Place generic parts and get an idea of how the circuit is going to function

Simulation - Replace generic parts with their simulatable counterparts and do analysis. Each part must have a SPICE model

Prototype - select specific components that you will use to prototype the circuit on a protoboard, add connectors, enclosures, etc as necessary. Each part must have a part number, supplier, etc

Layout - Replace the prototype parts with parts that you would place on a PCB, whether they be surface mount or through-hole. each part must have supplier information and a package.

At each steps the parts are replaced by their appropriate counterparts. A generic 2N2222 in the initial stage gets replaced by a simulatable 2N2222 in simulation, then a specific 2N2222 in prototype and layout. It would be nice if this replacement was automatic, or at least if the schematic was copied to each configuration and it was easy to select replacements for each part. Perhaps a replacement table built into TinyCAD that details which parts are used in which configurations.

I think at the minimum the feature of having different configurations is essential. Too many schematic capture programs blur the difference between these steps in a design. I know in PSPICE you can attempt to simulate a circuit that doesn't have any components with SPICE models - it just generates a netlist without any parts and errors out without letting you know why. And then there's the horrible issue in PSPICE where you need a special 'Ground' symbol to simulate properly. It's horrid. All of the different part types are just thrown together. If you want to work with different configurations of the same circuit you basically have to make three or four different schematics and backpropogate and forwardpropogate changes on your own. Like I said, horrid.

[Don Lucas]

A number of commercial integrated packages have found a better way to represent this than you suggest - They break the concept of "parts" down into smaller pieces:
1. Schematic Symbol - the top level parent component. Some people prefer to keep it as graphics only with a list of pointers (names) to the remaining items in this list. The graphics can be a single instance for the entire part (homogeneous symbols) or multiple graphical depictions that go together to represent a physical part (heterogeneous symbols). My favorite feature is symbols that also have alternate graphical depictions which can then be either homogeneous or heterogeneous. The altername graphics are used for anything you want, such as traditional logic gate symbols versus Demorgan logic symbols or IEEE format logic symbols.
2. Footprint - the name of a 2D or even 3D pcb footprint (some call it a "decal"). It is created separately and referred to by name in the schematic symbol. It is typically maintained in a separate library of footprints or even stored individually as XML files and under configuration management control. You can even qualify a list of footprint names (i.e., for a resistor, you might have 0402, 0603, 0805, etc) that the user selects later, depending on the density of the board layout that is needed. The latest industry standards now support 3 different standard footprint sizes for surface mounted components, a high density version, a medium density version, and a low density version in order to achieve the desired level of manufacturability versus product form factor.
3. Part information - the part number, manufacturer's name, distributor's name, alternate qualified part numbers, etc.
4. Simulation information - the name of a Spice template stored in a special library of Spice templates, much like symbols are stored in symbol libraries. You can then support multiple types of simulation - functional simulators, device level simulators, alternate brands of simulators, etc.
5. Design file information, such as the name of a hierarchical schematic sheet or collection of sheets that represent the symbol and get expanded into a hierarchical net list later. This also includes design files such as C source code for software block diagram schematics, various kinds of hardware description languages (HDL's) such as VHDL or Verilog. See http://en.wikipedia.org/wiki/Hardware_description_language for a good introduction.
6. Pin swapping information that represents which pins are equivalent on a physical part and therefore can be swapped at pcb placement time. This is often integrated into the schematic symbol information or sometimes with the physical part information.

One way of thinking about the role of a schematic symbol in a generic design process is to view it as a vehicle for holding plug-ins with very little actually formalized about what a plug-in might do. For example all of the items above except the symbol itself could be implemented simply as a list of plug-ins, making the system extremely flexible and infinitely extendable. You could have a plug-in represented as some sort of DLL, allowing anyone to create new plug-ins to extend what the symbol and thus the design can represent. Plug-ins could be footprints, simulation models, software subroutine models, etc. A plug-in could store methods for manipulating its own data when encountered in a symbol. This could be extended to support assembly variations where you have different part numbers (such as different resistor values) for different builds of a particular design.

In this way, a symbol could be added to a design once either preconfigured with its intended plug-ins (i.e., footprints, simlation models, part numbers, etc) or user configured after it is placed. It wouldn't have to be altered or maintained in parallel design files as you suggested to accomplish all of the many tasks that modern products require and certainly all of the tasks that you mention.

Whether we have the time and user interest to develop the concept this far, I don't know, but it does interest me a great deal. Only time will tell how far along we get with this.

Best regards,

Don