I created a symbol to represent a schematic (symbol saved as "block"
(.asy)). When I placed it in a higher level schematic and tried to
run a sim, I got an error message telling me that subcircuits cannot
be nested. The lower level schematic does have a subcircuit in it,
and a .lib directive to call that subcircuit, but this must not be a
limitation of heirarchical schematics, as it would severely limit
its usefulness. I'm certain I'm doing something wrong. Anyone know
what that might be?

Ron Harrison

The error message occurs when the schematic
resloves to netlist something like this:

.subckt N1 N2 N3 name1
.subckt N4 N5 N6 name2
[...]
.ends name2
.ends name1

The definition of name2 is inside name1.
Perhaps you have a subcircuit *defined*
in the circuit you want to include a subcircuit.
You can't nest definitions, but there's no
limit on the the depth of the hierarchy.

--Mike

--- "rmaxh <rmaxh@...>" <rmaxh@...> wrote:

I created a symbol to represent a schematic (symbol
saved as "block"
(.asy)). When I placed it in a higher level
schematic and tried to
run a sim, I got an error message telling me that
subcircuits cannot
be nested. The lower level schematic does have a
subcircuit in it,
and a .lib directive to call that subcircuit, but
this must not be a
limitation of heirarchical schematics, as it would
severely limit
its usefulness. I'm certain I'm doing something
wrong. Anyone know
what that might be?

Ron Harrison

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--- In LTspice@..., Panama Mike <panamatex@y...> wrote:

The error message occurs when the schematic
resloves to netlist something like this:

.subckt N1 N2 N3 name1
.subckt N4 N5 N6 name2
[...]
.ends name2
.ends name1

The definition of name2 is inside name1.
Perhaps you have a subcircuit *defined*
in the circuit you want to include a subcircuit.
You can't nest definitions, but there's no
limit on the the depth of the hierarchy.

Hello Mike,

thanks for the tip with the nested subcircuit.
I had the chance to get the circuit files from Ron and remembering
your advice, I immediatly looked into the LTSpice netlist.
It was exactly the problem as you have expected.


Let me sketch the three level hierarchy:

Top: Level-1 schematic: ressitors, instance of level-2

Next Level-2: instance of level-3, resistors, opamp.asy
.include opamp.sub

Next Level-3: transistors, diodes, G-sources


The problem was the ".include opamp.sub" statement in Level-2.
After I moved this statement to the top level-1, the simulation was
possible.


Top: Level-1 schematic: ressitors, instance of level-2
.include opamp.sub

Next Level-2: instance of level-3, resistors, opamp.asy

Next Level-3: transistors, diodes, G-sources



Partial netlist before change:
...
.subckt rc4200_sq cos sin Vref Vee out
...
.PARAM Ro={4*ampl*ampl*K/160e-6}
.PARAM K=1
.lib opamp.sub
.ends rc4200_sq

...
.backanno
.end


Partial netlist after change:
...
.subckt rc4200_sq cos sin Vref Vee out
...
.PARAM Ro={4*ampl*ampl*K/160e-6}
.PARAM K=1
.ends rc4200_sq

....
.inc opamp.sub
.backanno
.end


Hello Ron,
your opamp device is already under "lib&#92;asy&#92;opamps" in the LTSpice
path and the opamp.sub is directly under "lib&#92;sub". So you don't
need it additionally in your working directory.

Best Regards
Helmut

--- "rmaxh <rmaxh@y...>" <rmaxh@y...> wrote:

I created a symbol to represent a schematic (symbol
saved as "block"
(.asy)). When I placed it in a higher level
schematic and tried to
run a sim, I got an error message telling me that
subcircuits cannot
be nested. The lower level schematic does have a
subcircuit in it,
and a .lib directive to call that subcircuit, but
this must not be a
limitation of heirarchical schematics, as it would
severely limit
its usefulness. I'm certain I'm doing something
wrong. Anyone know
what that might be?

Ron Harrison

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--- In LTspice@..., "Helmut Sennewald
<helmutsennewald@y...>" <helmutsennewald@y...> wrote:

--- In LTspice@..., Panama Mike <panamatex@y...> wrote:

The error message occurs when the schematic
resloves to netlist something like this:

.subckt N1 N2 N3 name1
.subckt N4 N5 N6 name2
[...]
.ends name2
.ends name1

The definition of name2 is inside name1.
Perhaps you have a subcircuit *defined*
in the circuit you want to include a subcircuit.
You can't nest definitions, but there's no
limit on the the depth of the hierarchy.

Hello Mike,

thanks for the tip with the nested subcircuit.
I had the chance to get the circuit files from Ron and remembering
your advice, I immediatly looked into the LTSpice netlist.
It was exactly the problem as you have expected.


Let me sketch the three level hierarchy:

Top: Level-1 schematic: ressitors, instance of level-2

Next Level-2: instance of level-3, resistors, opamp.asy
.include opamp.sub

Next Level-3: transistors, diodes, G-sources


The problem was the ".include opamp.sub" statement in Level-2.
After I moved this statement to the top level-1, the simulation

