Thanks, Matt –

Please keep me informed of your progress.  I am very interested in adapting TinyCAD to Gandalf (my block diagram compiler), but I can’t even get started without the conditional evaluation primitives.  You will find that the Spice community will also be quite interested in the conditional primitives as they are a standard part of all popular Spice simulators.

By the way, I have considerable expertise in writing compilers using LALR(k) compiler compiler technology.  The parsers that are generated can very easily be embedded in other programs to allow very complex syntax commands to be implemented very easily.  The Spice netlister could easily be implemented with a full featured set of preprocessor capabilities such as the ones that I have already mentioned without too much effort.  Let me know if you ever have any interest in this approach.  The Spice netlister is pretty easy to implement without this technology, of course, so it is mostly just something fun to do.

Best regards,

Don

Don,

I don’t think what you are suggesting would take terribly long to implement.  I also don’t think it is that unreasonable.  I will have a look at it for you.

I am working on hierarchical drawings at the moment.  I have a plan for implementing them, and hopefully they will be in the next release (whenever that is…).

Thanks for the support,

Matt.

Hi Matt –

I recently found out about TinyCAD and am trying to convert some software that I have written to be compatible with it.  In order to do this, I need to be able to use conditional evaluation primitives for Spice.  My application is not really a Spice application, but I found that I could hijack the Spice netlister in most schematic capture packages to extract the information that I need.  My actual application is a graphical block diagram editor that in conjunction with a compiler that I wrote, generates TI DSP code for fixed point DSP’s.

The capabilities that I need that I haven’t found in TinyCAD’s implementation of the Spice netlister are:

1.      Category:  Basic if-then-else capability. 

Purpose:  the ability to determine if a schematic symbol primitive exists or not (presumably the user added an optional parameter to a library symbol in his schematic) and if it does exist, add some primitives to the Spice template.  I also need the “else” clause in order to add primitives if it is does not exist.  This capability needs to be able to nest in order to implement more complex logic decisions roughly corresponding to the capabilities the C language “switch” statement provides.

Possible implementation:  ?(Value, model text if parameter “Value” has been defined, model text if parameter “Value” has not been defined)

2.      Category:  Basic if-then-else capability: 

Purpose:  the ability to determine if a schematic symbol primitive has a defined value, or if it is empty.  This basically corresponds to 1) above except that it presumes that the parameter *does* exist and it is only checking to see if the user entered a value into the parameter or not.  Again, this needs full nesting capability as in 1) above.

Possible Implementation:  ?$(Value, model text if parameter “Value” has a value defined (even the default value), model text if parameter “Value” does not have a value defined)

3.      Category:  Basic if-then-else capability:

Purpose:  The ability to determine if a pin was connected to a net, or if it was left floating.  The result of this test is to either include some primitives or to skip them. 

Possible Implementation:  ?%(1, model text if pin #1 is attached to a net, model text if pin #1 was left floating)

4.      Category:  Extremely nice to have, but not absolutely required. 

Purpose:  Makes Spice models of large libraries easier to maintain and easier to understand.  The ability to use a pin’s name rather than its number in the Spice template.  For example, if pin 1 of a schematic symbol had the name “CLK”, then instead of using %(1) to get the net name attached to pin 1, you would also be able to use %(CLK).  This makes the Spice netlist for large pin count devices much easier to handle.

Possible Implementation:  %(CLK)  would have the same results as %(1).
Possible Implementation:  ?%(CLK,%(CLK), Default_CLK_Net) would have the same results as ?%(1,%(1), Default_CLK_Net).

5.      Category:  Grammar compatibility.

Purpose:  After implementing 1-4 above, you may need to implement some basic escape sequences such as “\,”, “\?”, and “\$” in order to support embedding these special characters into Spice models without being interpreted as one of the above  evaluation primitives.  An escaped character would never be interpreted as one of the sequences above.

6.      Category:  Very nice to have, but not absolutely required.

Purpose:  Hierarchical schematic capture capabilities.  Very useful for Spice simulations and for structuring your work.

Possible Implementation:  Add a special parameter to every schematic symbol that could contain a file path name (relative or absolute) to another TinyCAD schematic.  Match pin names on the upper level schematic symbol with identical net names on the referenced schematic to create a flattened net list during Spice netlist creation.  Retain the top level net name to name the flattened net after creating the flattened net list.

These capabilities exist and are used in other schematic capture packages for use with Spice such as the old Microsim PSpice that now belongs to Mentor/OrCAD.

If you have any interest in implementing these features, please let me know.  The software package that I wrote that I would like to use with TinyCAD has not been sold commercially, but was developed for in-house use.  I am presently considering what to do with it, as it has become a very useful and mature tool.  My options are somewhat limited because it depends on very expensive schematic capture packages presently.

Best regards,

Don Lucas

Orikon Solutions, LLC

Dallas, Texas