Páginas de programas

Simulación de circuitos con gEDA y SPICE, parte 6

6.3. Tclspice

Mientras se durmió el desarrollo principal de Ngspice en 2002, alguna gente amigable de MultiGig Ltd se dedicaban a desarrollar un derivado de Ngspice que bautizaron tclspice. Tclspice es un 'superset' (conjunto aumentado) de comandos de Ngspice, y además se exportó la gran mayoría de los comandos al API de Tcl.

El fin de este trabajo era de facilitar la automatización de analysis de SPICE. Tclspice es una herramienta muy poderosa: con Tclspice puede escribir programas que ejecutan lazos, mejoran valores de comonentes, corren analisis, y luego analizan el comportamiento del circuito antes de reiniciar el lazo. Obviamente, esta capacidad puede utilizarse para lograr optimización multi-dimensional del circuito. Terminado, Tclspice promete ser una 'aplicación asesina' del EDA de fuente abierto.

Si aún no lo tiene instalado, vea aquí como bajar el software y compilarlo.

Use of tclspice

TclSpice fue diseñado para exportar los comandos de SPICE para uso con programas en Tcl. Para utilizar TclSpice, es suficiente de entrar la línea package require spice al principio de su programa. Luego, para invocar un comando SPICE, simplemente llamarlo en el espacio de nombres 'spice'. Por ejemplo, el siguiente programa de Tcl leerá la lista de red, comanda un análisis de transientes, corre la simulación, y luego grafica el voltaje observado en la línea Vout:

#! tclsh
package require spice
spice::codemodel /usr/local/src/tclspice-0.2.12/src/xspice/icm/spice2poly.cm
spice::source netlistname.cir
spice::tran 0.1ns 40ns
spice::run
spice::plot Vout
puts "All done now!"

Tome nota que, ya que TclSpice no lee el archivo de inicialización spinit, será necesario de incluir todas los comandos de inicialización directamente en el programa Tcl. Por ejemplo, en el ejemplo arriba, leemos el modelo spice2poly directamente en la memoria de trabajo. Muchos otros comandos están disponibles; el conjunto completo de comandos de TclSpice está documentado en http://tclspice.sourceforge.net/docs/tclspice_com.html.

Problemas con Tclspice

Un problema mayor con TclSpice (heredado de Ngspice) es que 'pierde' memoria. Entonces, se ve limitado el tiempo en el cual se puede correr una simulación. Eso significa que si desea correr un lazo de optimización muchas, muchas veces, puede terminar sin memoria antes de la terminación del programa. Este es un problema conocido con TclSpice, y se está trabajando para corregir las 'pérdidas'.

Mientras, hay algunos trucos que pueden ser utilizado con diseños de tamaño mediano, para facilitar corridas largas de optimización. Un método que utilicé, es de forzar que el optimizador escriba su estado actual a un archivo luego de cada análisis, y luego leerlo desde el archivo. El optimizador también almacena la lista actualizada de los componentes óptimos en otro archivo, y lo lee al principio de cada corrida.

Luego, tengo un programa Tcl llamado TaskMgr.tcl que corre en un lazo; en cada iteración del lazo despacha un proceso hijo que corre el optimizador. Mientras, el proceso pariente espera por 5 minutos (tiempo determinado heurísticamente), y envia una señal 'KILL' al proceso hijo antes de reiniciar el optimizador. De estar forma, el optimizador nunca corre suficiente tiempo para consumir toda la memoria de la máquina. El programa TaskMgr.tcl se muestra a continuación:

#! tclsh
package require Tclx
while {1} {
  set PID [fork]
  if {$PID} {
    # Parent
    after 300000
    puts "About to kill child PID = $PID . . . ."
    kill $PID
    wait $PID
  } else {
    # Child
    source Optimize.tcl
    # If we ever get through this, we can print out the following:
    error "We are done now!!!!!!"
  }
}

Note que TaskMgr.tcl necesita el paquete TclX ya instalado para correr TclSpice. Además, puede necesitar cambios en el tiempo de espera, dependiendo de la cantidad de memoria, y la velocidad de su máquina. Finalmente, el programa pariente tiene que esperar en el PID del hijo, para que este termine y su código sea removido de la lista de tareas del kernel Linux cuando muera. Sino, terminará con una pila de procesos 'zombie' en su sistema mientras ejecuta el optimizador. Una corrida podría convertir su sistema en la noche de los muertos vivientes.

Este método de esperar un tiempo específico para el proceso hijo es preferible si cada corrida de análisis toma un tiempo relativamente corto comparado con el tiempo necesario para 'comer' toda la memoria de la máquina. Una técnica mejor, es de encargar el programa pariente del estado del análisis, iniciar un solo análisis, y hacer termianr la corrida después de cada iteración.

Si este método es preferible depende del tamaño y de la complejidad de su diseño; tendrá que experimentar con su análisis para ver cuanto tiempo toma, y cuanta memoria consume. Encontré que un diseño con seis amplificadores (con los correspondientes modelos), mas unos 50 componentes pasivos, corre en menos de 10 segundos en una PIII de 333 MHz con 128 MB de RAM. Entonces, su diseño deberá ser muy grande antes de que un solo análisis pueda consumir cantidades significantes de RAM. 6018

correo