Best practices for using subcircuits and hierarchical blocks in LTspice

Question

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.

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.

Answer 1

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.