Hi Matt –

 

This is exciting news! 

 

Can you send me a private email address that doesn’t get published openly?  I would like to discuss a potential business opportunity with you with information that I don’t want to release publicly at this time.

 

Thanks,

 

Don

 

 

 

Don,

 

I have actually done quite a bit of work on the conditional SPICE file generation, however, it will take me about another week to finish off.  I have been very busy recently, so although I managed to start the work I got interrupted.  However, next week I will have a lot more time on my hands in the evenings.

 

TinyCAD is licensed under the LGPL, which means that if you link against it you don’t have to release the source code.  So if you can put all of your code into a separate DLL and then link that against the main executable you don’t need to release your bits – but you do have to make any changes to the main executable (including those to load the DLL) available on request.

 

If you wish to licence TinyCAD then I have already licensed it to another 3^rd party before.  So I am willing to consider an offer – however from what you are saying I suggest you try and put your bits into a separate DLL as it would make more sense for you.

 

Also, I don’t know how popular you web-site is but I make around $8 a day from Google adverts on my site – OK it’s not going to pay the rent, but it does cover things like internet access and new computer equipment.

 

Hope this helps, and I will try and contact you later next week with a new version of TinyCAD for you to try…

 

Matt.

 

 

 

Hi Matt –

 

Have you had any further thoughts on implementing the conditional evaluation features in the Spice netlister module?  If you are interested in doing this, when might it be possible to test it?

 

How does the OpenSource license work?  Can I include it without restriction in a product that will be sold to others, or is that something that you and would have to work out a private license for?  I am interested either way.

 

My block diagram translator will be ready soon to put on the market.  It will be of interest primarily to DSP programmers and designers.  This is not a big money effort, but a small effort not unlike TinyCAD.  Only problem is that I have to charge for the program in order to justify the time that I am spending on it.  This is why I am interested in licensing a sellable version direct from you.  No exclusivity or anything like that, just a license to include your unmodified executable and libraries (although our own libraries will most likely be the only ones usable by our customers).

 

I have mentioned this to some of my potential users who have been alpha and beta site testing my code and they are very interested in a TinyCAD implementation.

 

Best regards,

 

Don Lucas

Orikon Solutions, LLC

 

 

 

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

 

 

 

 

Don,

 

I have actually done quite a bit of work on the conditional SPICE file generation, however, it will take me about another week to finish off.  I have been very busy recently, so although I managed to start the work I got interrupted.  However, next week I will have a lot more time on my hands in the evenings.

 

TinyCAD is licensed under the LGPL, which means that if you link against it you don’t have to release the source code.  So if you can put all of your code into a separate DLL and then link that against the main executable you don’t need to release your bits – but you do have to make any changes to the main executable (including those to load the DLL) available on request.

 

If you wish to licence TinyCAD then I have already licensed it to another 3^rd party before.  So I am willing to consider an offer – however from what you are saying I suggest you try and put your bits into a separate DLL as it would make more sense for you.

 

Also, I don’t know how popular you web-site is but I make around $8 a day from Google adverts on my site – OK it’s not going to pay the rent, but it does cover things like internet access and new computer equipment.

 

Hope this helps, and I will try and contact you later next week with a new version of TinyCAD for you to try…

 

Matt.

 

 

 

Hi Matt –

 

Have you had any further thoughts on implementing the conditional evaluation features in the Spice netlister module?  If you are interested in doing this, when might it be possible to test it?

 

How does the OpenSource license work?  Can I include it without restriction in a product that will be sold to others, or is that something that you and would have to work out a private license for?  I am interested either way.

 

My block diagram translator will be ready soon to put on the market.  It will be of interest primarily to DSP programmers and designers.  This is not a big money effort, but a small effort not unlike TinyCAD.  Only problem is that I have to charge for the program in order to justify the time that I am spending on it.  This is why I am interested in licensing a sellable version direct from you.  No exclusivity or anything like that, just a license to include your unmodified executable and libraries (although our own libraries will most likely be the only ones usable by our customers).

 

I have mentioned this to some of my potential users who have been alpha and beta site testing my code and they are very interested in a TinyCAD implementation.

 

Best regards,

 

Don Lucas

Orikon Solutions, LLC

 

 

 

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

 

 

 

Hi Matt –

 

Have you had any further thoughts on implementing the conditional evaluation features in the Spice netlister module?  If you are interested in doing this, when might it be possible to test it?

 

How does the OpenSource license work?  Can I include it without restriction in a product that will be sold to others, or is that something that you and would have to work out a private license for?  I am interested either way.

 

My block diagram translator will be ready soon to put on the market.  It will be of interest primarily to DSP programmers and designers.  This is not a big money effort, but a small effort not unlike TinyCAD.  Only problem is that I have to charge for the program in order to justify the time that I am spending on it.  This is why I am interested in licensing a sellable version direct from you.  No exclusivity or anything like that, just a license to include your unmodified executable and libraries (although our own libraries will most likely be the only ones usable by our customers).

 

I have mentioned this to some of my potential users who have been alpha and beta site testing my code and they are very interested in a TinyCAD implementation.

 

Best regards,

 

Don Lucas

Orikon Solutions, LLC

 

 

 

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

 

 

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

 

 

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

 

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

 

Hi Valya –

 

I just joined the group recently, so you may know more than I do, but I will help if I can.

 

Don Lucas

Orikon Solutions, LLC

11118 Grader St

Dallas, TX  75238

 

 

 

Hello!
Is any body here ?
Can I ask some questions ;-)

Bye.
Valya.