I'm designing a series of circuits in LTspice and wanted to get some feedback on the accepted way to use subcircuits and hierarchical blocks. The LTspice manual is somewhat vague on these topics. In the screenshot below, I've copied one section of my circuit to help illustrate the point.

enter image description here

The highest-level circuit contains a "V/F Converter" block which references a schematic with an LM331 chip. The "LM331" block in turn references the functional circuit for this IC. (LTspice doesn't include this component, so I found it elsewhere online.) I'm also using parameters that are passed down from the top-level block to the bottom-level LM331 circuit which set the logic and source voltage levels (note the "Vcc=12" and "Vlogic=5" parameters in the "V/F Converter" block). The entire circuit works fine and simulates the way I expect.

From a layout/organizational standpoint, are hierarchical blocks the right way to set this up in LTspice? Since the LM331 is an actual component, I'm thinking it might be better to convert it into a subcircuit using a netlist file instead of a schematic. As a subcircuit, I'd have access to the Components Attribute Editor and a few more fields for setting up parameters as opposed to the single PARAMS line that the hierarchical block uses. However, with the component as a subcircuit, I think the underlying schematic would go away since it'd be driven by a netlist. This would make the component a bit harder to debug since it would no longer be laid out visually.

At the end of the day, I suppose the functionality is the same regardless if I'm using hierarchical blocks or subcircuits (at least in this example), but I'm curious what the best practices are. Are there any advantages one way or the other?

Here are some screenshots of the two approaches. Note the difference in the editor dialog boxes and the Open Symbol/Schematic buttons.

enter image description here

enter image description here


Hierarchical or subcircuits are the same, after LTspice flattens the netlist. You can see this by checking Generate Expanded Listing in the control panel, the Operation tab.

The advantage hierarchical schematics have is the direct graphical access through the symbol editing, where you can open its contents as if it were a schematic, and easily probe voltages, currents, powers (needs the two Save subcircuit ... options checked in Control Panel > Save Defaults). You can also probe inside plain subcircuits, but you have to check the expanded listing in the error log; it's more cumbersome, but not impossible.

Overall, hierarchical designs are more user-friendly, but the disadvantage is the lack of encryption. Subcircuits can be encrypted to protect the contents, hierarchical designs cannot be. The expanded listing does not work with encrypted libraries, which is to be expected, therefore you are not able to save and plot internal quantities. Also, a subcircuit is more compact, typically one file, hierarchical schematics can be more than one. Oh, and you won't see nice yellow symbols...

Both ways, hierarchical and plain subcircuits, allow for external parameters to be passed on, such as your Vs={Vcc} example.

None is faster or slower than the other in terms of computations for same designs, since, as I mentioned before, LTspice flattens the whole schematic into a netlist, which is nothing more than a programming language for SPICE.

Which one to use? Take your pick. In general, if you're working on the design, choose hierarchical for easy, graphical access, so that the end result can be transformed into a subcircuit that's ready to be encrypted, if you so desire.

As a subcircuit, I'd have access to the Components Attribute Editor and a few more fields for setting up parameters as opposed to the single PARAMS line that the hierarchical block uses

Those fields mean nothing in terms of netlist, and the names shown in the component attribute editor are also flattened: if you check the netlist, all the lines get cropped up into a single line that belongs to the subcircuit.

They are only meaningful as some combinations, in terms of the order in which they appear in that line, and which has differnent effects together with the symbol: in some cases, it's possible to prevent the symbol from being edited. See, for example, an opamp from the existing library and try R-Click, with or without Ctrl -- it will not let you. This goes hand-in-hand with the encryption of subcircuits, but not hierarchical designs.

  • \$\begingroup\$ Thanks so much for the detailed response--those are exactly the sort of guidelines I was looking for! Delineating between design vs. "production" in terms of hierarchical blocks vs. subcircuits is a helpful way to think of things, especially with the probing aspects. I also wasn't aware that end users could encrypt their own subcircuits; I figured it was something that Linear was doing special with their built-in library models. Great tips! \$\endgroup\$ – higrafey Nov 29 '18 at 21:53
  • \$\begingroup\$ @higrafey You're welcome. The encryption comes in two flavours: LTspice's own models -- which you can see they are completely binary, and are encrypted in-house -- and program-wise, which can be encrypted using the -encrypt command line switch -- they are the ones you see as a mixed ASCII/Unicode and binary. \$\endgroup\$ – a concerned citizen Nov 30 '18 at 7:11
  • \$\begingroup\$ Also, what I meant with the 2nd edit (below the line), was that all those fields will be concatenated into the one line it takes for the subcircuit to be represented in the netlist, therefore it is not mandatory to only use SpiceLine and SpiceLine2, and not the others, you can use all of them, equally. See, for example, [Opamps]/UniversalOpamp2, it has parameters spread on 3 lines. \$\endgroup\$ – a concerned citizen Nov 30 '18 at 7:23
  • \$\begingroup\$ @a concerned citizen Ah yes, I did notice that some of the models were in binary format when I was poking around. That makes a lot of sense. Gotcha on the line concatenation. My preference for having multiple fields was because long parameters could be broken down into several lines and not messily overlap the model when made visible. I tried to add a newline command (\n) to the hierarchical block's PARAMS field to encourage a line break, but it didn't work. I guess all of those parameters have to be on a single line in the schematic view. \$\endgroup\$ – higrafey Dec 1 '18 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.