Mejores prácticas para usar subcircuitos y bloques jerárquicos en LTspice

Estoy diseñando una serie de circuitos en LTspice y quería recibir comentarios sobre la forma aceptada de usar subcircuitos y bloques jerárquicos. El manual de LTspice es algo vago en estos temas. En la captura de pantalla a continuación, copié una sección de mi circuito para ayudar a ilustrar el punto.

ingrese la descripción de la imagen aquí

El circuito de más alto nivel contiene un bloque "Convertidor V/F" que hace referencia a un esquema con un chip LM331. El bloque "LM331" a su vez hace referencia al circuito funcional para este IC. (LTspice no incluye este componente, así que lo encontré en otro lugar en línea). También estoy usando parámetros que se transmiten desde el bloque de nivel superior al circuito LM331 de nivel inferior que establece la lógica y los niveles de voltaje de fuente (nota los parámetros "Vcc=12" y "Vlogic=5" en el bloque "Convertidor V/F"). Todo el circuito funciona bien y simula de la manera que espero.

Desde un punto de vista de diseño/organización, ¿los bloques jerárquicos son la forma correcta de configurar esto en LTspice? Dado que el LM331 es un componente real, creo que sería mejor convertirlo en un subcircuito usando un archivo de lista de conexiones en lugar de un esquema. Como subcircuito, tendría acceso al Editor de atributos de componentes y algunos campos más para configurar parámetros en lugar de la única línea PARAMS que usa el bloque jerárquico. Sin embargo, con el componente como un subcircuito, creo que el esquema subyacente desaparecería ya que estaría controlado por una lista de conexiones. Esto haría que el componente fuera un poco más difícil de depurar, ya que ya no se presentaría visualmente.

Al final del día, supongo que la funcionalidad es la misma independientemente de si estoy usando bloques jerárquicos o subcircuitos (al menos en este ejemplo), pero tengo curiosidad por saber cuáles son las mejores prácticas. ¿Hay alguna ventaja de una forma u otra?

Aquí hay algunas capturas de pantalla de los dos enfoques. Tenga en cuenta la diferencia en los cuadros de diálogo del editor y los botones Abrir símbolo/esquema.

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí

Respuestas (1)

Los subcircuitos o jerárquicos son los mismos, después de que LTspice aplana la lista de conexiones. Puede ver esto comprobando Generate Expanded Listingen el panel de control, la Operationpestaña.

La ventaja que tienen los esquemas jerárquicos es el acceso gráfico directo a través de la edición de símbolos, donde puede abrir su contenido como si fuera un esquema, y ​​sondear fácilmente voltajes, corrientes, potencias (necesita las dos opciones marcadas Save subcircuit ...) Control Panel > Save Defaults. También puede sondear dentro de subcircuitos simples, pero debe verificar la lista ampliada en el registro de errores; es más engorroso, pero no imposible.

En general, los diseños jerárquicos son más fáciles de usar, pero la desventaja es la falta de cifrado. Los subcircuitos se pueden cifrar para proteger los contenidos, los diseños jerárquicos no. La lista ampliada no funciona con bibliotecas encriptadas, lo cual es de esperar, por lo tanto, no puede guardar ni trazar cantidades internas. Además, un subcircuito es más compacto, generalmente un archivo, los esquemas jerárquicos pueden ser más de uno. Ah, y no verás bonitos símbolos amarillos...

Ambas formas, subcircuitos jerárquicos y simples, permiten que se transmitan parámetros externos, como su Vs={Vcc}ejemplo.

Ninguno es más rápido o más lento que el otro en términos de cálculos para los mismos diseños, ya que, como mencioné antes, LTspice aplana todo el esquema en una netlist, que no es más que un lenguaje de programación para SPICE.

¿Cuál usar? Elige tu opción. En general, si está trabajando en el diseño, elija jerárquico para facilitar el acceso gráfico, de modo que el resultado final pueda transformarse en un subcircuito que esté listo para cifrarse, si así lo desea.


Como subcircuito, tendría acceso al Editor de atributos de componentes y algunos campos más para configurar parámetros en lugar de la única línea PARAMS que usa el bloque jerárquico.

Esos campos no significan nada en términos de lista de conexiones, y los nombres que se muestran en el editor de atributos del componente también se aplanan: si revisa la lista de conexiones, todas las líneas se recortan en una sola línea que pertenece al subcircuito.

Solo tienen sentido como algunas combinaciones, en términos del orden en que aparecen en esa línea, y que tienen diferentes efectos junto con el símbolo: en algunos casos, es posible evitar que el símbolo sea editado. Vea, por ejemplo, un opamp de la biblioteca existente e intente R-Click, con o sin Ctrl, no le permitirá. Esto va de la mano con el cifrado de subcircuitos, pero no con diseños jerárquicos.

Muchas gracias por la respuesta detallada: ¡esas son exactamente el tipo de pautas que estaba buscando! Delinear entre diseño y "producción" en términos de bloques jerárquicos y subcircuitos es una forma útil de pensar las cosas, especialmente con los aspectos de sondeo. Tampoco sabía que los usuarios finales podían cifrar sus propios subcircuitos; Supuse que era algo que Linear estaba haciendo especialmente con sus modelos de biblioteca integrados. ¡Grandes consejos!
@higrafey De nada. El cifrado viene en dos formas: los modelos propios de LTspice, que puede ver que son completamente binarios y están cifrados internamente, y el programa, que se puede cifrar usando el interruptor de línea de comando, son los que -encryptusted ver como ASCII/Unicode mixto y binario.
Además, lo que quise decir con la segunda edición (debajo de la línea) fue que todos esos campos se concatenarán en la única línea que se necesita para que el subcircuito se represente en la lista de conexiones, por lo tanto, no es obligatorio usar solo y SpiceLine, SpiceLine2y los demás no, puedes usarlos todos, por igual. Véase, por ejemplo, [Opamps]/UniversalOpamp2tiene parámetros repartidos en 3 líneas.
@un ciudadano preocupado Ah, sí, me di cuenta de que algunos de los modelos estaban en formato binario cuando estaba hurgando. Eso tiene mucho sentido. Gotcha en la concatenación de línea. Mi preferencia por tener varios campos se debía a que los parámetros largos podían dividirse en varias líneas y no superponerse desordenadamente al modelo cuando se hacían visibles. Traté de agregar un comando de nueva línea ( \n) al PARAMScampo del bloque jerárquico para fomentar un salto de línea, pero no funcionó. Supongo que todos esos parámetros deben estar en una sola línea en la vista esquemática.