There is more than one sub-circuit definition with this name, which is ill-formed

Hi jsteck ,

LTspice used to arbitrarily choose a model or subcircuit definition from multiple defs of the same name. No warning; no way of knowing LTspice had done this. Earlier versions of LTspice gave the impression that it had done something deterministic, when it had at best, flipped a coin. The best solution is to get rid of the definitions you do not want to use, or subjugate them.

Or, if you prefer the lottery approach—a return to the previous behavior—you can add this to your schematic (but you will still get a warning):

.options allow_ambiguous_models

mike

syntax error
.options allow_ambiguous_models=true

Without the "=true" there is no syntax error but does not solve the problem, it still fails with

There is more than one sub-circuit definition with this name, which is ill-formed.
.SUBCKT Prop_Delay VIN VOUT 

Looks like every Texas Instruments model I download has this same problem, I cannot use two TI components in the same simulation. Near as I can tell the duplicates are always identical. I saw a suggestion elsewhere that LTspice should check if they are the same, and if so use it without failing.

But for now, how can I make the simulation run with two TI components?

syntax error
.options allow_ambiguous_models=true

Without the "=true" there is no syntax error but does not solve the problem, it still fails with

There is more than one sub-circuit definition with this name, which is ill-formed.
.SUBCKT Prop_Delay VIN VOUT 

Looks like every Texas Instruments model I download has this same problem, I cannot use two TI components in the same simulation. Near as I can tell the duplicates are always identical. I saw a suggestion elsewhere that LTspice should check if they are the same, and if so use it without failing.

But for now, how can I make the simulation run with two TI components?

Hi Mark536 ,

Mark536 said:

Without the "=true" there is no syntax error but does not solve the problem, it still fails with

Can you upload your schematics, symbols, and libraries. Zip it all up and drag to this window.

Mark536 said:

Near as I can tell the duplicates are always identical. I saw a suggestion elsewhere that LTspice should check if they are the same, and if so use it without failing.

I believe this is only the case for entire files being identical, not if sections within libraries are duplicated. I will confirm.

MStokowski said:

Or, if you prefer the lottery approach—a return to the previous behavior—you can add this to your schematic (but you will still get a warning):

.options allow_ambiguous_models=true

I made a mistake. It should be:

.options allow_ambiguous_models

mike

ShowLTspiceProblem.zip

Here is a dummied up schematic that uses two TI parts and the .LIB files exactly as supplied by TI.

This fails to run no matter if the ".options allow_ambiguous_models" is there or not.

Hi Mark536 ,

Will take a look. Thanks.

mike

Hi Mark536 ,

Have your tried clearing these errors:

Y:\Downloads\ShowLTspiceProblem\tlv1861.lib(81): No such node.

G_G1         IN+ V- TABLE { V(CONTROL_IBN+, 0) }

                              ^^^^^^^^^^^^

Y:\Downloads\ShowLTspiceProblem\tlv1861.lib(88): No such node.

G_G2         IN- V- TABLE { V(CONTROL_IBN-, 0) }

                              ^^^^^^^^^^^^

mike

Hi Mark536 ,

This is not legal LTspice syntax for a G source using a table. Should be easy to modify.

mike

Hi jsteck ,

OK, I fixed the syntax and still had problems with ambiguous models, but the duplicate models persist. So, I opened up the libraries and found the problem.

The problem appears to be that the ambiguous (not duplicate by inspection) models are called from within the libraries. Using these two libraries in one circuit would require LTspice to apply a scope to each use of each model wrt which library called it, which I don't think it can do, or would probably require a complete refactoring of how LTspice operates.

The workaround here is to edit the libraries, or one of the libraries to give the duplicate names unique names. Simple search and replace should to the trick. I'm gonna try it, but you could do the same.

Here's the fix for the G sources:

*****************************************************************************
* source TLV1861
.SUBCKT TLV1861 IN+ IN- V+ V- OUT
X_U4 N21103 N862087 Prop_Delay
X_U5 RVB_EN 0 N786723 V+ V+_BUFFER V- V-_BUFFER N862127 OUT Output_Stage
X_U6 V+ V+_BUFFER V- V-_BUFFER Supply_Buffer
X_U3 N785573 IN-BUFF N21103 V+_BUFFER V-_BUFFER N852568 HPA_COMPHYS
I_IS N843683 V- DC 560n
X_U7 EN N786723 V+_BUFFER V-_BUFFER Supply_Enable
X_U1 IN+ IN+BUFF IN- IN-BUFF Input_Buffer
V_VOS N785573 IN+BUFF 0.25m
R_RIS N843683 V+ 1u TC=0,0
C_CINPL V- IN+ 0.5p TC=0,0
C_CINNL V- IN- 0.5p TC=0,0
C_CINPH IN+ V+ 0.5p TC=0,0
C_CINNH IN- V+ 0.5p TC=0,0
V_VHYST N852568 0 2.7m
E_E1 N862127 V-_BUFFER N862087 V-_BUFFER 2
X_DESD3 V- IN+ DESD PARAMS: AREA=1.0
X_DESD4 V- IN- DESD PARAMS: AREA=1.0
X_DESD5 V- V+ DESD PARAMS: AREA=1.0
V_VLOGIC 1V 0 1
X_U8 V-_BUFFER V+_BUFFER RVB_EN 1V 0 VCC_Range
X_U9 IN+ V+ N879589 1V 0 VCC_Range
G_G1 IN+ V- CONTROL_IBN+ 0
+ TABLE = ( 0,80p , 1,50n )
X_U10 N879589 N883030 CONTROL_IBN+ 1V 0 ANDGATE
X_U11 EN N883030 1V 0 INVERTER
X_U12 IN- V+ N884396 1V 0 VCC_Range
X_U13 N884396 N884552 CONTROL_IBN- 1V 0 ANDGATE
X_U14 EN N884552 1V 0 INVERTER
G_G2 IN- V- CONTROL_IBN- 0
+TABLE = ( 0,80p , 1,50n )
.ENDS

