Lesson 7: Dynamic components versus subcircuits

Section 1: Generating Dynamic (Primitive) Components

I'm not a big fan of subcircuits. I occasionally use them, they work in the code, you can nest them, whatever. Sub-circuits are actually not the preferred method of nesting designs, though. Mason allows for automatically generating new primitives based on a circuit composed of other primitives, which provides a similar functionality with less confusion. Tracking variables and calculations can be tricky over subcircuits (for the user, not Mason), where local copies of variables take precedence over the calling circuit's. For example, the sub-circuit may have a local copy of the microstrip line's permittivity, which will overwrite the calling circuit's value, which may or may not be desired.

In programming, we like to have a defined barrier- a function call. Dynamic components are like a properly coded function call. Subcircuits are like those procedural codes that use lots of global variables. It is difficult for a human to generate the S-Parameter relationships for some complex circuit. Consider the microstrip cross model in Illustration 51; in the upper left the variable block defines the arguments that go into the model. The calculation block includes the additional algebra to map to the component values. Mason outputs a valid Primitive file which is my actual mcross model.

Figure 7.1: Model for the microstrip cross

Details

Mason has the ability to output the complete algebraic expression for a circuit composed entirely of dynamic components, for example a Wilkinson that uses a lumped element model of a resistor. Mason actually outputs two files, one which is a legal Mason dynamic file, and one which is a legal MATLAB file. Because they share syntax, it's not too difficult to adapt the MATLAB code to C code.

When you consider that Mason's kernel is explicitly solving for these equations, it really wasn't too much of a stretch to actually output the algebra.

The definitive guide is here: Make New Primitive Files

The following rules apply:

• 1. The variables in the model will be the arguments for the primitive file

  2. No Touchstone files may be used- strictly primitives (dynamic models)

  3. Calculations can be used to manipulate the arguments (variables)

  4. Optimizations and statistics can't be used

  5. Must use 50-ohm ports

  6. Be careful using S_X_Y in your calculations (e.g. "S_2_1 = S_1_2"); this doesn't map well in the new primitive files since "S_2_1" in this case will get mapped to something like "T1_S_2_1 = S_1_2", where S_1_2 will not have been defined.

  7. Be careful using variables that are also arguments to primitive components; in general Mason is good about this but not in this application.

The actual flag to generate this output is: make_primitive=”new_primitive.xml”; more details can be found at: Dynamic (or Primitive) File Descriptions.

Section 2: Subcircuits

Sub-circuits are groupings of components that form a logical block- such as a combiner, a balun, or a detailed transistor model. Sub-circuits follow the general Mason file rules, although only the model, component, port, and variable elements are read. They may be complete Mason files but the other elements will be ignored.

The local nodes will be mapped to the ports in the order that the ports are listed in the sub-circuit.

Figure 6.2: 3-port subcircuit used in Mason

The impedances of the sub-circuit port definitions are ignored: these impedances are “outside” of the circuit. While models are not shared between sub-circuits and the main circuit, variable definitions do flow from the Mason file to the sub-circuits.

[For those who skipped the previous section], sub-circuits are actually not the preferred method of nesting designs. Mason allows for automatically generating new primitives based on a circuit composed of other primitives , which provides a similar functionality with less confusion. Tracking variables and calculations can be tricky over sub-circuits (for the user, not Mason), where local copies of variables take precedence over the calling circuit's. For example, the sub-circuit may have a local copy of the microstrip line's permittivity, which will overwrite the calling circuit's value, which may or may not be desired.

As of version 4.5, subcircuits can output PCB Layout files.

Notes for layout:

The top level TinyCAD (or Mason XML file) needs to have a primitive component attached to each port, for example a small (10-mils long) microstrip line. Currently the routine is not smart enough to drill into the subciruit to figure out which part the terminal should attach to.

Subcircuits can be used through TinyCAD using the mason_subcircuit library, but care must be taken. Currently, files are only loosely linked- the following steps describe how the link can be made and how it works. An example can be found in the TinyCAD examples folder, specifically "subcircuits.dsn" which is loosely linked to "single_wilkinson.dsn".

• 1. Start with a Circuit Mason design that runs in TinyCAD

     1. 1. For this example, "single_wilkinson.dsn"

        2. When "single_wilkinson.dsn" is run, it creates a file called "single_wilkinson.dsn.msn.xml"

        3. "single_wilkinson.dsn.msn.xml" is the file which "subcircuit.dsn" will link

        4. "single_wilkinson.dsn.msn.xml" is only updated when "single_wilkinson.dsn" is run; this file is not updated when "subcircuit.dsn" is run

Variables and calculations are hierarchical

• 1. Variables and calculations flow down into subcircuits

  2. Local variables and calculations take precedent over variables passed down into the design

  3. Care must be taken not to confuse variable scope when running the subcircuit file and the calling file independently

     1. 1. variables must be defined in the subcircuit to make it run

        2. variables defined in the calling circuit will be overwritten by the subcircuit variables

• • You can optimize using subcircuits, the subcircuit files will be updates individually (but not the TinyCAD DSN files)

More details can be found at: Subcircuit Tag

Copyright 2010, Gregory Kiesel