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?

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.