was

possible.


Top: Level-1 schematic: ressitors, instance of level-2
.include opamp.sub

Next Level-2: instance of level-3, resistors, opamp.asy

Next Level-3: transistors, diodes, G-sources



Partial netlist before change:
...
.subckt rc4200_sq cos sin Vref Vee out
...
.PARAM Ro={4*ampl*ampl*K/160e-6}
.PARAM K=1
.lib opamp.sub
.ends rc4200_sq

...
.backanno
.end


Partial netlist after change:
...
.subckt rc4200_sq cos sin Vref Vee out
...
.PARAM Ro={4*ampl*ampl*K/160e-6}
.PARAM K=1
.ends rc4200_sq

....
.inc opamp.sub
.backanno
.end


Hello Ron,
your opamp device is already under "lib&#92;asy&#92;opamps" in the LTSpice
path and the opamp.sub is directly under "lib&#92;sub". So you don't
need it additionally in your working directory.

Best Regards
Helmut

Helmut and Mike,

Many thanks for your help. I moved the Spice directive ".lib
opamp.sub" to the top level as suggested, and the sim ran. It seems
rather awkward to have to remember to put all hierarchical
subcircuit calls at the top level when constructing a hierarchical
schematic, but I guess there's no way around it. (Is there?)

Thanks again,

Ron

--- "rmaxh <rmaxh@y...>" <rmaxh@y...> wrote:

I created a symbol to represent a schematic (symbol
saved as "block"
(.asy)). When I placed it in a higher level
schematic and tried to
run a sim, I got an error message telling me that
subcircuits cannot
be nested. The lower level schematic does have a
subcircuit in it,
and a .lib directive to call that subcircuit, but
this must not be a
limitation of heirarchical schematics, as it would
severely limit
its usefulness. I'm certain I'm doing something
wrong. Anyone know
what that might be?

Ron Harrison

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Helmut and Mike,

Many thanks for your help. I moved the Spice directive ".lib
opamp.sub" to the top level as suggested, and the sim ran. It

seems

rather awkward to have to remember to put all hierarchical
subcircuit calls at the top level when constructing a hierarchical
schematic, but I guess there's no way around it. (Is there?)

Hello Ron,
a few minutes ago I sent Mike Engelhardt this question and asked him
to answer into this thread at the YAHOO-LTSpice group.

Best Regards
Helmut

Many thanks for your help. I moved the Spice
directive ".lib opamp.sub" to the top level as
suggested, and the sim ran. It seems rather
awkward to have to remember to put all
hierarchical subcircuit calls at the top
level when constructing a hierarchical
schematic, but I guess there's no way around
it. (Is there?)

a few minutes ago I sent Mike Engelhardt this
question and asked him to answer into this
thread at the YAHOO-LTSpice group.

Oh, yes. That is awkward. I'll see if I can't
improve on this. The situation comes about
historically because while the academic codes
often do allow nested subcircuit definitions,
the commercial codes do not. However, the
commercial codes allow subcircuit parameters to
be passed, which is usually more useful.
Anyway, LTspice follows the commercial
standards. Maybe I can make it follow a
superset language.

--Mike

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Many thanks for your help. I moved the Spice
directive ".lib opamp.sub" to the top level as
suggested, and the sim ran. It seems rather
awkward to have to remember to put all
hierarchical subcircuit calls at the top
level when constructing a hierarchical
schematic, but I guess there's no way around
it. (Is there?)

a few minutes ago I sent Mike Engelhardt this
question and asked him to answer into this
thread at the YAHOO-LTSpice group.

Oh, yes. That is awkward. I'll see if I can't
improve on this.

I put up a version today(2.00t) that enables nested
subcircuit definitions. Initial tests suggest the
parameter passing is properly scoped. Please report
any problems or crashes as soon as you detect them.

--Mike

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

--- In LTspice@..., Panama Mike <panamatex@y...> wrote:

Many thanks for your help. I moved the Spice
directive ".lib opamp.sub" to the top level as
suggested, and the sim ran. It seems rather
awkward to have to remember to put all
hierarchical subcircuit calls at the top
level when constructing a hierarchical
schematic, but I guess there's no way around
it. (Is there?)

a few minutes ago I sent Mike Engelhardt this
question and asked him to answer into this
thread at the YAHOO-LTSpice group.

Oh, yes. That is awkward. I'll see if I can't
improve on this.

I put up a version today(2.00t) that enables nested
subcircuit definitions. Initial tests suggest the
parameter passing is properly scoped. Please report
any problems or crashes as soon as you detect them.

Hello Mike,
thank you very much for the work on solving the .lib problem
in lower level hierarchy. Version 2.00x now works with the
configuration from Ron, too. It is now no longer necessary to put the
.include or .lib statement to the top level.

Best Regards
Helmut


Let me sketch the three level hierarchy for the people interested:
------------------------------------------------------------------

Top: Level-1 schematic: ressitors, instance of level-2

Next Level-2: instance of level-3, resistors, opamp.asy
.include opamp.sub

Next Level-3: transistors, diodes, G-sources