mike 

Hi Mark536 ,

This might be a case where allow ambiguous models could allow you to run the sim (I'm looking into that), but you would not want to, as the models are truly ambiguous (different).

mike

OK, so I came across a solution somewhere else (can't even remember now). Someone said the models are written incorrectly (or at least not best practice). The problem is that every subckt in the LIB file is at the top level of scope. If you take the first .ENDS statement in the file and move it to the end of the file, then all the subckts are inside the first (main) model -- e.g. the are scoped to only that single device model.

I tried this and moved the first .ENDS statement in every TI LIB file I am using, and my circuit simulates without errors (not this sample I posted, but the real project I am working on).

I have little knowledge of the spice language, but if it has scoping and nesting rules like other languages then this makes perfect sense. It seems crazy that one of the largest semiconductor companies in the world would be shipping models that cannot work together because of such a simple oversight.

I have to believe the models work correctly as-is in the PSPICE-FOR-TI simulation tool (a derivative of Cadence PSpice). Maybe PSpice automatically scopes everything in a LIB files to avoid this sort of problem.

Hi Mark536 ,

SPICE (generic) netlists have no scoping; they are flat.

Mark536 said:

OK, so I came across a solution somewhere else (can't even remember now). Someone said the models are written incorrectly (or at least not best practice). The problem is that every subckt in the LIB file is at the top level of scope. If you take the first .ENDS statement in the file and move it to the end of the file, then all the subckts are inside the first (main) model -- e.g. the are scoped to only that single device model.

Correct.

Change the names of the problem subckt statements in one of the libraries and you should be good to go. I can't vouch for the veracity of the models themselves, of course.

Longer historical explanation below:

Old LTspice (like XVII) did not check for duplicate models in a syntax checker, it simply ran the simulation from the flattened nettlist and picked a model, which is non-ideal. In fact, before the duplicate model check was implemented, this essentially made LTspice nondeterministic, with it coin-flipping the choice of duplicate model. 

The "Allow ambiguous models" option was only added to appease users of Old LTspice who complained about the syntax check stopping their (probably) non-deterministic simulations. The statement, "it worked" was fraught, in that it wasn't working; Old LTspice (XVII) was giving the appearance of working. Allow ambiguous models enabled the return of the coin flip, buyer beware. It is highly discouraged. In your particular case, you would not want to allow such ambiguity, it would cause problems because the models are not identical in the different libraries.

Mark536 said:

I have to believe the models work correctly as-is in the PSPICE-FOR-TI simulation tool (a derivative of Cadence PSpice). Maybe PSpice automatically scopes everything in a LIB files to avoid this sort of problem.

This might make the case for a work-stopping syntax check even stronger. I checked to see if Pspice also flattens the netlist and then simulates. It does, suggesting that these libraries are malformed if ever used in conjunction in Pspice, as you have done in LTspice, with Pspice actually simply picking the first sub it finds. Google search suggests this is actually the case. Odds are quite low that these two libraries were ever tested together.

In short, the appearance of "working" is really mistranslating "running" to "working", when there is no logical reason to do so. 

So it is tempting to equate "it simulated" to "I have to believe the models work correctly". You are not the first to make this illogical leap, nor will you be the last. :-) The syntax checker, although annoying when pointing out the problems of old models, might, in this case, indicate that neither Old LTspice (XVII) nor even current Pspice are actually using the models as intended. My belief is that both Old LTspice and Pspice would yield a wrong result in some cases without fixing the duplicate names problem.

mike

Still a bit confused here. I did not rename any subckt, I simply enclosed all the subckt statements in the file within the first subckt (by moving it's .ENDS statement to the end of the file). The original LIB files were structured like:

.SUBCKT TLV6700 INA+ INB- VDD GND OUTA OUTB
    *...
.ENDS

.SUBCKT A ...
    *...
.ENDS

.SUBCKT B ...
    *...
.ENDS

LTspice gave the "more than on sub-circuit" error. Then I move that first .ENDS like this:

.SUBCKT TLV6700 INA+ INB- VDD GND OUTA OUTB
    *...

.SUBCKT A ...
    *...
.ENDS

.SUBCKT B ...
    *...
.ENDS
.ENDS * moved

If there is no scoping and the model is flattened why did the "more than one sub-circuit" error go away when the .ENDS statement was moved?