Introduccion al Diseno˜ de Circuitos VLSI en CMOS 1 · Cap´ıtulo 1 Introducci´on a las Herramientas de Alliance El sistema de herramientas proporcionados por Alliance nos permite

Introduccion al Diseno de Circuitos VLSI en CMOS 1

Carlos Silva CardenasUniversidad Catolica del Peru

Takeo YoshidaUniversidad de los Ryukyus

Alberto Palacios PawlovskyUniversidad Toin de Yokohama

18 de agosto de 2006

1Trabajo auspiciado por el Ministerio de Educacion Ciencia y Deporte del Japon y la Universidad Toin de Yokohama

2

Indice general

1. Introduccion a las Herramientas de Alliance 111.1. ASIMUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1.1. Subconjunto VHDL aceptado por Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2. B2F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.3. BOOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.4. BOOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.5. COUGAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.6. DREAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341.7. DRUC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361.8. FlatBeh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371.9. FLATLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391.10. FLATPH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391.11. FMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391.12. FSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411.13. GENPAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411.14. GRAAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421.15. K2F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431.16. L2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441.17. LOON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471.18. LVX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481.19. MOKA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481.20. NERO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491.21. OCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501.22. Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511.23. Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531.24. S2R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531.25. SCAPIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531.26. SYF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541.27. VASY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551.28. X2Y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551.29. XFSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561.30. XPAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561.31. XSCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571.32. XVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

2. Ejemplos de Diseno Combinacional 592.1. El diseno de un multiplicador de 4 bits usando sumadores en arbol . . . . . . . . . . . . . . . . . 59

2.1.1. Diseno de un generador de productos parciales . . . . . . . . . . . . . . . . . . . . . . . . 612.1.2. Diseno de un medio-sumador y sumador completo . . . . . . . . . . . . . . . . . . . . . . 632.1.3. Arbol sumador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642.1.4. Sumador de salida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662.1.5. Multiplicador de 4 bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

2.2. El uso de Makefiles para automatizar el flujo de diseno . . . . . . . . . . . . . . . . . . . . . . . . 74

3

4 INDICE GENERAL

Indice de figuras

1.1. Un multiplexor de 2 entradas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2. Verificando la correccion del archivo de diseno usando ASIMUT. . . . . . . . . . . . . . . . . . . 131.3. El archivo mux in.pat mostrado por xpat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4. Simulacion del diseno funcional usando ASIMUT. . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5. El archivo mux out.pat mostrado por xpat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.6. Una posible configuracion estructural de nuestro circuito multiplexor. . . . . . . . . . . . . . . . 191.7. Simulacion de la estructura basica usando ASIMUT. . . . . . . . . . . . . . . . . . . . . . . . . . 231.8. El rwgraph.fsm mostrado mediante el xfsm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.9. El proceso de sıntesis usando BOOM nd BOOG . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.10. El mux.vst mostrado mediante el xsch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.11. El mux oo.vst mostrado mediante el xsch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.12. The muxoop.ap (the mux design placed by OCP) shown by graal. . . . . . . . . . . . . . . . . . . 301.13. El muxoor.ap (archivo mux ruteado.o enlazado por NERO) mostrado mediante graal. . . . . . . . 321.14. El proceso de un archivo de diseno con OCP y NERO. . . . . . . . . . . . . . . . . . . . . . . . . 321.15. Flujo de verificacion incluyendo COUGAR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341.16. Layout real de nuestro mux mostrado por DREAL. . . . . . . . . . . . . . . . . . . . . . . . . . . 361.17. El archivo muxgp inpat mostrado mediante XPAT. . . . . . . . . . . . . . . . . . . . . . . . . . . 431.18. Snapshot del archivo Postcript generado mediante L2P (ubicado por default). . . . . . . . . . . . 461.19. Colocacion orientada del pad del circuito multiplexor usando OCP. . . . . . . . . . . . . . . . . . 51

2.1. Los bloques basicos para construir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592.2. Generador de productos parciales de 4bits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592.3. Tres esquemas de sumadores en arbol propuestos por: (a) Wallace (b) Dadda (c) Palacios . . . . 602.4. Detalles del circuito Medio-sumador (Half-adder, HA). . . . . . . . . . . . . . . . . . . . . . . . . 602.5. Detalles del circuito Sumador completo (Full-adder, FA). . . . . . . . . . . . . . . . . . . . . . . . 602.6. Sumador con acarreo de 4bits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602.7. Diseno jerarquico del multiplicador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612.8. Flujo de diseno en un diseno jerarquico hasta el paso de ubicacion o posicionamiento. . . . . . . 712.9. Layout mostrado por DREAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5

6 INDICE DE FIGURAS

Indice de cuadros

1.1. Opciones en ASIMUT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2. Conjunto de tipos usados en el subconjunto VHDL de Alliance. . . . . . . . . . . . . . . . . . . . 181.3. Declaraciones Concurrentes en el subconjunto VHDL de Alliance. . . . . . . . . . . . . . . . . . . 231.4. Opciones disponibles para la herramienta B2F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.5. Opciones disponibles para la herramienta BOOG. . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.6. Opciones Disponibles para la herramienta BOOM. . . . . . . . . . . . . . . . . . . . . . . . . . . 271.7. Opciones Disponibles para la herramienta COUGAR. . . . . . . . . . . . . . . . . . . . . . . . . 301.8. Opciones Disponibles para la herramienta DREAL. . . . . . . . . . . . . . . . . . . . . . . . . . . 351.9. Opciones Disponibles para la herramienta DRUC. . . . . . . . . . . . . . . . . . . . . . . . . . . 371.10. Opciones Disponibles para la herramienta FLATLO. . . . . . . . . . . . . . . . . . . . . . . . . . 391.11. Opciones Disponibles para la herramienta FLATPH. . . . . . . . . . . . . . . . . . . . . . . . . . 391.12. Opciones Disponibles para la herramienta FMI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391.13. Opciones Disponibles para la herramienta FSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411.14. Opciones Disponibles para la herramienta GENPAT. . . . . . . . . . . . . . . . . . . . . . . . . . 411.15. Opciones Disponibles para la herramienta GRAAL. . . . . . . . . . . . . . . . . . . . . . . . . . . 431.16. Opciones Disponibles para la herramienta L2P. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451.17. Opciones Disponibles para la herramienta LOON. . . . . . . . . . . . . . . . . . . . . . . . . . . . 471.18. Opciones Disponibles para la herramienta LVX Tool. . . . . . . . . . . . . . . . . . . . . . . . . . 481.19. Opciones Disponibles para la herramienta MOKA. . . . . . . . . . . . . . . . . . . . . . . . . . . 481.20. Opciones Disponibles para la herramienta NERO. . . . . . . . . . . . . . . . . . . . . . . . . . . . 501.21. Opciones Disponibles para la herramienta OCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501.22. Opciones Disponibles para la herramienta proof. . . . . . . . . . . . . . . . . . . . . . . . . . . . 521.23. Opciones Disponibles para la herramienta S2R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531.24. Opciones Disponibles para la herramienta SCAPIN. . . . . . . . . . . . . . . . . . . . . . . . . . 541.25. Opciones Disponibles para la herramienta SYF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541.26. Opciones Disponibles para la herramienta VASY. . . . . . . . . . . . . . . . . . . . . . . . . . . . 561.27. Formatos manejados por la herramienta X2Y. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561.28. Opciones Disponibles para la herramienta XPAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . 571.29. Opciones Disponibles para la herramienta XSCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7

8 INDICE DE CUADROS

Prefacio

La tecnologıa ha avanzado hasta un punto donde casi cualquier persona con las herramientas y conocimientocorrectos podrıan hacer lo que hace pocos anos era la tarea de un grupo de especialistas dotados con potentesestaciones de trabajo y herramientas de software muy costosas. Tenemos hoy en dıa computadoras potentes ybaratas y software libre muy elaborado que nos ha permitido encontrar muchas maneras de hacer diversas cosas.Esto es verdad no solamente en el campo del diseno de paginas web, produccion de pelıculas, composicion demusica, y de muchos otros campos, pero tambien en el diseno de circuitos digitales.

Podrıamos hacer un cierto trabajo de investigacion o probar disenos de circuitos innovadores con softwaregratuito de diseno. Sin embargo puesto que muchas de las herramientas disponibles han sido desarrolladas porvoluntarios y/o investigadores y educadores como medios para ensenar y/o hacer investigacion, estas herra-mientas casi siempre carecen de la documentacion adecuada para los que empiezan a trabajar en el campo deldiseno digital y aquellos que necesitan informacion detallada para usar esas herramientas en educacion, disenobasico y/o prueba de circuitos.

En este libro, solo explicamos las herramientas de Alliance, desarrolladas en el Laboratorio LIP6 de laUniversidad Pierre y Marie Curie de Parıs; ya que es un conjunto completo de herramientas que cubren muchasetapas del proceso de diseno de un circuito VLSI. Los Autores de este Libro desean colaborar, con su granitode arena, juntando parte de la informacion que esta dispersa de manera que hasta los principiantes puedanbeneficiarse de ella.

Este libro es gratuito y esta disponible para cualquier persona que desee usarlo en algun curso o para usopersonal. La impresion y venta de este libro para cualquier proposito lucrativo esta prohibida. Sin embargo,usted puede imprimir o reproducir el libro o parte de el libremente para propositos educativos y no lucrativos.No necesita contactarnos en ese caso, siempre que incluya la pagina principal y este prefacio a las copiascorrespondientes.

El contenido del libro es muy ambicioso y esperamos que otras personas se sientan motivadas a contribuira su mejora. Pueden anadir, modificar y enriquecer el libro a su voluntad, solo esperamos que haga llegar lasmodificaciones a los autores para hacerlas publicas. Hemos revisado exhaustivamente el contenido del libro,pero sabemos que deben haber algunas correcciones por hacerse. Si Ud. encuentra algun error u omision, o tienealguna sugerencia o idea, por favor contactenos. Trataremos de incluir estas en futuras ediciones del libro.

Carlos Silva Cardenas ([email protected]), Takeo Yoshida ([email protected]), Alberto PalaciosPawlovsky ([email protected]).

9

10 INDICE DE CUADROS

Capıtulo 1

Introduccion a las Herramientas deAlliance

El sistema de herramientas proporcionados por Alliance nos permite disenar y probar un circuito desde suespecificacion hasta su disposicion fısica (layout) y muchos de sus formatos intermedios. Alliance proporcionauna biblioteca de celdas que permite el diseno de circuitos independiente de la tecnologıa usada en la etapa defabricacion. Las bibliotecas de celdas incluyen una biblioteca de celdas estandar y varias celdas de propositoespecıfico para memoria y la logica de la trayectoria de datos.

Muchas de las herramientas de Alliance pueden ser utilizadas independientemente como herramientas delınea de comando. Otros tienen un interfaz grafica que requiere las bibliotecas Motif y X11 usadas en muchasvariantes de UNIX y Linux. Si proporcionamos un archivo tecnologico adecuado, el diseno obtenido con Alliancepuede ser convertido a formato CIF o GDSII para la fabricacion del circuito.

En las secciones siguientes introducimos brevemente cada herramienta con un ejemplo muy simple parailustrar su uso y opciones.

1.1. ASIMUT

ASIMUT (A SIMUlation Tool) es una herramienta de lınea de comando con muchas capacidades. Puede serutilizada para comprobar la correccion de la descripcion de un circuito en su forma funcional o estructural enVHDL. Puede tambien ser utilizada para simular y generar las salidas del circuito para un sistema de entradasdeterminado. Uno corre o ejecuta ASIMUT escribiendo:

% asimut [options] [target_file] [input_pattern_file] [output_pattern_file]

Probemos ASIMUT con un pequeno ejemplo. Para esto usaremos la descripcion funcional del multiplexor de 2entradas mostrado en la figura 1.1.

Figura 1.1: Un multiplexor de 2 entradas.

En este circuito, si la entrada de control c es 1 la salida q tomara el valor de la entrada a, pero si c es 0 lasalida tomara el valor de la entrada b.

11

12 CAPITULO 1. INTRODUCCION A LAS HERRAMIENTAS DE ALLIANCE

La descripcion de este circuito en su forma funcional es:

-- mux.vbe : un circuito multiplexor de 2 entradas discretas

-- VHDL descripcion funcional

ENTITY mux IS

PORT(

a : IN BIT;

b : IN BIT;

c : IN BIT;

q : OUT BIT;

vdd : IN BIT;

vss : IN BIT );

END mux;

ARCHITECTURE vbe OF mux IS

BEGIN

q <=((a AND c) OR (NOT(c) AND b));

END vbe;

Verifiquemos esta descripcion con ASIMUT. Pero antes, verificaremos que las variables de entorno referenciadaspor ASIMUT estan fijadas correctamente. Suponemos que Ud. trabaja con valores por defecto luego de haberinstalado Alliance. Puede verificar las variables de entorno de la siguiente manera:

% env | grep MBK

MBK_IN_LO=vst

MBK_OUT_LO=vst

MBK_IN_PH=ap

MBK_OUT_PH=ap

MBK_WORK_LIB=.

MBK_CATAL_NAME=CATAL

MBK_SCALE_X=100

MBK_CATA_LIB=.:/usr/local/alliance/cells/sxlib:/usr/local/alliance/cells/dp_sxlib:

/usr/local/alliance/cells/rflib:/usr/local/alliance/cells/romlib:

/usr/local/alliance/cells/ramlib:/usr/local/alliance/cells/padlib

MBK_TARGET_LIB=/usr/local/alliance/cells/sxlib

MBK_C4_LIB=./cellsC4

MBK_VDD=vdd

MBK_VSS=vss

La mas importante para ASIMUT es MBK IN LO, que le indica a ASIMUT la extension del tipo del archivode entrada. El tipo por defecto en ASIMUT es estructural. Un archivo funcional debe ser especificado usandola opcion -b. La extension (sufijo) del archivo funcional es especificada por la variable de entorno VH BEHSFX.Para verificar solo la sintaxis del archivo de diseno de nuestro multiplexor usamos el siguiente comando:

% asimut -b -c mux

Notemos que solamente indicamos el nombre del archivo de destino debido a que su tipo (extension .vbe) estafijado explıcitamente por una de las opciones (-b). La salida sera como sigue:

% asimut -b -c mux

@ @@@@ @ @ @@@@@@@@@@

@ @ @@ @@@ @ @@ @

@@@ @@ @ @ @ @@ @

@@@ @@@ @@@ @@ @@@ @@@ @@@@ @@

@ @@ @@@@ @@@@ @@@ @@ @@ @@ @@ @@

@ @@ @@@@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@ @ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @ @@ @@ @@ @@ @@ @@@ @@

@@@@ @@@@ @ @@@@ @@@@@@ @@@@ @@@ @@@ @@@@ @@ @@@@@@

A SIMUlation Tool

Alliance CAD System 5.0 20040928, asimut v3.02

Copyright (c) 1991...1999-2005, ASIM/LIP6/UPMC

E-mail : [email protected]

Paris, France, Europe, Earth, Solar system, Milky Way, ...

initializing ...

searching ‘mux‘ ...

BEH : Compiling ‘mux.vbe‘ (Behaviour) ...

making GEX ...

Modifiquemos esta descripcion cambiando la salida q a x en la lınea que describe el comportamiento del circuito(x es una entrada desconocida ya que no esta declarada en la entidad de la descripcion funcional). En este caso

1.1. ASIMUT 13

ASIMUT detectara el error y dara la siguiente salida:

% asimut -b -c mux

@ @@@@ @ @ @@@@@@@@@@

@ @ @@ @@@ @ @@ @

@@@ @@ @ @ @ @@ @

@@@ @@@ @@@ @@ @@@ @@@ @@@@ @@

@ @@ @@@@ @@@@ @@@ @@ @@ @@ @@ @@

@ @@ @@@@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@ @ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @ @@ @@ @@ @@ @@ @@@ @@

@@@@ @@@@ @ @@@@ @@@@@@ @@@@ @@@ @@@ @@@@ @@ @@@@@@

A SIMUlation Tool





initializing ...



‘mux.vbe‘ Error 17 line 17 :‘x‘ unknown port or signal

cannot continue further more.

have a nice day...

En este caso, ASIMUT apunta a la segunda lınea empezando de la ultima, donde x aparece y tambien muestraun mensaje diciendonos que esta es un entrada o senal desconocida (no definida). El flujo de diseno hastaeste punto usando ASIMUT se muestra en la figura 1.2. Cuando corremos ASIMUT, como se muestra arriba,

Figura 1.2: Verificando la correccion del archivo de diseno usando ASIMUT.

tenemos dos opciones. La primera -b le dice a ASIMUT que el archivo de entrada es funcional. La segunda -cle dice a ASIMUT que compile el archivo indicado. Esta opcion permite a ASIMUT verificar errores de sintaxisen el archivo antes de compilarlo. Despues de compilar, ASIMUT ve si un archivo de patrones de entrada hasido dado. Si este archivo ha sido dado, se compila y se enlaza a la descripcion HDL del archivo indicado.Luego, ASIMUT simula la descripcion y usa el archivo de patrones de entrada para generar un archivo depatrones de salida para el circuito dado. Tanto el archivo de patrones de entrada como el de salida estan escritosen formato pat, usado en Alliance. Mas detalles sobre este formato seran mostrados en la seccion referente agenpat. Ahı explicaremos una forma simplificada para generar el archivo de patrones de entrada. Cada archivo


de patrones de entrada tiene el siguiente formato:

-- descripcion de las entradas y salidas :tipo del terminal, su nombre y tipo logico;

-- use B para valores binarios, O para octales y X para hexadecimales.

-- terminales de fuente y tierra

in vdd B;

in vss B;

-- otras entradas y salidas del circuito

-- las entradas y las salidas que se esperan en cada intervalo de tiempo

-- <tiempo> [descripcion]: valores de entrada en el orden indicado arriba, valor esperado;

-- los valores de salida son precedidos por una ?

-- escribimos los valores esperados despues de este simbolo ejemplo: ?1 o ?0

-- si deseamos que el simulador calcule el valor de salida escribimos este como ?*

begin

<0 ns> valor inicial : 10 00 ?*;

<+1 ns> intervalo siguiente : 10 00 ?*;

end;

Las lıneas que empiezan con −− indican un comentario. Siguiendo el patron mostrado podemos escribir elarchivo de patrones de entrada mux in.pat del multiplexor de la siguiente manera:

-- terminales del circuito multiplexor

in vdd B;

in vss B;

in c B;

in a B;

in b B;

out q B;

-- intervalos de tiempos de los valores de entrada y valores esperados de salida (indeterminados)

begin

<0 ns> mux_test : 10 000 ?*;

<+1 ns> notc_nota_notb : 10 000 ?*;

<+1 ns> notc_nota_b : 10 001 ?*;

<+1 ns> : 10 001 ?*;

<+1 ns> notc_a_notb : 10 010 ?*;

<+1 ns> : 10 010 ?*;

<+1 ns> notc_a_b : 10 011 ?*;

<+1 ns> : 10 011 ?*;

<+1 ns> c_nota_notb : 10 100 ?*;

<+1 ns> : 10 100 ?*;

<+1 ns> c_nota_b : 10 101 ?*;

<+1 ns> : 10 101 ?*;

<+1 ns> c_a_notb : 10 110 ?*;

<+1 ns> : 10 110 ?*;

<+1 ns> c_a_b : 10 111 ?*;

<+1 ns> : 10 111 ?*;

end;

Como se muestra en este archivo, hemos escrito un archivo de patrones de entrada para todas las combinacionesde valores de entrada posibles. Empezamos con 00 en el tiempo 0 y luego en cada intervalo de 1ns modificamos losvalores de entrada para probar el circuito para todas las combinaciones de entrada posibles. Podemos visualizarestos patrones usando xpat (ver seccion 1.30) e insertando el siguiente comando y abriendo mux in.pat desdeel menu de esta herramienta grafica.

% xpat &

El archivo abierto nos mostrara la senal de entrada y una senal indeterminada de salida como muestra lafigura 1.3. Con este archivo de patrones de entrada podemos correr ASIMUT y hacer que compile el circuito,su archivo de patrones de entrada y genere el archivo de patrones de salida correspondiente.

1.1. ASIMUT 15

Figura 1.3: El archivo mux in.pat mostrado por xpat.

Corremos ASIMUT de la siguiente manera:

% asimut -b mux mux_in mux_out

@ @@@@ @ @ @@@@@@@@@@

@ @ @@ @@@ @ @@ @

@@@ @@ @ @ @ @@ @

@@@ @@@ @@@ @@ @@@ @@@ @@@@ @@

@ @@ @@@@ @@@@ @@@ @@ @@ @@ @@ @@

@ @@ @@@@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@ @ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @ @@ @@ @@ @@ @@ @@@ @@

@@@@ @@@@ @ @@@@ @@@@@@ @@@@ @@@ @@@ @@@@ @@ @@@@@@

A SIMUlation Tool





initializing ...



making GEX ...

searching pattern file : ‘mux_in‘ ...

restoring ...

linking ...

executing ...

###----- processing pattern 0 : 0 ps -----###
















Nuevamente le decimos a ASIMUT con la opcion -b que el archivo de entrada es de tipo funcional, que elarchivo de patrones de entrada se llama mux in y que queremos que el archivo de patrones de salida generado


por la simulacion se llame mux out (Note que los archivos usados en las lıneas de comando de Alliance no llevanextension). Como podemos ver, el archivo funcional es compilado en esta salida, ASIMUT busca el archivo depatrones de entrada, enlaza los archivos y los ejecuta a intervalos indicados en el archivo de patrones de entrada.El flujo de diseno hasta esta etapa usando ASIMUT se muestra en la figura 1.4. Podemos abrir y mostrar el

Figura 1.4: Simulacion del diseno funcional usando ASIMUT.

archivo de salida mux out.pat con xpat. Esta vez la senal de salida q tambien se muestra como vemos en lafigura 1.5. Esta senal ha sido derivada de la descripcion funcional del circuito y de los valores asignados a c, ay b. Podemos verificar que el multiplexor se comporta como esperamos pasando b a la salida q cuando c es 0y a cuando c es 1. Tambien es posible indicar en el archivo de patrones de entrada si los ultimos valores en la

Figura 1.5: El archivo mux out.pat mostrado por xpat.

simulacion deben ser guardados para ser usados como valores iniciales del circuito en posteriores simulaciones.En este caso anadimos una lınea con el comando save; antes del comando end; en el archivo de patrones deentrada. Probemos usando una copia modificada de muestro archivo de patrones de entrada previa (solamentemostramos las 3 ultimas lıneas de muxs in.pat).

<+1 ns> : 10 110 ?*;

<+1 ns> c_a_b : 10 111 ?*;

<+1 ns> : 10 111 ?*;

save;

end;

Cuando usamos este archivo de patrones de entrada, la salida de la simulacion sera la misma, pero esta vezse generara un archivo adicional llamado igual que el archivo de patrones de entrada pero con extension .sav.Usando este archivo podemos fijar las condiciones iniciales del circuito antes de correr la simulacion con algunotro archivo de patrones de entrada.

Las opciones en ASIMUT se muestran en la Tabla 1.1. La extension .ext es especificada por la variable deentorno VH DLYSFX. Podemos verificar su valor de la siguiente manera:

% env | grep VH

VH_MAXERR=10

VH_BEHSFX=vbe

VH_PATSFX=pat

VH_DLYSFX=dly

1.1. ASIMUT 17

Cuadro 1.1: Opciones en ASIMUT.

Opcion Descripcion-b La descripcion RTL del circuito funcional-backdelay [min, max, typ] delayfile Usa el archivo delayfile (.ext) de retardos anotados.-bdd Usa BDDs (Binary Decision Diagram) al representar expresiones.-c Solo ejecuta la etapa de compilacion.

-core archivo nucleoEn un error, vacea el estado del circuito en un archivo ascii (.cor)y en un archivo binario (.sav).

-dbg[sbpldc] Llama al buscador de errores (para uso solo en desarrollo).-defaultdelay (-dd) Usa retardos nulos (no hay clausulas after en el archivo VHDL).-fixeddelay valor (-fd valor) Fija todos los retardos al valor indicado.-h Muestra el archivo de ayuda de ASIMUT.-i valor Inicializa todas las senales a valor. Este puede ser 0 o 1.-i savefile Lee el archivo .sav y usa este para inicializar la descripcion.

-inspect instancename Produce un archivo de patrones para la interface del elemento iden-tificado por instancename.

-l n Imprime n caracteres para las etiquetas de patron. Por defecto nes 15.

-nores No genera el archivo de patrones de salida

-p n Carga n patrones desde la entrada en cada momento. Si el valor es(defecto) 0, carga todos los patrones de entrada .

-t Rastrea las senales cuando se usan BDDs (modo desarrollo).-transport Usa el modelo de transporte de retardo (por defecto es inercial).-zerodelay (-zd) Hace nulos todos los retardos de la descripcion VHDL.

Esta salida nos dice que el numero maximo de errores es 10 y que la extension de los archivos funcionales, depatrones y de retardo son .vbe, .pat y .dly respectivamente. Debemos ser cuidadosos cuando usemos algunaopcion (Verificar las opciones disponibles usando -h). Por ejemplo, la opcion −bdd hara la simulacion mas rapida,pero incrementara los requisitos de memoria. Tambien debemos ser cuidadosos al nombrar archivos. Si usamosla opcion −i, el nombre del archivo de inicializacion no debe ser 1 o 0 sino este sera considerado como valor deinicializacion. Por otro lado, opciones como −p nos permite reducir la demanda de memoria cuando un grupogrande de patrones son simulados (despues de cada n patrones, el resultado de la simulacion es impreso en elarchivo de patrones de salida). No todo el sintaxis de VHDL es soportado en Alliance. Solo podemos usar unaparte de VHDL para describir nuestros disenos. Es por ello que tambien tendremos indicacion de errores alcompilar si usamos descripciones que no estan soportadas. En las secciones siguientes revisaremos brevementelas descripciones VHDL soportadas en las herramientas de Alliance.

1.1.1. Subconjunto VHDL aceptado por Alliance

El subconjunto VHDL de Alliance cumple con el estandard IEEE Std 1076-1987. Esto origina que lasdescripciones escritas en este subconjunto puedan ser usadas con cualquier herramienta VHDL comercial ogratuita. El subconjunto de Alliance nos permite describir solo circuitos digitales sıncronos. El circuito descritocon este subconjunto es una entidad de diseno que puede ser un submodulo de otras entidades o el modulo dealto nivel de un diseno. Cada entidad de diseno en VHDL define los puertos que permite la comunicacion deldiseno con el mundo exterior. Los puertos pueden ser del tipo in, out, e inout. Los puertos de tipo in soportanvalores de entrada del circuito. Los de tipo out soportan los valores de salida. Si el puerto soporta entradas ysalidas, debe declararse como tipo inout.

El conjunto de tipos predefinidos soportados por los puertos se muestran en la Tabla 1.2. Recuerde quelos tipos definidos por el usuario no son aceptados en el subconjunto VHDL usado en Alliance. En VHDLpodemos especificar una entidad estructuralmente o funcionalmente en un archivo. En otras palabras, podemosmezclar descripciones en un archivo de descripcion. Sin embargo, en el subconjunto aceptado por Alliance estono esta permitido. Debemos usar un archivo .vbe para la descripcion funcional de la entidad y un archivo .vstpara su descripcion estructural. En un diseno jerarquico solo las entidades terminales son requeridas para lograruna descripcion funcional. En las siguientes sub-secciones describiremos brevemente los detalles de la sintaxisaceptada en los subconjuntos estructurales y funcionales usados en Alliance.

1.1.1.1. Subconjunto Estructural VHDL

En el subconjunto aceptado por Alliance, la descripcion estructural de un diseno puede incluir declaracionesde senal y de componentes. Las senales internas pueden ser de cualquiera de los tipos mostrados en la Tabla 1.2.


Cuadro 1.2: Conjunto de tipos usados en el subconjunto VHDL de Alliance.

Tipo Descripcionbit El tipo estandar bit: ’0’ or ’1’bit vector Arreglo de bits

mux bit

Subtipo resuelto de bit usando la funcion de resolucion mux. Esta funcion chequeaque solo una fuente este conectada a una senal. El valor de la senal es el valor dela fuente activa. Si todas las fuentes estan inactivas el valor de la senal sera ’1’(pullup). Una senal de tipo mux bit debe ser declarada de la clase bus.

mux vector Arreglo de mux bit

wor bit

Subtipo resuelto bit usando la funcion de resolucion wor. Esta funcion permiteque una senal sea alimentada por mas de una fuente. Todas las activas tienen queproveer el mismo valor. El valor efectivo es el valor de las fuentes activas. Si todaslas fuentes estan desconectadas el valor de la senal sera ’1’ (pull up). Una senal deltipo wor bit debe ser declarada del tipo bus.

wor vector Array of wor bit

reg bit

Subtipo resuelto de bit usando la funcion de resolucion reg. Esta funcion chequeaque solo una fuente este conectada a una senal. El valor efectivo de la senal serala de la fuente. Una senal del tipo reg bit debe ser declarada del tipo register (locual hace que la senal mantenga su valor previo cuando todas las fuentes estandesconectadas).

reg vector Arreglo de reg bit

La descripcion estructural es en si un conjunto de componentes implementados. Los puertos (entradas ysalidas) de los componentes deben ser declarados con el mismo nombre, tipo y clase y en el mismo orden en queaparecen en la declaracion de la entidad. La interconexion de los componentes se describe usando un mapeode puertos. Podemos hacer un mapeo de puertos implıcito o explicito. Sin embargo, no estan permitidos lospuertos sin conexion. Ademas, solo el operador de concatenacion & puede ser usado en el mapeo de puertos.Veamos un ejemplo usando el multiplexor de la seccion anterior. Para esto usaremos una puerta AND.

-- AND gate entity andg is port(a : in bit;

b : in bit;

q : out bit;

vdd : in bit;

vss : in bit); end andg;

architecture vbe of andg is begin

q <= (a AND b); end vbe;

Asimismo usaremos el diseno terminal de la siguiente compuerta OR.

-- OR gate entity org is port(a: in bit;

b: in bit;

q: out bit;

vdd: in bit;

vss: in bit); end org;

architecture vbe of org is begin

q <= (a OR b); end vbe;

Y tambien el diseno terminal de la siguiente compuerta NOT .

-- inverter (NOT) gate entity invg is port(a : in bit;

x : out bit;

vdd : in bit;

vss : in bit); end invg;

architecture vbe of invg is begin

x <= NOT(a); end vbe;

Combinaremos estas tres puertas como muestra la Figura 1.6. El correspondiente archivo VHDL estructural es

1.1. ASIMUT 19

Figura 1.6: Una posible configuracion estructural de nuestro circuito multiplexor.

como sigue:

entity mux is

port (

a : in bit;

b : in bit;

c : in bit;

q : out bit;

vdd : in bit;

vss : in bit

); end mux;

architecture structural of mux is

signal s1 : bit; signal s2 : bit; signal s3 : bit;

Component andg

port (a : in bit;

b : in bit;

q : out bit;

vdd : in bit;

vss : in bit); end component;

Component org

port (a : in bit;

b : in bit;

q : out bit;

vdd : in bit;


Component invg

port (a : in bit;

q : out bit;

vdd : in bit;


begin

g1 : andg port map (a => a,

b => c,

q => s1,

vdd => vdd,

vss => vss);

g2 : invg port map (a => c,

q => s2,

vdd => vdd,

vss => vss);

g3 : andg port map (a => s2,

b => b,

q => s3,

vdd => vdd,

vss => vss);

g4 : org port map (a => s1,

b => s3,

q => q,

vdd => vdd,

vss => vss);

end structural;

De esta manera podemos construir cualquier diseno jerarquico. Pero recuerde que si el circuito correspondien-te esta en la parte baja de la jerarquıa (diseno terminal), debemos proveer tambien su descripcion funcional.


Previamente, en Alliance podıamos generar la descripcion estructural de un diseno usando una herramientallamada SCMAP que mapeaba la descripcion funcional (.vbe) a una estructural usando celdas standard pro-vistas por Alliance. Esta herramienta ya no esta disponible, pero podemos generar estos archivos usando otrasdos herramientas: BOOM y BOOG. Mostraremos un ejemplo trivial sobre su uso aplicandolas para generararchivos estructurales del diseno del multiplexor. La primera herramienta realiza una minimizacion booleana dela descripcion funcional (En nuestro diseno los disenos terminales son compuertas basicas, por lo tanto no serealizara nada significativo). Para ello usaremos el siguiente comando:

% boom -l 3 -d 50 invg

Este comando le dice a BOOM que debe minimizar el diseno descrito en invg.vbe. La opcion -l da el valor deoptimizacion (valor entre 0 y 3). La opcion -d indica que queremos optimizar, en porcentaje. Un valor de 0( %)indica que queremos optimizar retardos. Un valor de 100(%) optimiza area. En nuestro ejemplo indicaremosque tanto retardo como area seran optimizados equitativamente. La salida correspondiente sera como sigue:

% boom -l 3 -d 50 invg

@@@@@@@ @@@ @@@

@@ @@ @@ @@

@@ @@ @@@ @@@

@@ @@ @@@ @@@ @@@ @@@

@@ @@ @@ @@ @@ @@ @ @@ @ @@

@@@@@@ @@ @@ @@ @@ @ @@ @ @@

@@ @@ @@ @@ @@ @@ @ @@@ @@

@@ @@ @@ @@ @@ @@ @ @@ @@

@@ @@ @@ @@ @@ @@ @ @ @@

@@ @@ @@ @@ @@ @@ @ @@

@@@@@@@@ @@@ @@@ @@@ @@@@

BOOlean Minimization

Alliance CAD System 5.0 20040928, boom 5.0

Copyright (c) 2000-2005, ASIM/LIP6/UPMC

Author(s): Ludovic Jacomme


--> Parse BEH file invg.vbe

--> Drive BEH file invg_o

Como no hemos indicado un archivo de salida, un archivo con el nombre original seguido con o sera generado.Usamos el mismo comando para las otras dos puertas: andg y org. Con los disenos funcionales optimizadosusamos BOOG para generar las descripciones estructurales correspondientes. BOOG hace un seguimiento de ladescripcion funcional y genera y optimiza una descripcion estructural basada en la librerıa de celdas standard(sxlib) proporcionada por Alliance. Para usarla utilizamos el siguiente comando:

% boog invg_o invg -x 1 -m 2

Este comando le dice a BOOG que debe usar invg o.vbe y generar un archivo estructural invg.vst optimizado.La opcion -x indica que queremos generar un archivo invg.xsc de salida. Este archivo mostrara las celdasusadas y tambien los retrasos. Si fijamos un valor de 0 para esta opcion, solo las trayectorias criticas serancoloreadas. Si fijamos un valor de 1, todas las trayectorias seran coloreadas. La opcion -m indica que queremosoptimizar (podemos usar valores entre 0 y 4). Un valor de 0 indica que queremos optimizar area. Un valor de4 optimizara retardos. En el ejemplo indicamos que tanto el area como el retardo deben ser optimizados. El

1.1. ASIMUT 21

correspondiente archivo de salida es el siguiente:

% boog invg_o invg -x 1 -m 2

@@@@@@@ @@@@ @

@@ @@ @@ @@

@@ @@ @@ @

@@ @@ @@@ @@@ @@

@@ @@ @@ @@ @@ @@ @@

@@@@@@ @@ @@ @@ @@ @@ @@@@@

@@ @@ @@ @@ @@ @@ @@ @ @@

@@ @@ @@ @@ @@ @@ @@ @ @@

@@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@@ @@@ @@@ @@@@

Binding and Optimizing On Gates

Alliance CAD System 5.0 20040928, boog 5.0 [2003/01/09]


Author(s): Fran?ois Donnet


MBK_VDD : vdd

MBK_VSS : vss

MBK_IN_LO : vst

MBK_OUT_LO : vst

MBK_WORK_LIB : .

MBK_TARGET_LIB : /usr/local/alliance/cells/sxlib

Reading default parameter...

50% area - 50% delay optimization

Reading file ’invg_o.vbe’...

Controlling file ’invg_o.vbe’...

Reading lib ’/usr/local/alliance/cells/sxlib’...

Mapping Warning: Cell ’halfadder_x4’ isn’t supported


Mapping Warning: Cell ’fulladder_x4’ isn’t supported


Controlling lib ’/usr/local/alliance/cells/sxlib’...

Preparing file ’invg_o.vbe’...

Capacitances on file ’invg_o.vbe’...

Unflattening file ’invg_o.vbe’...

Mapping file ’invg_o.vbe’...

Saving file ’invg.vst’...

Quick estimated critical path (no warranty)...116 ps from ’a’ to ’q’

Quick estimated area (with over-cell routing)...750 lambda?

Details...

inv_x2: 1

Total: 1

Saving delay gradient in xsch color file ’invg.xsc’...

End of boog...

Daremos el mismo comando para las otras dos puertas: andg o y org o. Esto nos dara los archivos .vstcorrespondientes a nuestros disenos. Chequearemos haciendo lo siguiente:

% ls *.vst

andg.vst inv.vst invg.vst mux.vst org.vst

Una vez que tengamos todos estos archivos, podemos simular nuestra descripcion estructural usando ASIMUTde la siguiente manera:

% asimut mux mux_in muxst_out

Estamos usando los patrones de entrada que utilizamos para probar nuestra descripcion funcional, y ahoraestamos guardando los patrones generados en un archivo muxst out.pat. Podemos usar este archivo para


comparar las salidas obtenidas con los de la descripcion funcional. Esta vez conseguiremos la siguiente salida:

% asimut mux mux_in muxst_out

@ @@@@ @ @ @@@@@@@@@@

@ @ @@ @@@ @ @@ @

@@@ @@ @ @ @ @@ @

@@@ @@@ @@@ @@ @@@ @@@ @@@@ @@

@ @@ @@@@ @@@@ @@@ @@ @@ @@ @@ @@

@ @@ @@@@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@ @ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @ @@ @@ @@ @@ @@ @@@ @@

@@@@ @@@@ @ @@@@ @@@@@@ @@@@ @@@ @@@ @@@@ @@ @@@@@@

A SIMUlation Tool





initializing ...


compiling ‘mux‘ (Structural) ...

flattening the root figure ...

searching ‘o2_x2‘ ...

BEH : Compiling ‘o2_x2.vbe‘ (Behaviour) ...

making GEX ...

searching ‘inv_x2‘ ...

BEH : Compiling ‘inv_x2.vbe‘ (Behaviour) ...

making GEX ...

searching ‘a2_x2‘ ...

BEH : Compiling ‘a2_x2.vbe‘ (Behaviour) ...

making GEX ...

searching pattern file : ‘mux_in‘ ...

restoring ...

linking ...

executing ...

















Notara que esta vez no hemos indicado el tipo de archivo de entrada (lo hicimos previamente usando laopcion −b). Esto es posible en este punto debido a que la variables de entorno correspondiente fueron fijadascorrectamente. En caso de duda, se usa el siguiente comando:

% env | grep MBK

1.1. ASIMUT 23

Esto nos dara la siguiente salida(este correponde a nuestro entorno en este punto en el flujo de diseno):

% env | grep MBK

MBK_IN_LO=vst

MBK_OUT_LO=vst

MBK_IN_PH=ap

MBK_OUT_PH=ap

MBK_WORK_LIB=.

MBK_CATAL_NAME=CATAL

MBK_SCALE_X=100

MBK_CATA_LIB=.:/usr/local/alliance/cells/sxlib:/usr/local/alliance/cells/dp_sxlib:

/usr/local/alliance/cells/rflib:/usr/local/alliance/cells/romlib:/usr/local/alliance/cells/ramlib:

/usr/local/alliance/cells/padlib

MBK_TARGET_LIB=/usr/local/alliance/cells/sxlib

MBK_C4_LIB=./cellsC4

MBK_VDD=vdd

MBK_VSS=vss

No lo detallaremos aquı, pero note que MBK IN LO es de extension .vst, en este caso .vst es el formato pordefecto que espera ASIMUT. El flujo de diseno) usando ASIMUT hasta este punto se muestra en la figura 1.7.:

Figura 1.7: Simulacion de la estructura basica usando ASIMUT.

Los detalles de los subconjuntos funcionales aceptados por Alliance se dan en la siguiente sub-seccion.

1.1.1.2. Subconjunto funcional de VHDL

En muchos casos no necesitamos especificar la estructura de un diseno, pero si su funcion. En este caso nohacemos referencia alguna a la estructura interna de la entidad del diseno. Dicha descripcion se llama funcionalo comportamental. Ya hemos visto la descripcion funcional de 3 puertas basicas (AND, OR y NOT ) y unmultiplexor. En esos pequenos disenos es posible describir el comportamiento de los circuitos en funcion desus entradas. Sin embargo, circuitos mas complejos requieren otro tipo de descripciones. VHDL provee muchasmaneras de describir comportamientos complejos, pero Alliance acepta algunas de ellas. En los subconjuntosaceptados por Alliance, solamente se aceptan declaraciones concurrentes en las descripciones funcionales. Tam-poco podemos usar declaraciones concurrentes (lazos, etc) o procesos. La informacion de tiempo es permitida endescripciones funcionales usando el condicional after. Sin embargo, estos retardos se usan solo en la simulaciondel diseno y no en la sıntesis o en las etapas formales de prueba. Las declaraciones concurrentes en el subconjuntode Alliance se muestran en la Tabla 1.3: Cuando usamos declaraciones concurrentes, debemos asegurarnos que

Cuadro 1.3: Declaraciones Concurrentes en el subconjunto VHDL de Alliance.

Tipo Ejemploasignacion de senal sencilla q <= a and b;asignacion de senal condicional q <= D when clock = ’1’ and E = ’0’;

asignacion de senal seleccionada with expression selecttarget <= value1 when choice1, value2 when choice2;

declaracion concurrente asegura-da

assert Reset = ’1’;

declaracion de bloqueo clump : block begin A <= B or C; D <= B and not C; endblock clump ;

una senal ordinaria sea asignada solo una vez. El valor de la Senal debe ser definido explıcitamente mediante laasignacion de senal. Cuando seleccionamos una asignacion de senal, debemos asegurarnos que el valor de destinosea definido por cada valor que pueda tomar la expresion seleccionada. Las restricciones que puedan aparecerde este conjunto limitado de declaraciones se aplacan mediante el uso de senales resueltas (ver seccion VHDL).Tambien podemos ver senales guardadas. En el siguiente ejemplo, un bus con 2 drivers, muestra el uso de las


senales resueltas y guardadas.

begin first_driver_of_mux : block (Sel1 = ’1’) begin

Distributed_Mux <= guarded Data1; end block;

second_driver_of_mux : block (Sel2 = ’1’) begin

Distributed_Mux <= guarded Data2; end block;

Podemos usar declaraciones secuenciales pero sus elementos secuenciales deben ser explıcitamente declaradosusando reb bit o reg vector y deben ser de tipo registro. El elemento secuencial debe ser asignado por unaasignacion guardada dentro de un bloque de declaracion. La descripcion de un Flip-Flop muestra el uso de estasdeclaraciones:

begin

Reg <= guarded Din;

end block;

Otro ejemplo, una descripcion de un latch sensible a nivel.

begin

Lat <= guarded Din;

end block;

Si nosotros intentamos usar la descripcion funcional durante le proceso de sıntesis logica, debemos asegurarnosque la senal guardada depende solo de una sola senal (como en los ejemplos anteriores). En el subconjuntoapoyado por Alliance solamente son apoyados los operadores logicos ( not, and, or, xor, nor, y nand), laconcatenacion (&), igualdad (=) y la desigualdad (/ =).

Los operadores aritmeticos (+ y −), comparacion (<, >) y todos los otros operadores (mod, <= ∗∗, etc.)no son apoyados por Alliance. Tal como se indico antes, la informacion del timing es apoyada usando clausulasafter. Pero ellos no pueden ser usados en en sentencias secuenciales (aquellas senales de tipo registro). Sinembargo ellas pueden ser usadas en senales de tipo bus. Ellas tambien pueden ser usadas en asignacion desenales seleccionadas. La opcion transport no esta permitida en el subcojunto soportado por Alliance. En lasdeclaraciones solo dos niveles de severidad son apoyados. Uno es el cuidado”que aparece cuando la condicion noes satisfecha. La otra es un error que se imprime con un mensaje de error y se para la simulacion. En Alliance estambien posible usar D para senalar las condiciones o valores de ”no importa”para propositos de sıntesis perodebe tenerse cuidado debido a que no se trata de un estandar VHDL. Durante la simulacion D es reemplazadopor 0 mediante el ASIMUT Los unicos tipos de arreglos apoyados por Alliance se encuentran listados en laTabla 1.2.

1.2. B2F

La herramienta B2F (Behavior to Finite state machine format abstractor) es un traductor de una descripcionfuncional a un formato FSM (Maquina de Estado Finita). Usa como entrada una descripcion RTL (Niveltransferencia de registros) en descripcion VHDL, en formato .vbe. Esta herramienta usa un algoritmo desimulacion simbolica para construir un grafico equivalente a la maquina de estado finita de destino, que es dadacomo salida. Podemos usar la herramienta usando el siguiente comando:

% b2f [options] input_file output_flle

Las opciones de B2F se muestran en la Tabla 1.4.: Veamos un ejemplo usando esta herramienta. Para esto,

Cuadro 1.4: Opciones disponibles para la herramienta B2F.

Opcion Descripcion-V Sets Verbose mode on-I bit string Valor inicial del registro de estado-O o0,...,on Valor inicial (one index list)-Z z0,...,zn Valor inicial (zero index list)-R reset cond Reset condicion

1.2. B2F 25

usaremos la siguiente descripcion en VHDL de un controlador simple:

library IEEE;

use IEEE.std_logic_1164.all;

entity RWFSM is

port(

CLK : in std_logic;

START : in std_logic;

RW : in std_logic;

NE : in std_logic;

BUSY : out std_logic);

end RWFSM;

architecture RTL of RWFSM is

type STATE_TYPE is (IDLE, READING, WRITING, WAITING);

signal CURRENT_STATE, NEXT_STATE: STATE_TYPE;

begin

comb : process(CURRENT_STATE, START, RW, NE)

begin

BUSY <= ’0’;

case CURRENT_STATE is

when IDLE =>

if START = ’0’ then

NEXT_STATE <= IDLE;

elsif RW = ’1’ then

NEXT_STATE <= READING;

else

NEXT_STATE <= WRITING;

end if;

when READING =>

BUSY <= ’1’;

if NE = ’0’ then

NEXT_STATE <= READING;

else

NEXT_STATE <= WAITING;

end if;

when WRITING =>

BUSY <= ’1’;

if NE = ’0’ then

NEXT_STATE <= WRITING;

else

NEXT_STATE <= WAITING;

end if;

when WAITING =>

BUSY <= ’1’;

NEXT_STATE <= IDLE;

end case;

end process;

seq : process

begin

wait until CLK’event and CLK = ’1’;

CURRENT_STATE <= NEXT_STATE;

end process;

end RTL;

Convertiremos este archivo a una descripcion funcional de Alliance (archivo .vbe). Hacemos esto usando laherramienta VASY de Alliance, mediante el siguiente comando:

% vasy -Vaop -I vhd rwfsm

Esto producira el archivo rwfsm.vbe. Con este archivo podemos usar B2F para convertirlo en formato grafico.Para esto, usamos el siguiente comando:

% b2f -V rwfsm rwgraph

Esto generara el archivo rwgraph.fsm que puede ser visualizado con la herramienta XFSM de Alliance. Se debetener cuidado en usar el comando correspondiente en un entorno donde X11 esta disponible (XFSM se basa enla herramienta X11).

% xfsm

Esto empezara la herramienta de visualizacion XFSM. Desde su menu de archivos podemos seleccionar elarchivo rwgraph.fsm que se verıa como en la figura 1.8. Como podemos notar de este grafico, XFSM no es unaherramienta compleja. No muestra de manera correcta los lazos y no tiene capacidad de edicion.


Figura 1.8: El rwgraph.fsm mostrado mediante el xfsm.

1.3. BOOG

La herramienta BOOG (Binding and Optimizing On Gates) mapea una descripcion funcional sobre unalibrerıa predeterminada de celdas Standard. Como mostramos en un ejemplo sobre el uso del ASIMUT, estaherramienta es usada usualmente como un segundo paso del proceso de sıntesis en Alliance. Es usada despuesde BOOM. La descripcion optimizada por BOOM es la entrada de esta herramienta. BOOG construye una redbooleana equivalente a la descripcion obtenida con BOOM. Luego, para cada funcion booleana de cada nodo dela red, trata de encontrar una celda o un conjunto de celdas que implemente dicha funcion. El resultado sera unadescripcion estructural basada en las celdas de la librerıa SXLIB de Alliance. Usamos esta herramienta dandoel siguiente comando:

% boog [-hmxold] input_file output_file [lax_file]

Las opciones disponibles en BOOG se muestran en la Tabla 1.5. Cuando se usa BOOG, es importante ve-

Cuadro 1.5: Opciones disponibles para la herramienta BOOG.

Opcion Descripcion-h Modo de ayuda. Muestra los posibles usos de boog.

-m optim mode

Modo de Optimizacion. Puede ser definido en un archivo lax, esto representa solouna acceso directo para definirlo en la lınea de comando. Este modo numericotiene un arreglo definido entre 0 y 4, e indica la manera de optimizacion que elusuario requiere. Si se escoge 0, el area de circuito sera mejorado. Por otro lado,4 mejorara los retardos del circuito, mientras que 2 es un valor medio para laoptimizacion.

-x xsch mode

Genera un archivo ’.xsc’. Es un mapa de colores para cada una de las senales con-tenidas en la red output file. Este archivo es usado por xsch para ver el netlist.Escogiendo el nivel 0 o 1 para xsch mode, Ud. puede colorear las direcciones crıti-cas respectivamente o todas las senales con graduacion de retardos.

-o output file Otra forma de mostrar explıcitamente el nombre del archivo de salida VST.-l lax file Otra forma de mostrar explıcitamente el nombre del archivo de parametro LAX.

-d debug file Genera un archivo VBEdebug. Este proviene de un algoritmo de resultado interno.Los usuarios no estan comprometidos.

rificar que las variables de entorno correspondientes sean fijadas de manera correcta. Las mas importantesson MBK CATALIB, MBK TARGETLIB y MBK OUTLO. MBK CATALIB nos da las rutas de losarchivos de entrada auxiliares (los funcionales). MBK TARGETLIB determina la ruta del directorio de lalibrerıa de celdas Standard elegida. Finalmente, MBK OUTLO nos da el formato de salida de la descripcionestructural.

1.4. BOOM 27

1.4. BOOM

La herramienta BOOM (BOOlean Minimization) es usada en la primera etapa del proceso de sıntesis DEAlliance. Optimiza la descripcion funcional usando una representacion RBDD (Diagrama de Decisiones Binariasde Orden Reducido) de su funcion logica. Esta herramienta da buenos resultados para logica aletoria pequena,pero no es aplicable a optimizacion de trayectoria de datos. Podemos usar esta herramienta mediante el siguientecomando:

% boom [-VTOAP] [-l num] [-d num] [-i num] [-a num] [-sjbgpwtmorn] filename [outname]

Las opciones disponibles en BOOM se muestra en la Tabla 1.6:. Hemos visto un ejemplo sobre el uso de

Cuadro 1.6: Opciones Disponibles para la herramienta BOOM.

Opcion Descripcion

-V Modo Verbose activo. Cada paso de optimizacion es desplegado en la salida estan-dard.

-T Modo Trace activo. Alguna informacion de depuracion es desplegada en la salidaestandard.

-O Reverses initial Bdd variables order.

-A

BOOM ejecuta una optimizacion local y mantiene la arquitectura de la descripcioninicial al salvar la mayorıa de las senales intermedias. Este modo esta bien estudiadopara circuitos grandes o regulares tales como multiplicadores y sumadores. BOOMejecuta por defecto una optimizacion y remueve la mayorıa de las senales intermediasde manera tal que las salidas son expresadas en terminos de las entradas o de losregistros internos. Este modo esta bien ajustado a circuitos aleatorios tales comoFSMs.

-PUsa un archivo de parametro input name.boom describiendo las directivas de opti-mizacion y coaccion. (vea abajo para la sintaxis exacta)

-l num Escifica el nivel de optimizacion [0-3] (por defecto es 0, nivel bajo).

-d numEscifica el retardo de optimizacion porcentual (por defecto es 0 %retardo, 100%superficie).

-i numEspecifica el numero de iteraciones para los algoritmos de optimizacion escogidos(solo para expertos).

-a num Especifica la amplitud durante el reordenamiento bdd (solo para expertos).-sjbgpwtmorn Especifica cual algoritmo ha sido usado para la optimizacion booleana.

BOOM. Ahora usaremos BOOM y BOOG para optimizar nuestro circuito mux. Primero optimizaremos sudescripcion funcional con BOOM. Tal como lo hicimos previamente, usaremos el nivel maximo de optimizaciony optimizaremos retardo y area. En este caso BOOM nos dara la siguiente salida:

% boom -l 3 -d 50 mux

@@@@@@@ @@@ @@@

@@ @@ @@ @@

@@ @@ @@@ @@@

@@ @@ @@@ @@@ @@@ @@@

@@ @@ @@ @@ @@ @@ @ @@ @ @@

@@@@@@ @@ @@ @@ @@ @ @@ @ @@

@@ @@ @@ @@ @@ @@ @ @@@ @@

@@ @@ @@ @@ @@ @@ @ @@ @@

@@ @@ @@ @@ @@ @@ @ @ @@

@@ @@ @@ @@ @@ @@ @ @@

@@@@@@@@ @@@ @@@ @@@ @@@@






--> Parse BEH file mux.vbe

--> Drive BEH file mux_o

BOOM genero una version minimizada del mux llamado mux o, que sera usada como entrada para BOOG.Ası como en el ejemplo de ASIMUT, ejecutamos BOOG indicando que queremos optimizar retardo y area yque queremos un archivo de salida para visualizar todos los retardos. Ejecutando BOOG nos dara la siguiente


salida:

% boog mux_o mux_oo -x 1 -m 2

@@@@@@@ @@@@ @

@@ @@ @@ @@

@@ @@ @@ @

@@ @@ @@@ @@@ @@

@@ @@ @@ @@ @@ @@ @@

@@@@@@ @@ @@ @@ @@ @@ @@@@@

@@ @@ @@ @@ @@ @@ @@ @ @@

@@ @@ @@ @@ @@ @@ @@ @ @@

@@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@@ @@@ @@@ @@@@






MBK_VDD : vdd

MBK_VSS : vss

MBK_IN_LO : vst

MBK_OUT_LO : vst

MBK_WORK_LIB : .




Reading file ’mux_o.vbe’...

Controlling file ’mux_o.vbe’...







Preparing file ’mux_o.vbe’...

Capacitances on file ’mux_o.vbe’...

Unflattening file ’mux_o.vbe’...

Mapping file ’mux_o.vbe’...

Saving file ’mux_oo.vst’...

Quick estimated critical path (no warranty)...657 ps from ’c’ to ’q’


Details...

ao2o22_x2: 1

inv_x2: 1

Total: 2

Saving delay gradient in xsch color file ’mux_oo.xsc’...

End of boog...

El proceso de sıntesis con BOOM y BOOG se muestra en la figura 1.9. Para ver los esquematicos del diseno

Figura 1.9: El proceso de sıntesis usando BOOM nd BOOG

del mux usamos la herramienta grafica XSCH. La llamamos usando el siguiente comando:

% xsch

Entonces, desde su menu de archivos podemos elegir cualquier archivo .vst en nuestro directorio de trabajo.Veamos primero nuestro diseno estructural original mux.vst. Este se muestra en la figura 1.10. Veamos ahorael circuito optimizado y sintetizado del mux (mux oo.vst). Lo podemos ver en la figura 1.11. Como podemosver de estas figuras, el circuito original del mux esta formado por componentes discretos, mientras que eldiseno optimizado esta hecho con solo 2 celdas, un inversor y una puerta compleja and-or (ambas fueronescogidas por BOOG de la librerıa de celdas SXLIB de Alliance). Cuando usamos XSCH tenemos que variar las

1.5. COUGAR 29

Figura 1.10: El mux.vst mostrado mediante el xsch.

Figura 1.11: El mux oo.vst mostrado mediante el xsch.

capas y elementos a mostrar antes de obtener el mejor esquema que se ajuste a las necesidades. Usamos estosesquematicos para ver que efecto producen diferentes configuraciones en la visualizacion de nuestros disenos.Luego de encontrar el mejor posicionamiento y configuracion de la ventana la grabamos usando el comandoSave Config del menu Setup de XSCH. La unica variable de entorno de la cual debemos tener cuidadocuando ejecutemos BOOM es MBK WORL LIB. Esta variable debe ser fijada en nuestro directorio de trabajo.

1.5. COUGAR

Esta herramienta es el extractor de netlist usado en Alliance y fue conocido formalmente como LYNX(Secambio el nombre parra evitar problemas en sistemas que tambien usan el popular web browser Lynx). COUGARes un extractor jerarquico que se aplica a un layout simbolico, pero no puede usarse a un layout real a menosque se provea del archivo tecnologico correspondiente (archivo RDS). COUGAR puede solo extraer transistoresCMOS (ningun otro dispositivo es soportado). Tambien extrae capacitancias y resistencias parasitas, pero conmuy baja precision. COUGAR es ejecutado normalmente con el siguiente comando:

COUGAR [ -v ] [-c ] [ -f ] [ -t ] [-ar ] [ -ac ] input_name [output_name ]

Las opciones disponibles en COUGAR se muestran en la Tabla 1.7. Cuando no se especifican opciones, COU-GAR extraera el nivel jerarquico actual. El netlist resultante sera la lista de interconexiones del actual niveljerarquico del layout. COUGAR se usa para verificar disenos. Veremos un pequeno ejemplo de su uso aplicandoloa nuestro circuito del mux. Para hacer eso, primero necesitamos colocarlo y rutearlo”. Para esto, usaremos otrasherramientas proveıdas por Alliance. Primero colocamos el circuito (el optimizado por BOOG y BOOM) usandoOCP. Observamos lo siguiente (tomar en cuenta que las variables MBK IN LO y MBK OUT PH determinan


Cuadro 1.7: Opciones Disponibles para la herramienta COUGAR.

Opcion Descripcion

-tNotifica el nivel de extraccion de un transistor, la celda del arreglo simbolico es aplanada aun arreglo de transistor antes de la extraccion.

-f

La celda del arreglo simbolico es aplanada a un nivel de catalogo antes de la extraccion.Use ”man catal”para detalles en el archivo de catalogo. Si el catalogo esta vacıo o no existeel netlist es una interconeccion de transistores, sino, el netlist es una interconeccion decompuertas o bloques de quienes los nombres estan definidos en el catalogo.

-v Mod Verbose activo. Cada paso de extraccion es desplegado en la salida estandard juntocon valores estadisticos.

-c

Genera un archivo central que representa la red conflictuel, cuando COUGAR detecta dosconectores externos con nombres diferentes sobre la misma senal, o cuando encuentra dosconectores externos que tienen el mismo nombre pero que internamente no esta conectadosa la net o cuando no puede extraer correctamente un transistor del tipo L.

-ac Extraer capacitancia a tierra sobre losig.

-ar Extraer resistencia de interconeccion y capacitancia a tierra. El valor de la resistencia porcada capa puede ser modificado en el archvio RDS.

el tipo de archivo de entrada y de salida para y desde OCP).

% ocp mux_oo muxoop

@@@ @@@@ @ @@@@@@@

@@ @@ @@ @@ @@ @@

@@ @@ @@ @ @@ @@

@@ @@ @@ @ @@ @@

@@ @@ @@ @@ @@

@@ @@ @@ @@@@@

@@ @@ @@ @@

@@ @@ @@ @@

@@ @@ @@ @ @@

@@ @@ @@ @@ @@

@@@ @@@@ @@@@@@

Placer for Standards Cells

Alliance CAD System 5.0 20040928, ocp 5.0



o Special Net detected : vss

o Special Net detected : vdd

o No More Mouvement Possible .....

Ocp : placement finished

Esto nos da el archivo muxoop.ap. Podemos visualizar este archivo usando la herramienta GRAAL deAlliance. Podemos llamarla desde la linea de comandos como graal y desde el menu de archivos elegimosel archivo muxoop.ap. Esto se muestra en la figura 1.12. Ahora podemos trazar o rutear.el diseno del mux

Figura 1.12: The muxoop.ap (the mux design placed by OCP) shown by graal.

1.5. COUGAR 31

colocado con la herramienta NERO de Alliance de la siguiente manera:

% nero -V -p muxoop mux_oo muxoor

@@@ @@@ @@@@@@@

@@ @ @@ @@

@@@ @ @@ @@

@ @@ @ @@@@@ @@ @@ @@@

@ @@ @ @ @ @@ @@ @@ @@

@ @@ @ @@ @@ @@@@@ @@ @@

@ @@ @ @@@@@@@@@ @@ @@ @@ @@

@ @@ @ @@ @@ @@ @@ @@

@ @@@ @@ @ @@ @@ @@ @@

@ @@ @@ @@ @@ @@ @@ @@

@@@ @@ @@@@ @@@@@ @@@ @@@

Negotiating Router

Alliance CAD System 5.0 20040928, nero 5.0



S/N 20021117.1

o MBK environment :

MBK_IN_LO := vst

MBK_OUT_LO := vst

MBK_IN_PH := ap

MBK_OUT_PH := ap

MBK_WORK_LIB := .

MBK_CATA_LIB := .

/usr/local/alliance/cells/sxlib

/usr/local/alliance/cells/dp_sxlib

/usr/local/alliance/cells/rflib

/usr/local/alliance/cells/romlib

/usr/local/alliance/cells/ramlib


MBK_CATAL_NAME := CATAL

MBK_VDD := vdd

MBK_VSS := vss

MBK_SEPAR := .

o Loading netlist "mux_oo"...

o Loading layout "muxoop"...

o Flattening layout...

o Flattening netlist...

o Building netlist dual representation (lofigchain)...

o Binding logical & physical views...

o Loading design into grid...

o Small design, global routing disabled.

o Allocating grid size [15,11,3].

o Loading external terminals.

o Finding obstacles.

o Loading nets into grid.

o Allocating the net scheduler.

o Reading power grid.

o Local routing stage.

- [ 4] (hp := 4) "a"

- [ 3] (hp := 4) "b"

- [ 2] (hp := 6) "q"

- [ 1] (hp := 14) "c"

- [ 0] (hp := 17) "inv_x2_sig"

o Routing stats :

- routing iterations := 169

- re-routing iterations := 0

- ratio := 0%.

o Dumping routing grid.

o Saving MBK figure "muxoor".

o Saving layout as "muxoor"...


Le decimos a NERO que ejecute en modo verbose, que use el archivo muxoop del netlist de mux oo yque genere un archivo de salida llamado muxoor. NERO nos da el archivo muxoor.ap que tambien puede servisualizado con GRAAL.

% graal

Esta vez elegimos el archivo muxoor.ap. Se muestra en la figura 1.13. El procesamiento del layout con OCP

Figura 1.13: El muxoor.ap (archivo mux ruteado.o enlazado por NERO) mostrado mediante graal.

y NERO se muestra en la figura 1.14. Una vez que el diseno esta ruteado o trazado, podemos usar COUGAR

Figura 1.14: El proceso de un archivo de diseno con OCP y NERO.

para extraer de el, el netlist correspondiente. Antes de usar COUGAR necesitamos fijar la variable de entornoMBK OUT LO como al. Hacemos esto con los siguientes comandos( bajo un C shell como tcsh o csh):

% setenv MBK_OUT_LO al

En un bash (o sh) shell serıa:

% export MBK_OUT_LO = al

Mientras que en un Bourne shell estandar:

% MBK_OUT_LO = al

% export MBK_OUT_LO

Podemos verificar si la configuracion fue correcta, usando el siguiente comando:

% echo $MBK_OUT_LO

al

1.5. COUGAR 33

La cual nos mostrara el valor de la variable de entorno. Una vez que se fija esta variable, usamos COUGAR dela siguiente manera:

% COUGAR muxoor muxooc

@@@@ @

@@ @@

@@ @

@@ @ @@@ @@@ @@@@ @@@@@@ @@@@ @@@ @@@

@@ @@ @@ @@ @@ @@ @@ @@ @ @@@ @@

@@ @@ @@ @@ @@ @ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @ @ @@@@@ @@

@@ @@ @@ @@ @@ @@@ @@ @@ @@

@@ @ @@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@@ @@@@@@ @@ @@@ @@

@@@@ @@@ @@@@ @@ @@ @@@ @@@@ @@ @@@@

@ @

@@@@@

Netlist extractor ... formerly Lynx

Alliance CAD System 5.0 20040928, COUGAR 1.21


Author(s): Ludovic Jacomme and Gregoire Avot

Contributor(s): Picault Stephane


---> Extract symbolic figure muxoor

<--- done !

---> Total extracted capacitance

<--- 0.0pF

COUGAR toma el archivo de entrada muxoor.ap, archivo de trazado simbolico del layout, y genera el net-list extraıdo muxooc.al. Ahora podemos usar otra herramienta de Alliance, LVX, para comparar el archivoestructural mux oo.vst y el netlist extraıdo por COUGAR. Se hace de la siguiente manera:

% lvx vst al mux_oo muxooc

@@@@@@ @@@@ @@@ @@@@ @@@@

@@ @@ @ @@ @

@@ @@ @ @@ @

@@ @@ @ @@ @

@@ @@ @ @@

@@ @@ @ @@

@@ @@ @ @@@

@@ @@@ @ @@

@@ @ @@@ @ @@

@@ @ @ @ @@

@@@@@@@@@@ @ @@@ @@@@

Gate Netlist Comparator

Alliance CAD System 5.0 20040928, lvx 1.4



***** Loading mux_oo (vst)...

***** Loading muxooc (al)...

***** Compare Terminals ...........

***** O.K. (0 sec)

***** Compare Instances ..........

***** O.K. (0 sec)

***** Compare Connections ..........

***** O.K. (0 sec)

===== Terminals .......... 6

===== Instances .......... 2

===== Connectors ......... 17

***** Netlists are Identical. ***** (0 sec)


La ultima lınea nos dice que los netlist son identicos, en otras palabras, que el diseno del mux ha sido trazadocorrectamente. La verificacion de diseno que incluye COUGAR puede ser vista en la figura 1.15. COUGAR

Figura 1.15: Flujo de verificacion incluyendo COUGAR.

puede extraer un netlist para Spice del diseno en formato ap. En este caso necesitamos fijar las variables deentorno MBK OUT LO en spi y MBK SPI MODEL (solo se muestra la disposicion para un shell de C).

% setenv MBK_OUT_LO spi

% setenv MBK_SPI_MODEL $ALLIANCE_TOP/etc/spimodel.cfg

Luego, podemos extraer el netlist para SPICE de la siguiente manera:

% COUGAR -t muxoor mux_oo

@@@@ @

@@ @@

@@ @

@@ @ @@@ @@@ @@@@ @@@@@@ @@@@ @@@ @@@

@@ @@ @@ @@ @@ @@ @@ @@ @ @@@ @@

@@ @@ @@ @@ @@ @ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @ @ @@@@@ @@

@@ @@ @@ @@ @@ @@@ @@ @@ @@

@@ @ @@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@@ @@@@@@ @@ @@@ @@

@@@@ @@@ @@@@ @@ @@ @@@ @@@@ @@ @@@@

@ @

@@@@@


Alliance CAD System 5.0 20040928, COUGAR 1.21





---> Extract symbolic figure muxoor

<--- done !


<--- 0.0pF

Este tipo de netlist puede ser simulado por un simulador SPICE si proveemos un modelo de transistor adecuada.

1.6. DREAL

Esta herramienta es un editor jerarquico de layout real similar a GRAAL (herramienta usada para visualizardisenos fijados y trazados), pero no posee un verificador de reglas de diseno, ni tampoco un extractor como siposee GRAAL. Usamos DREAL usando el siguiente comando:

% dreal [-l file_name] [-xor] [-debug] [-install] [-force]

1.6. DREAL 35

Cuadro 1.8: Opciones Disponibles para la herramienta DREAL.

Opcion Descripcion-l filename Cargar el nombre del archivo (con o sin extension)

-xor Dos metodos de cursor grafico pueden ser usados, inversor (defecto)o xor.

-debug-install Suiche a un mapa de color privado.

-force Esta opcion fuerza a que todos los objetos graficos sean desplega-dos.

Las opciones disponibles en DREAL se muestran en la Tabla 1.8. Esta herramienta generalmente se usa a lasalida de la herramienta S2R de Alliance. S2R convierte el layout simbolico obtenido con NERO en un layoutreal tecnologico en formato cif o gds. El formato de salida es dado por la variable de entorno RDS OUTPUT.Podemos verificar esto usando:

% env | grep RDS

RDS_IN=cif

RDS_OUT=cif

RDS_TECHNO_NAME=/usr/local/alliance/etc/cmos.rds

Ejecutaremos S2R en el trazado simbolico del layout de nuestro mux:

% s2r -v muxoor muxcore

@@@@

@ @@

@@ @@

@@@@@@ @@@ @@ @@@ @@@

@@ @ @ @@ @@@ @@

@@@ @ @@ @@

@@@@ @ @@

@@@@ @ @@

@ @@@ @ @ @@

@@ @@ @@@@@@ @@

@ @@@@@ @@@@@@@ @@@@

Symbolic to Real layout converter

Alliance CAD System 5.0 20040928, s2r 5.0



o loading technology file : /usr/local/alliance/etc/cmos.rds

o loading all level of symbolic layout : muxoor

o removing symbolic data structure

o layout post-treating

with top connectors,

with sub connectors,

with signal names,

without scotch.

--> post-treating model ao2o22_x2

rectangle merging :

--> post-treating model inv_x2

rectangle merging :

--> post-treating model tie_x0

rectangle merging :

--> post-treating model muxoor

ring flattenning :

rectangle merging :

o saving muxcore.cif

o memory allocation informations

--> required rectangles = 0 really allocated = 0

--> Number of allocated bytes: 55448

Luego usamos DREAL para ver el archivo del layout real generado muxcore (la tecnologıa ofrecida porAlliance no es realmente una tecnologıa de 0.35 um, pero es util para el ejemplo que estamos viendo). Recuerdeque DREAL requiere un entorno X11, usamos el siguiente comando para ejecutar DREAL:

% dreal -l muxcore

La figura 1.16 muestra el layout real correspondiente.


Figura 1.16: Layout real de nuestro mux mostrado por DREAL.

1.7. DRUC

DRUC (Design RUle Checker) es el verificador de reglas de diseno en VLSI parametrizado de Alliance.Las reglas que usa estan definidas por la variable de entorno RDS TECHNO NAME. DRUC aplana todala jerarquıa del diseno para verificar si hay alguna violacion a alguna regla de diseno especıfica, por lo que esnecesario que las celdas instantaneas estan en el directorio actual. Usemos DRUC en nuestro archivo de disenomuxoor.ap para verificarlo:

% druc -v muxoor

@@@@@@@ @@@@@@@ @@@@ @

@@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @

@@ @@ @@ @@ @@@ @@@@ @@ @

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@@@@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @

@@ @@ @@ @@ @@ @@@ @@ @@

@@@@@@@ @@@@@ @@@ @@@@ @@ @@@@

Design Rule Checker

Alliance CAD System 5.0 20040928, druc 5.0



Flatten DRC on: muxoor

Delete MBK figure : muxoor

Load Flatten Rules : /usr/local/alliance/etc/cmos.rds

layer RDS_NWELL 4.;

layer RDS_NTIE 2.;

....intermediate output has been deleted for space reasons.

fin regles

Unify : muxoor

Create Ring : muxoor_rng

Merge Errorfiles:

Merge Error Instances:

instructionCourante : 56

End DRC on: muxoor

Saving the Error file figure

Done

0

File: muxoor.drc is empty: no errors detected.

Como podra notar de esta salida, no se han detectado errores. Ademas el layout generado por OCP y NEROno contiene violaciones a las reglas de diseno especificadas en el archivo cmos.rds.

Las opciones disponibles para DRUC se muestran en la Tabla 1.9. La opcion -h genera muchos archivos

1.8. FLATBEH 37

intermedios pero no hay documentacion sobre su uso.

Cuadro 1.9: Opciones Disponibles para la herramienta DRUC.

Opcion Descripcion-v Modo Verbose activo. Cada paso de el DRC es la salida en la salida estandar

-h Chequeo de la regla de diseno jerarquica. Genera varios archivos localmente, a ser usadosen invocaciones futuras de druc.

1.8. FlatBeh

La herramienta FlatBeh (Flattens to Behavioral) genera una descripcion funcional de una descripcionestructural. Puede usarse para verificar si la descripcion obtenida en el proceso de sıntesis de un diseno escorrecta. Aplana la descripcion estructural del diseno de destino hasta los componentes funcionales. Luego, usaaquellas descripciones para crear descripciones funcionales del diseno final. Esta herramienta se ejecuta usandoel siguiente comando:

flatbeh root_structural_file [ output_file ]

Esta herramiente no tiene opciones. Sus parametros son solo la raiz del diseno estructural y el nombre del archivode salida. Debemos verificar que MBK CATA LIB se fije a la ruta donde se den las descripciones del diseno.MBK IN LO debe ser fijado a vst. Tambien, en caso de necesitarse, podemos fijar MBK CATAL NAMEal archivo (normalmente CATAL) que enliste los archivos de las descripciones funcionales donde FlatBeh debaparar el aplanamiento del diseno estructural. Usemos la herramienta en nuestro diseno generado por BOOG,muxoo.vst.

% flatbeh mux_oo mux_oo

@@@@@@@@@ @@@@ @@@@@@@ @@@

@@ @ @@ @ @@ @@ @@

@@ @ @@ @@ @@ @@ @@

@@ @@ @@@@ @@ @@ @@ @@@@@ @@ @@@

@@ @ @@ @@ @ @@@@@@@@ @@ @@ @ @ @@@ @@

@@@@@@ @@ @@ @@ @@ @@@@@@ @@ @@ @@ @@

@@ @ @@ @@@@@ @@ @@ @@ @@@@@@@@@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @@ @ @@ @@

@@ @@ @@ @@@ @@ @ @@ @@ @@ @@ @@ @@

@@@@@@ @@@@@@ @@@@ @@ @@@@ @@@@@@@@ @@@@ @@@@ @@@@

a netlist abstractor

Alliance CAD System 5.0 20040928, flatbeh 5.0 [2000/11/01]


Author(s): Fran?ois DONNET, Huu Nghia VUONG


========================= Environnement =========================

MBK_WORK_LIB = .

MBK_CATA_LIB = .:/usr/local/alliance/cells/sxlib:/usr/local/alliance/cells/dp_sxlib

:/usr/local/alliance/cells/rflib:/usr/local/alliance/cells/romlib:/usr/local/alliance/cells/ramlib

:/usr/local/alliance/cells/padlib

MBK_CATAL_NAME = CATAL

============================== Files ==============================

Netlist file = mux_oo.vst

Output file = mux_oo.vbe

===================================================================

Loading ’./mux_oo.vst’

flattening figure mux_oo

loading inv_x2

loading ao2o22_x2

Restoring array’s orders

BEH : Saving ’mux_oo’ in a vhdl file (vbe)


Podemos probar este circuito con ASIMUT usando una version modificada de mux in.pat (muxoo in.pat).

-- terminals of the mux circuit

in vdd B;

in vss B;

in c B;

in a B;

in b B;

out q B;

-- time interval description of the input values and expected output

begin

<0 ns> mux_test : 10 000 ?0;

<+1 ns> notc_nota_notb : 10 000 ?0;

<+1 ns> notc_nota_b : 10 001 ?1;

<+1 ns> : 10 001 ?1;

<+1 ns> notc_a_notb : 10 010 ?0;

<+1 ns> : 10 010 ?0;

<+1 ns> notc_a_b : 10 011 ?1;

<+1 ns> : 10 011 ?1;

<+1 ns> c_nota_notb : 10 100 ?0;

<+1 ns> : 10 100 ?0;

<+1 ns> c_nota_b : 10 101 ?0;

<+1 ns> : 10 101 ?0;

<+1 ns> c_a_notb : 10 110 ?1;

<+1 ns> : 10 110 ?1;

<+1 ns> c_a_b : 10 111 ?1;

<+1 ns> : 10 111 ?1;

end;

Podemos usar este archivo como entrada para ASIMUT:

% asimut -b mux_oo muxoo_in muxoo_out

@ @@@@ @ @ @@@@@@@@@@

@ @ @@ @@@ @ @@ @

@@@ @@ @ @ @ @@ @

@@@ @@@ @@@ @@ @@@ @@@ @@@@ @@

@ @@ @@@@ @@@@ @@@ @@ @@ @@ @@ @@

@ @@ @@@@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@ @ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @ @@ @@ @@ @@ @@ @@@ @@

@@@@ @@@@ @ @@@@ @@@@@@ @@@@ @@@ @@@ @@@@ @@ @@@@@@

A SIMUlation Tool





initializing ...

searching ‘mux_oo‘ ...

BEH : Compiling ‘mux_oo.vbe‘ (Behaviour) ...

making GEX ...

searching pattern file : ‘muxoo_in‘ ...

restoring ...

linking ...

executing ...

















1.9. FLATLO 39

Verificamos de esta manera que la descripcion funcional generada tambien es correcta.

1.9. FLATLO

La herramienta FLATLO (FLATtens LOgical) inserta un netlist jerarquico y lo aplana hasta cierto nivel,ya sea en formato vst o formato logico Alliance al. El formato general para usar esta herramienta es:

% flatlo [option] logical_figure [instance] output_name

Las opciones disponibles para FLATLO se muestran en la Tabla 1.10. Si la instance es indicada entonces esaplanada en la descripcion logica.

Cuadro 1.10: Opciones Disponibles para la herramienta FLATLO.

Opcion Descripcion-r Aplana el archivo principal a el catalogo.

-t Aplana el archivo principal a un nivel de transis-tor.

1.10. FLATPH

La herramienta FLATPH (FLATtens PHysical) aplana un layout simbolico y jerarquico hasta cierto nivel.La herramienta se usa con el siguiente comando:

% flatph [option] logical_figure [instance] output_name

Las opciones disponibles se muestran en la Tabla 1.11. Si la instance es indicada entonces es aplanada en ladescripcion fısica.

Cuadro 1.11: Opciones Disponibles para la herramienta FLATPH.

Opcion Descripcion-r Flattens the target file to the catalog.-t Flattens the target file to the transistor level.

1.11. FMI

La herramienta FMI (Finite state machine Minimizer) toma una descripcion FSM (archivo .fsm) y lominimiza a un FSM equivalente reducido (en numero de estados). Usamos esta herramienta mediante el siguientecomando:

fmi [-V] input_file output_file

Las opciones disponibles para FMI se muestran en la Tabla 1.12. Apliquemos este ejemplo a la FSM que

Cuadro 1.12: Opciones Disponibles para la herramienta FMI.

Opcion Descripcion-V Verbose mode. Each step of the minimization is displayed.


generamos en el ejemplo usando la herramienta B2F:

% fmi -V rwgraph rwmin

@@@@@@@@@ @@@ @@@ @@@@@@

@@ @ @@ @@ @@

@@ @ @@@ @@@ @@

@@ @@@ @@@ @@

@@ @ @ @@ @ @@ @@

@@@@@@ @ @@ @ @@ @@

@@ @ @ @@@ @@ @@

@@ @ @@ @@ @@

@@ @ @ @@ @@

@@ @ @@ @@

@@@@@@ @@@ @@@@ @@@@@@

FSM Minimization

Alliance CAD System 5.0 20040928, fmi 5.0


Author(s): Fr?d?ric P?trot, Ludovic Jacomme

Contributor(s): Jean-Marie Alexandre


--> Run FSM Compiler

--> Compile file rwgraph

--> Build Binay Decision Diagrams

--> Identify equivalent states

--> Initial number states : 4

--> Number of deleted states : 1

--> Save file rwmin

Como puede notarse de la salida de arriba, un estado ha sido borrado, ahora tenemos el siguiente FSM:

-- DATE : Thu Jan 27 23:56:30 2005

ENTITY rwmin IS

PORT

(vss : IN BIT;

vdd : IN BIT;

busy : OUT BIT;

ne : IN BIT;

rw : IN BIT;

start : IN BIT;

clk : IN BIT);

END rwmin;

ARCHITECTURE FSM OF rwmin IS

TYPE STATE_TYPE IS ( s0,s3,s2 );

SIGNAL CURRENT_STATE, NEXT_STATE: STATE_TYPE;

--PRAGMA FIRST_STATE s0

--PRAGMA CLOCK clk

BEGIN

PROCESS( CURRENT_STATE, vss, vdd, ne, rw, start)

BEGIN

CASE CURRENT_STATE IS

WHEN s3 =>

IF (( ’1’) = ’1’) THEN NEXT_STATE <= s0; END IF;

busy <= ’1’;

WHEN s2 =>

IF (( ne) = ’1’) THEN NEXT_STATE <= s3;

ELSE NEXT_STATE <= s2; END IF;

busy <= ’1’;

WHEN s0 =>

IF (( ((start AND NOT(rw)) OR (NOT(start AND NOT(rw)) AND (start AND rw)))) = ’1’)

THEN NEXT_STATE <= s2;

ELSE NEXT_STATE <= s0; END IF;

busy <= ’0’;

END CASE;

END PROCESS;

PROCESS( clk )

BEGIN

IF ( (NOT((clk’STABLE)) AND clk) )

THEN CURRENT_STATE <= NEXT_STATE;

END IF;

END PROCESS;

END;

1.12. FSP 41

1.12. FSP

La herramienta FSP (Finite State machine Proof)verifica la equivalencia de 2 descripciones FSM. Lo haceusando formalmente un algoritmo basado en productos. Usamos esta herramienta mediante el siguiente comando:

% fsp [-V] format1 format2 file1 file2

Las opciones disponibles para FSP se muestran en la Tabla 1.13. Apliquemos la herramienta en la descripcion

Cuadro 1.13: Opciones Disponibles para la herramienta FSP.

Opcion Descripcion-V Modo Verbose. Cada paso de el formal proof es desplegado.

FSM que obtuvimos en los ejemplos usando B2F y FMI:

% fsp -V fsm fsm rwgraph rwmin

@@@@@@@@@ @@@@ @ @@@@@@@

@@ @ @ @@ @@ @@

@@ @ @@ @ @@ @@

@@ @@@ @@ @@

@@ @ @@@@ @@ @@

@@@@@@ @@@@ @@@@@

@@ @ @@@ @@

@@ @ @@ @@

@@ @@ @@ @@

@@ @@@ @ @@

@@@@@@ @ @@@@ @@@@@@

FSM formal Proof

Alliance CAD System 5.0 20040928, fsp 5.0





--> Compile file rwgraph


--> Compile file rwmin

--> Formal proof between "rwgraph.fsm" and "rwmin.fsm"

==> "rwgraph.fsm" and "rwmin.fsm" are identicals

Como podemos observar, la descripcion original obtenida con B2F y la obtenida con FMI son identicas.

1.13. GENPAT

GENPAT (GENerator of PATterns) es una herramienta que se usa para crear un archivo de patrones deentrada para ASIMUT. Es una interfase (conjunto de instrucciones) en C que facilita la creacion de patrones deentrada. Esta herramienta toma como entrada un archivo en C describiendo los patrones de entrada y generacomo salida un archivo .pat. Como en otras herramientas, la extension del archivo no se da en el comando deentrada. Como explicamos en la seccion que describıa ASIMUT, un archivo .pat puede ser facilmente editadopara circuitos pequenos, pero se vuelve complicado para disenos complejos. GENPAT trata de automatizaresta labor de edicion. Usamos GENPAT mediante el siguiente comando:

% genpat [-v] [-k] [file]

Las opciones disponibles para GENPAT se muestran en la Tabla 1.14: Probaremos GENPAT generando los

Cuadro 1.14: Opciones Disponibles para la herramienta GENPAT.

Opcion Descripcion-v Modo Verbose.

-k Mantiene el ejecutable y la compilacion Makefile despues de haber culmi-nado.


patrones de entrada de nuestro circuito multiplexor usando el siguiente archivo muxgp.c:

#include <stdio.h>

#include <genpat.h>

/*Define the number of test patterns */

#define MAXCYCLE 8

/* Function to allocate a memory buffer, convert the first parameter into a string

and return the pointer to it.*/

char *inttostr (int integer, int len)

{

char *str;

str = (char *)mbkalloc(len*sizeof(char)+1);

sprintf(str, "%.32d", integer);

return(&str[32-len]);

}

/* Apply power to the circuit */

void power (void)

{

AFFECT (inttostr (0, 32), "Vdd", "0b1");

AFFECT (inttostr (0, 32), "Vss", "0b0");

}

/*Generate the patterns for the mux */

void patterns (void)

{

int i,a,b,c,q;

for (i=0; i<MAXCYCLE; i++)

{

LABEL ( "pat" );

if (i%8 < 4) c = 0; else c = 1;

AFFECT(inttostr(i, 32), "c", inttostr(c,32));

if (i%4 < 2) a = 0; else a = 1;

AFFECT(inttostr(i, 32), "a", inttostr(a,32));

if(i%2 == 0) b = 0; else b = 1;

AFFECT(inttostr(i, 32), "b", inttostr(b, 32));

if(c == 1) q = a; else q = b;

AFFECT(inttostr(i, 32), "q", inttostr(q, 32));

}

}

int main(void)

{

/* Declares the name of the pattern file */

DEF_GENPAT ("muxgp_in");

/* Declare the name, format and type of each of the inputs/outputs */

DECLAR ( "Vdd", ":0", "B", IN, "", "");

DECLAR ( "Vss", ":5", "B", IN, "", "");

DECLAR ( "a", ":2", "B", IN, "", "");

DECLAR ( "b", ":2", "B", IN, "", "");

DECLAR ( "c", ":2", "B", IN, "", "");

DECLAR ( "q", ":2", "B", OUT, "", "");

/* Generate the patterns */

power();

patterns();

/* Save the pattern file */

SAV_GENPAT();

/* Return success code */

return(0);

}

Podemos verificar si el archivo de patrones de entrada es correcto viendolo con XPAT. La salida se muestra enla figura 1.17. Existen diferentes funciones que pueden usarse en los archivos de entrada de GENPAT, esperamosdescribir alguno de ellos en algun anexo del libro.

1.14. GRAAL

GRAAL es un editor de layout simbolico jerarquico de Alliance. Es una herramienta grafica que requiere lainstalacion de X11 y de MOTIF. Las funcionalidades de GRAAL pueden ser accesadas mediante sus 7 menus.

1.15. K2F 43

Figura 1.17: El archivo muxgp inpat mostrado mediante XPAT.

GRAAL es ejecutado con un comando como el que se muestra:

% graal [-l file_name] [-scale n] [-debug] [-xor] [-install] [-force]

Las opciones disponibles se muestran en la Tabla 1.15: Ya hemos observado una aplicacion de GRAAL en el

Cuadro 1.15: Opciones Disponibles para la herramienta GRAAL.

Opcion Descripcion-l filename Cargar el nombre de archivo (con o sin extension)

-scale nEscalar el nombre de archivo (el rango de n no es explicado en las pagina principalde graal)

-debug-xor Dos metodos de cursor grafico pueden ser usados, inversor (defecto) o xor.-install Suiche a un mapa de color privado.-force Esta opcion fuerza a que todos los objetos graficos sean desplegados.

fijado y trazado de nuestro multiplexor, de manera que no lo colocamos aquı.

1.15. K2F

K2F es una herramienta de linea de comando de Alliance que traduce una descripcion FSM en formatoAlliance (.fsm) a formato Berkeley (.kiss2) o viceversa. Se ejecuta mediante el siguiente comando:

k2f In_format Out_format Input_name [ Output_name ]

Si “Output name”no es dado, el “ Input name”sera usado. No hay opciones disponibles en K2F. el FormatoKISS (Sep It Simple Stupid) puede ser usado para simplificar una descripcion FSM con las herramientas SIS oVIS desarrolladas por la Universidad de California en Berkeley. Probemos esta herramienta en el ejemplo usado


para explicar la herramienta B2F:

% k2f fsm kiss2 rwgraph

@@@@ @@@@ @@@@ @@@@@@@@@

@@ @ @ @@ @@ @

@@ @ @@ @@ @@ @

@@ @ @@@ @@ @@

@@ @@ @ @@ @@ @

@@ @ @@ @ @@@@@@

@@@ @@ @ @@ @

@@ @@ @ @@

@@ @@ @ @ @@

@@ @@ @@@@@@ @@

@@@@ @@@@ @@@@@@@ @@@@@@

Translator Kiss <-> FSM Format

Alliance CAD System 5.0 20040928, k2f 5.0




--> Translate figure rwgraph

<-- done

Obtendremos el siguiente archivo rwgraph.kiss2:

.i 5

.o 1

.s 4

.r s0

.p 8

10--- s0 s2 0

11--- s0 s1 0

0---- s0 s0 0

--1-- s1 s3 1

--0-- s1 s1 1

--1-- s2 s3 1

--0-- s2 s2 1

----- s3 s0 1

.e

Usted puede tratar de simplificar esta descripcion con cualquiera de las herramientas indicadas de Berkeley (silas ha instalado en su Sistema).

1.16. L2P

La herramienta de lınea de comando, L2P, crea un archivo PostScript (.ps) de un archivo de entrada delayout real o simbolico. Las opciones disponibles para L2P se muestran en la Tabla 1.16.:

Un diccionario PostScript es un conjunto de macros usados durante la interpretacion de un archivo PostS-cript. Modificando los macros en los diccionarios PostScript internos de L2P usted puede controlar que capamostrar, como llenar los rectangulos, especificar los colores de los rectangulos y muchas otras cosas. El PostScriptgenerado esta principalmente formado por un diccionario y ordenes para dibujar rectangulos. Si no se indicanopciones, L2P generara un archivo de salida Standard. Generalmente esto basta para disenos con celdas, pero

1.16. L2P 45

Cuadro 1.16: Opciones Disponibles para la herramienta L2P.

Opcion Descripcion

-colorGenera un archivo a color PostScript. El valor por defecto da un archivoPostScript en blanco y negro.

-drawingsize=w × h

Especifica en area de dibujo en centenas de pulgadas. Por defecto setiene, ancho = 725 y altura = 1068 para papel A4. Si el tamano deldibujo es mucho mayor que el area del papel luego el dibujo sera dividoen varias paginas.

-fA3 El dibujo es hecho en un papel de formato A3.-fLETTER El dibujo es hecho en un papel de formato CARTA.-fLEGAL El dibujo es hecho en un papel de formato LEGAL.-givebwdict Give the Black & White internal PostScript dictionary. Vease abajo.

-givecolordict

Esta opcion tiene que ser unica en la lınea de comando. cuando esusado como ’l2p -givebwdict’, l2p ofrece sobre la salida estandar PostS-cript diccionario en blanco y negro. Ud., puede obtener el diccionarioestandard por una lınea de la forma ’l2p -givecolordict > dict.ps’. Lue-go puede editarla, con la finalidad de reusarla con l2p, vea la opcion’-usedict’ mostrada abajo.

-help Te muestra la pagina principal que te explica como usar l2p.

-noheaderPreviene las informaciones redundantes o de borde, como el nombre decelda y la posicion de la pagina en el dibujo a ser impresa.

-papersize=x× y × w × hEspecifica el area del papel en centenas de pulgada. Por defecto se usa50x50x726x1069 para papel a4 (x y y puntos abajo en la izquierda,valores de ancho y altura respectivamente).

-pages=x pages× y pages

Especifica el area de dibujo en paginas. Esto puede ser util en lugar detener que calcular el tamano en centenas de pulgadas del dibujo paradarnos el numero de paginas. Este se encarga de arreglar el tamano delpapel en caso de tener un encabezado.

-tsize=s Tamanos disponibles:6,8,10,12,14. El valor por defecto es 8.-nrname Sera desplegado sin nombre.-ncname El nombre de los conectores externos no seran mostrados..-nrfname Los nombres de referencia no seran mostrados.-niname The instances’s names won’t be displayed.-nsname Los nombres de los segmentos no seran mostrados.

-mfeedManual alimentado. Si se fija, este informa la impresora que sera usadapor el usuario para cada impresion.

-realUsa archivos reales (cif, gds). Por defecto, usa un archivo de arreglosimboolico (ap, cp).

-resol=x

Fija la resolucian del archivo en puntos por pulgadas (dpi) y ademaslimita el tamano de el PostScript. Cada rectangulo del cual el ancho yaltura son mas pequenas que la resolucion no seran impresas. El valorpor defecto es de 72dpi. It should only be changed in one wants to pro-duce a plot of several meters. Usualmente debe proveer de un archivode PostScript de tamano de papel A4 con una resolucion superior a los72dpi. Pudiendo incrementar ese valor hasta 1000dpi pero debe asegu-rarse de que el tamano de el archivo probablemente sera mas grandede 44Mb SyQuest cartucho que es usado en PAO para el intercambiode archivos de dato.

-rflattencatalAplana la celda a el nivel de catalogo. Tenga cuidado ya que esta opcionrequiere de mucha memoria.

-rflattentransAplana la celda al nivel de transistor antes de ser impreso. Tenga cui-dado ya que esta opcion requiere de mucha memoria.

-rotateRotar la celda 90 grados. Esto es util si usted tiene un ancho de celdauna celda amplia, y usted desea imprimirla modo de relieve.

-scale=f.f

Fuerza la celda a ser impresa con cierta escala (un numero de pun-to flotante). Esto es muy util cuando usted esta imprimienmdo unabiblioteca completa de celdas y usted desea que todas las celdas seanimpresas a la misma escala. Ud., puede encontrar a que escala una celdafue impresa al mirar al inicio de el archivo: ’head n1 y-1x1.ps’ le mos-trara un comentario del PostScript comenzado en ’%SCALE=3.78435’por ejemplo.

-usedict=filename

El archivo de salida Postcript contiene un diccionario Postcript de ma-cros. Hay dos diccionarios estandard usados por l2p. Uno para blancoy negro y otro para impresiones a color. Esto te permite usar un dic-cionario PostScript diferente a los dos internamente codificados hacial2p.


no para circuitos grandes. Vamos a generar el archivo PostScript de nuestro diseno de multiplexor:

% l2p muxoor

@@@@@@ @@@@ @@@@@@@

@@ @ @@ @@ @@

@@ @@ @@ @@ @@

@@ @@@ @@ @@ @@

@@ @ @@ @@ @@

@@ @ @@@@@

@@ @ @@

@@ @ @@

@@ @ @ @ @@

@@ @ @@@@@@ @@

@@@@@@@@@@ @@@@@@@ @@@@@@

(L)ayout to(2) (P)aper: A tool for PostScript plots

Alliance CAD System 5.0 20040928, l2p 5.0



- Loading technology file : /usr/local/alliance/etc/cmos.rds

- Loading mbk figure: muxoor.ap

- Saving PostScript figure: muxoor

81 masks, BBox=(x=-4,y=0,w=288,h=200)

Paper=(0.500,0.250) 7.400 inch(es) wide, 11.190 inch(es) tall

Drawing= 7.389 inch(es) wide, 10.931 inch(es) tall

width first, SCALE=1.847222, resol=100dpi Centering:(0,113)

One page PS(36,36,532,787) RDS(-4,0,288,426)

- All done.

Esto producira una vista en blanco y negro del diseno del multiplexor, tal como muestra la figura 1.18.:

Figura 1.18: Snapshot del archivo Postcript generado mediante L2P (ubicado por default).

1.17. LOON 47

1.17. LOON

LOON (Light Optimizing On Nets) es una herramienta de linea de comando de Alliance que se usa parael proceso de sıntesis despues de aplicar BOOM y BOOG al diseno. Su netlist de entrada puede ser jerarquico(puede ser aplanado si es necesario). LOON se usa mediante el siguiente comando:

% loon loon <input_file> <output_file> [-l <lax_file>] [-x <xsch_mode>] [-m <optim_mode>]

Las opciones disponibles para LOON se muestran en la Tabla 1.17.: Aplicaremos LOON al diseno del multiplexor

Cuadro 1.17: Opciones Disponibles para la herramienta LOON.

Opcion Descripcion-h Modo de ayuda. Despliega posibles usos de loon.

-o outfile Sobre escribe el archivo fuente si no hay ningun output file. Esto puede ser util si ustedno desea varios archivos netlist.

-m optmode

Modo de Optimizacion. Puede ser definido en un archivo lax, este es un acceso directopara definirlo en la lınea de comando. El modo numerico toma un valor entre 0 y 4 eindica el tipo de optimizacion que se desea. Si es 0, el area del circuito mejorara. Porotro lado, 4 mejorara los retardos del circuito. 2 es un valor medio para la optimizacion.

-x xschmode

Genera un archivo ’.xsc’. El cual es un mapa para las senales contenidas en el output file.Este archivo es usado por xsch cuando se observa el netlist. Al escoger el nivel 0 o 1para xsch mode, usted puede colorear las direcciones crıticas o con todas las senales conun retardo gradual.

-l laxfile Otra manera de indicar explicitamente el nombre del archivo de parametro LAX.

que optimizamos con BOOM y BOOG:

% loon mux_oo mux_ool -x 0 -m 0

@@@@@@ @@@ @@@

@@ @@ @

@@ @@@ @

@@ @@@ @@@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @ @@ @@ @@ @@ @ @@@

@@ @ @@ @@ @@ @@ @ @@

@@@@@@@@@@ @@@ @@@ @@@ @@

Local optimization on Nets

Alliance CAD System 5.0 20040928, loon 5.0 [2003/12/07]




MBK_IN_LO : vst

MBK_OUT_LO : vst



100% area optimization

Reading file ’mux_oo.vst’...


Capacitances on file ’mux_oo.vst’...

Delays on file ’mux_oo.vst’...657 ps

Area on file ’mux_oo.vst’...3000 lamda? (with over-cell routing)

Details... ao2o22_x2: 1 (75%)

inv_x2: 1 (25%)

Total: 2

Worst RC on file ’mux_oo.vst’...16 ps

Improving RC on critical path for file ’mux_ool.vst’...643 ps

Improving all RC for file ’mux_ool.vst’...

Worst RC on file ’mux_ool.vst’...16 ps

Area on file ’mux_ool.vst’...3000 lamda? (with over-cell routing)

Details... ao2o22_x2: 1 (75%)

inv_x2: 1 (25%)

Total: 2

Critical path (no warranty)...643 ps from ’c’ to ’q’

Saving file ’mux_ool.vst’...

Saving critical path in xsch color file ’mux_ool.xsc’...

End of loon...


Claro que, en este caso es un diseno muy simple, no habran cambios en la descripcion que obtuvimos conBOOG, ya que sus celdas no cambiaron.

1.18. LVX

La herramienta LVX (Logical Versus eXtracted) de Alliance nos permite comparar 2 netlist a nivel depuertas o de bloques. Esta herramienta se usa para comparar una especificacion (netlist logico) con el netlistextraido de un netlist fısico. Usando esta herramienta podemos verificar si la ubicacion y trazado de un disenologico se ha hecho correctamente. Ya que esta es una herramienta jerarquica a nivel 1, debemos usar COUGARpara extraer un netlist para comparar. Usamos LVX mediante el siguiente comando:

lvx format1 format2 filename1 filename2 [ -a ] [ -o ] [ -f ]

Las opciones disponibles para LVX se muestran en la Tabla 1.18.: Si la opcion -f es usada, los 2 net-

Cuadro 1.18: Opciones Disponibles para la herramienta LVX Tool.

Opcion Descripcion

-a

Algunos enrutadores generan un layout con diversos conectores fısicos para enegizar oaterrar(VDD or VSS). Si esos conectores no son internamentes conectados, ellos tendran di-ferentes nombres indexados (VDD1 , VDD2 etc...) en el netlist extraıdo. Es posible mejorar lareduccion de sobre aquellos conectores de energia y tierra antes de la comparacion usando laopcion -a. Despues de la reduccion cada instacia contiene solo un conector VDD y un conectorVSS con la figura principal.

-o

En este caso lvx produce un netlis modificado (salvado con el mismo nombre del archivo 2), elcual es una copia de netlist 2 con conectores ordenados. Los conectores terminales e instanciason relitatados en el orden de los modelos en netlist 1. El netlist salvado es hecho con el formatoMBK OUT LO(1), asi que el usuario tiene que fijar esta variable antes de correr el lvx. Si el nolo hace se usa el valor por defecto y netlist 1 podria perderse si el nombre del archivo es identicoy el formato de entrada el mismo al formato de salida. Si se usa la opcion -a luego la netlistsalvada es la netlist reducida con solo un VDD y un VSS.

-fThe two netlists are flattened to the leaf cells contained in the catalog file. Usually the extractednetlist is a flatten netlist, while the logical one can be a hierarchical net-list.

lists se aplanaran usando los valores de las variables de entorno MBK CATA LIB y MBK WORK LIB.MBK CATA LIB indica la ruta al archivo de catalogos de la librerıa de celdas, y MBK WORK LIB la rutadonde el archivo indicado por MBK CATA LIB indica al usuario los bloques que no deben ser aplanados.

LVX compara los nombres de conectores externos, nombres de instancias, nombres de senales conectadas odesconectadas, en ese orden. Si los nombres del conector o de la instancia no coinciden, LVX se detiene con unerror. No comparara las senales si los nombres del terminal y de la instancia difieren.

Ya hemos visto un ejemplo de aplicacion de LVX, asi que no lo haremos de nuevo.

1.19. MOKA

La herramienta MOKA (Model checKer Ancestro) de Alliance permite verificar una descripcion FSM o RTLusando una lista de formulas descritas en un archivo CTL (Logica de Control Temporal). MOKA tiene algunasrestricciones. Necesita que todos los registros en la descripcion funcional posean el mismo reloj y no permite eluso de triestados o buses multiplexados (no se admite mux bit o Wor bit). Usamos MOKA mediante el siguientecomando:

% moka [-VDB] fsmfile ctlfile

Las opciones disponibles para MOKA se muestran en la Tabla 1.19.: Usaremos MOKA en el ejemplo provisto

Cuadro 1.19: Opciones Disponibles para la herramienta MOKA.

Opcion Descripcion-V Sets verbose mode on.

-DSets debug mode on. Each step of the model checking is detailed on the standard output.In particular all states set are displayed for each CTL sub-expression.

-B The input file is a VHDL description using the Alliance VHDL subset

1.20. NERO 49

para esta herramienta en las paginas del manual. Hemos llamado a los archivos fsm.vhd y fsm.ctl respectiva-mente. Primero convertimos el archivo VHDL en una descripcion funcional usando el siguiente comando:

% vasy -Vao -I vhd fsm

Luego de que la conversion se hizo, ejecutamos MOKA de la siguiente manera:

% moka -VB fsm fsm

@@@ @@@ @@@@ @@@@ @

@@ @@ @@ @ @

@@@ @@@ @@ @ @@@

@@@ @@@ @@@ @@ @ @@@

@ @@ @ @@ @@ @@ @@ @@ @ @@

@ @@ @ @@ @@ @@ @@ @ @@ @ @@

@ @@@ @@ @@ @@ @@@ @@ @ @@

@ @@ @@ @@ @@ @@ @@ @@@@@@@

@ @ @@ @@ @@ @@ @@ @ @@

@ @@ @@ @@ @@ @@ @ @@

@@@ @@@@ @@@ @@@@ @@@@ @@@@ @@@@

MOdel checKer Ancestor

Alliance CAD System 5.0 20040928, moka 5.0




--> Running BEH Compiler

Compiling file fsm

--> Verifying BEH figure

--> Running CTL Compiler

Compiling file fsm

--> Building BDDs

--> Model checking of "fsm"

Checking formula prop1

EX((ack = ’1’))

> states set:

(NOT(a_cs) AND b_cs)

(NOT(a_cs) AND NOT(b_cs)) (first state)


AG((req -> AF(ack)))

> all reachable states


((req = ’1’) AU (ack = ’1’))

> states set:

(a_cs AND b_cs)

(NOT(a_cs) AND b_cs)

(NOT(a_cs) AND NOT(b_cs)) (first state)

<-- done

1.20. NERO

NERO (Negotiating Router) es un simple ruteador o enlazador (router) sobre las celdas provisto por Allianceque puede procesar disenos superiores a las 4K puertas de tamano. Toma como entradas un netlist y unaubicacion para ella. Por defecto asume que los archivos del netlist y de ubicacion tienen el mismo nombre. Elusuario puede indicar mediante una opcion un nombre diferente para el archivo de ubicacion.

Si algun diseno posee un semiperımetro mayor a 800 lambdas, NERO usara routing global”para enlazarlo.Cuando NERO usa routing global”, las redes mas grandes seran trazadas primero usando las capas 3 y 4. Luego,las redes restantes seran trazadas usando las capas que queden disponibles. Cuando routing global”se usa, comomınimo se usan 4 capas para el trazado. Las redes en este caso se trazan de la mas pequena a la mas grande conel mismo algoritmo de trazado. NERO ofrece buenos resultados para netlists pequenos (menos de 500 puertas)y puede no converger cuando se manejan netlist complejos. Usamos NERO mediante el siguiente comando:

% nero [options] netlist layout

Los nombres del netlist y del archivo del layout deben ser diferentes sino se sobrescribira sobre el primero.Las opciones disponibles para NERO se muestran en la Tabla 1.20.: Ya hemos mostrado un ejemplo de NERO,por lo que no lo repetiremos aca. Otros ejemplos seran dados en los siguientes capıtulos mostrando ejemplos dediseno mas complejos.


Cuadro 1.20: Opciones Disponibles para la herramienta NERO.

Opcion Descripcion-h, –help Prints help.-v, –verbose Verbose mode.-V, –very-verbose Unbearably verbose.-c, –core-dump Allows core dump in case of a crash.

-2, -3, -4, -5, -6 Sets the numbers of layers used for routing. The default for small designs is 2and 4 for big ones.

-L, –local Turns off the global routing stage, whatever the size of the design is. Be warnedthat this will enormously slow down the routing process.

-G, –global Turns on the global routing regardless of the size of the design.-p file, –place file Specifies a name for the placement file different from the netlist name.

1.21. OCP

La herramienta OCP se usa en Alliance para la ubicacion de componentes o celdas. Usa como entradaun netlist de celdas Standard. El formato del netlist puede ser formato VHDL estructural, EDIF o algunformato interno de Alliance. Este formato es dado por la variable MBK IN LO. Opcionalmente, podemos darel archivo indicando la ubicacion de los conectores (archivos de tipo ioc). Si se usan bloques no estandar en eldiseno, debemos proveer la ubicacion para esos bloques. La salida sera un archivo de layout fısico con celdas yconectores ya colocados. El formato de la salida se define por la variable de entorno MBK OUT PH. UsamosOCP mediante el siguiente comando:

% ocp [options] netlist outputname

Las opciones disponibles para OCP se muestran en la Tabla 1.21.: Usaremos OCP para ubicar el diseno del

Cuadro 1.21: Opciones Disponibles para la herramienta OCP.

Opcion Descripcion

-partial NAME Defines the user defined placement file. It must have an extension equal to thatdefined by MBK IN PH.

-c Will make OCP place the connectors randomly on each side of the abutment box.

-ring

Makes OCP to place the connectors for the ring pad placement tool. The placementis random but only on the north and south side unless the -ioc option is given, inwhich case the constraints given in the NAME.ioc file will be respected, but withlayers suitable for ring. This option is temporary and is provided for the ring padplacement tool.

-ioc NAME The placement of connectors will be done accordingly to what is specified in theNAME.ioc file.

-margin mSets the amount of free area added in percentage of the cells area. The resultingarea will be equal to CELL AREA * (1 + m). By default, the margin value is 0.2(20 %)

-eqmargin Will distribute equitably the margin between cells. By default the largest numberof 2-pitch tie cells is inserted to have the best well and bulk polarity.

-rows NRForces the design to be placed in NR rows. This option will not be used if a definedplacement file is used.

-v Verbose mode.-gnuplot Generates gnuplot files for editing statistics.

multiplexor optimizado mediante LOON (mux ool.vst), pero esta vez OCP tambion ubicara los conectores deldiseno. Ubicando los conectores prepararemos el diseno para ubicar el anillo del pad. En este caso, usamos el

1.22. PROOF 51

siguiente comando:

% ocp -ring mux_ool muxoolpring

@@@ @@@@ @ @@@@@@@

@@ @@ @@ @@ @@ @@

@@ @@ @@ @ @@ @@

@@ @@ @@ @ @@ @@

@@ @@ @@ @@ @@

@@ @@ @@ @@@@@

@@ @@ @@ @@

@@ @@ @@ @@

@@ @@ @@ @ @@

@@ @@ @@ @@ @@

@@@ @@@@ @@@@@@







o No More Mouvement Possible .....


Obtendremos las ubicaciones como muestra la figura 1.19.: Si deseamos, podemos forzar una ubicacion vertical

Figura 1.19: Colocacion orientada del pad del circuito multiplexor usando OCP.

del diseno indicando el numero de filas que queremos usar, pero debemos elegir cuidadosamente el numero defilas para evitar el uso excesivo de celdas en blanco.

1.22. Proof

PROOF es una herramienta de Alliance que compara una descripcion funcional extraida de un layout conla correspondiente descripcion funcional del diseno.

Para extraer una descripcion funcional de un layout necesitamos una herramienta llamada YAGLE que noesta disponible en Alliance. Ahora esta disponible desde Avertec (http://www.avertec.com/). PROOF es usadomediante el siguiente comando:

% proof [-a] [-d] file1 file2

Las opciones disponibles para PROOF se muestran en la Tabla 1.22.: Como un ejemplo del uso de PROOF


Cuadro 1.22: Opciones Disponibles para la herramienta proof.

Opcion Descripcion

-a

This option asks proof to keep the common auxiliary signals. Proof keeps all intermediatesignals that have the same name in both descriptions (A common signal is considered asan input and an output of each description). This option can be useful for descriptionscontaining large equations. It may be used when proof has failed or if you want to debug instep by step mode the two different descriptions.

-dThe program displays errors when the behavioral descriptions are different. Equations aredisplayed when it’s possible.

compararemos la descripcion funcional original de nuestro diseno de multiplexor con la obtenida con BOOM:

% proof -a -d mux mux_o

@@@@@@@ @@@

@@ @@ @ @@

@@ @@ @@ @@

@@ @@ @@@ @@@ @@@ @@@ @@

@@ @@ @@@ @@ @@ @@ @@ @@ @@@@@@@@

@@@@@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@

@@@@@@ @@@@ @@@ @@@ @@@@@@

Formal Proof

Alliance CAD System 5.0 20040928, proof 5.0



================================ Environment ================================

MBK_WORK_LIB = .

MBK_CATA_LIB =.:/usr/local/alliance/cells/sxlib:/usr/local/alliance/cells/dp_sxlib:

/usr/local/alliance/cells/rflib:/usr/local/alliance/cells/romlib:/usr/local/alliance/cells/ramlib:


======================= Files, Options and Parameters =======================

First VHDL file = mux.vbe

Second VHDL file = mux_o.vbe

The common auxiliary signals are kept

Errors are displayed

===============================================================================

Compiling ’mux’ ...

Compiling ’mux_o’ ...

Looking for the common auxiliary signals :

---> final number of nodes = 9(3)

Running Abl2Bdd on ‘mux_o‘

--------------------------------------------------------------------------------

Formal proof with Ordered Binary Decision Diagrams between

’./mux’ and ’./mux_o’

--------------------------------------------------------------------------------

============================== PRIMARY OUTPUT ===============================

============================= AUXILIARY SIGNAL ==============================

============================== REGISTER SIGNAL ==============================

=============================== EXTERNAL BUS =================================

================================ INTERNAL BUS =================================

Formal Proof : OK

pppppppppppppppppppppppprrrrrrrrrrrrooooooooooooooooooooooooooooofffffffffffffff

--------------------------------------------------------------------------------

Como podemos ver, desde esta salida PROOF verifica la equivalencia de las salidas, senales y buses primariosen ese orden. Internamente, PROOF usa un ROBDD (Diagrama de Decision Binaria de Orden Reducido) paraprobar la equivalencia de las 2 descripciones funcionales.

1.23. RING 53

1.23. Ring

RING es un trazador de anillos de pads de Alliance. Se usa mediante el siguiente comando (no poseeopciones):

% ring source result [stat]

Aplicaremos RING a nuestro diseno del multiplexor, pero primero editaremos un archivo .rin describiendo laorientacion de sus entradas y salidas. El archivo es el siguiente:

north(q,c)

south(b,a)

east(p_vssb)

west(p_vddb)

width(vss 50 vdd 80)

El archivo mostrado arriba no es suficiente para usar RING. Tambien debemos proveer un archivo estructuralde nuestro diseno que incluya los pads.

1.24. S2R

S2R (Symbolic to Layout) es una herramienta en Alliance que nos permite traducir nuestro diseno de sımbolosa uno real. Para eso, S2R usa el archivo tecnologico definido por la variable de entorno RDS TECHNO NAME.Si proveemos un archivo tecnologico adecuado, la salida de S2R sera un archivo de layout que puede darsea una fabrica de circuitos integrados (foundry) para la fabricacion del diseno. Durante el diseno con Alliancepodemos tambien colocar y trazar los pads del diseno usando RING. Sin embargo, los pads reales son especificaspara cada fabrica y deben ser disenadas para que coincida con los pads de Alliance. Algo que debe tomarse encuenta es que los pads en Alliance poseen su propia caja de estribo en la coordenada inferior izquierda. Tambiendebemos notar que las celdas de las fabricas tienen una caja de estribo proporcional al paso de rejilla simbolicausada en Alliance. Usamos S2R mediante el siguiente comando:

s2r [-tc1rv] source [result]

Las opciones disponibles para S2R se muestran en la Tabla 1.23.: Determinamos el tipo de archivo de salida

Cuadro 1.23: Opciones Disponibles para la herramienta S2R.

Opcion Descripcion

-tSuppress the denotching phase. s2r performs gap filling, denotching in order to avoid DRCerrors. This operation is time consuming. It is mandatory for the foundry but not reallyuseful for capacitance evaluation.

-c

Deletes connectors and node names at all hierarchy level. Theses objects link the physicalview and the logical view of a chip. If simulation is to be done after physical mapping,connectors must appear, so that the extractors and simulators can use them. This mustnot be used when preparing a final layout for the foundry. For the factory, the top levelconnectors are forbidden, since they do not represent any physical reality.

-1Creates the top level cell with the instances as black boxes. This may be useful for hierar-chical extractors, since the file size may be greatly reduced.

-r Does not replace black boxes. Cells flagged with the G attribute in the catal(5) file will notbe replaced by their equivalent layout loaded from disk.

-v Verbose mode on.

de S2R fijando el tipo de archivo apropiado mediante la variable de entorno RDS OUT. El tipo por defecto escif, pero podemos fijarlo a gds. El nombre del catalogo del archivo usado en la sustitucion de pads es fijado porla variable MBK CATAL NAME. La variable RDS IN se usa para definir el formato de las celdas usadas en elproceso de sustitucion. El formato del layout simbolico se determina con la variable MBK IN PH.

1.25. SCAPIN

La herramienta SCAPIN (SCAn Path INsertion) se usa en Alliance para insertar una ruta de exploracionen el netlist de un diseno.

scapin [-VRB] [-P file] infile pathfile outfile


La ruta de exploracion insertada contendra todos los registros especificados dentro del archivo senalado porel archivo de ruta (.path). SCAPIN tambien anadira tres nuevos conectores al netlist: scan in, scan out yscan test. En algunos casos, tambien se anadira un buffer de salida al conector scan out. Las opciones disponiblespara SCAPIN se muestran en la Tabla 1.24.: Los formatos de los archivos de entrada y salida se determinan

Cuadro 1.24: Opciones Disponibles para la herramienta SCAPIN.

Opcion Descripcion-V Verbose mode on.

-RAll registers of the scan path are replaced by an equivalent cannable register cell (calledreg-mux). (With the default option a simple multiplexor is added just before all registers ofthe scan path).

-B Adds an output buffer before the output connector scan out.

-P fileSpecifies a parameter file (with extention .scapin) containing the properties of all cells neededfor the scan path insertion.

mediante las variables MBK IN LO y MBK OUT LO respectivamente. Tambien debemos verificar la variableSCAN PARAM NAME que determina la ubicacion del archivo de parametro .scapin (Contiene las propiedades(nombre de puertos, nombre de modelos, etc.) de las celdas necesarias en la insercion de la ruta de exploracion).

1.26. SYF

La herramienta SYF (SYnthesizer of Finite state machines) de Alliance se usa para generar descripcionesde flujos de datos en VHDL desde una descripcion FSM en VHDL. Esta descripcion puede utilizar una pilainterna. Podemos generar con esta herramienta, FSM del tipo Mealy y Moore con registros de salida si se desea.En el tipo Moore podemos generar una implementacion optimizada en tiempo que emule una ROM con unmicrosecuenciador. Podemos tambien implementar la exploracion-ruta de los registros correspondientes.

syf -a|j|m|u|o|r [-CDEOPRSTV] input [output]

Las opciones disponibles en SYP se muestran en la Tabla 1.25.: Usaremos SYF en el ejemplo del mipsR3000

Cuadro 1.25: Opciones Disponibles para la herramienta SYF.

Opcion Descripcion-a Uses .Asp.as encoding algorithm.-j Uses ”Jedi.as encoding algorithm.-m Uses ”Mustang.as encoding algorithm.

-uUses an encoding given by user through input.enc file. In this file, a line started by a #character is a comment. A valid line contains one state name followed by its hexadecimalcode.

-o Uses the one hot encoding algorithm.-r Uses distinct random numbers for state encoding.-C Checks the transition’s consistency.-D With this option syf doesn’t optimize unused, i.e Don’t Care, codes.

-ESaves the encoding result in the output.enc. This file has the same syntax as input.enc filewhich is used by -u option.

-O With this option syf places registers on the outputs.

-PImplements a scan-path for the state registers, stack registers and possibly output registers.Scan-path mechanism is directely included in states decoder. Users should use scapin for acorrect insertion of a scan-path in a netlist.

-I Doesn’t inverse outputs polarity.

-RThis option is only available for MOORE FSM. With this option, syf emulates a ROM withmicro-sequencer implementation : there is no combinatorial logic between the state registersand the FSM outputs. This can be mandatory for external timing constraints.

-SWith this option syf doesn’t take into account the cost of the transitions to compute anencoding.

-V Verbose mode on.-F Sets synopsis output format.

provisto por Alliance. Ejecutamos SYF en el archivo mips seq.fsm previamente creado en ese Tutorial.

1.27. VASY 55

Ejecutamos SYF de la siguiente manera:

% syf -o -V mips_seq mips_seqs

@@@@ @ @@@@ @@@@ @@@@@@@@@

@ @@ @@ @ @@ @

@@ @ @@ @ @@ @

@@@ @@ @ @@

@@@@ @@ @@ @

@@@@ @@ @@@@@@

@@@ @@ @@ @

@ @@ @@ @@

@@ @@ @@ @@

@@@ @ @@ @@

@ @@@@ @@@@@@ @@@@@@

FSM Synthesizer

Alliance CAD System 5.0 20040928, syf 5.0


Author(s): Ludovic Jacomme and Chaker Sarwary


--> Compile FSM file mips_seq

--> Check FSM figure outputs

--> Simplify FSM figure

--> Verify FSM figure

--> Identify reset conditions

--> Name : mips_seq

--> States : 99

--> Inputs : 32

--> Outputs : 47

--> Edges : 353

--> Stacks : 0

--> Encode FSM figure

--> One hot encoding

--> Translate FSM to BEH

--> Simplify BEH figure

--> Literals : 5019

--> Save BEH file mips_seqs

Esto genera, usando una codificacion one-hot, el archivo mips seqs.vbe que puede ser usado para sintetizar, enAlliance, el diseno correspondiente.

1.27. VASY

VASY (VHDL Analyzer for sYntesis) es una herramienta que convierte una descripcion en VHDL en unadescripcion sintetizable equivalente que puede ser usada por Alliance u otras herramientas de sıntesis. VASYpuede manejar un subconjunto en VHDL mas grande que los admitidos por Alliance. VASY puede generar unasalida en formato VHDL o Verilog. Usamos VASY mediante el siguiente comando:

vasy [-VpavsoipSHL] [-C num] [-E num] [-I format] [-P file] filename [outname]

Las opciones disponibles en VASY se muestran en la Tabla 1.26.:

1.28. X2Y

X2Y es un convertidor de formato de netlist. Es una herramienta que se usa de la siguiente manera:

% x2y informat outformat infile outfile

No existen opciones para la herramienta X2Y. Los formatos disponibles en X2Y se muestran en la Tabla 1.27.:


Cuadro 1.26: Opciones Disponibles para la herramienta VASY.

Opcion Descripcion-D Sets Debug mode on. As option [Level] and [File] could be given.-V Verbose mode on. Each step of the analysis is displayed onn the standard output.

-I Specifies the VHDL input format such as Alliance VHDL format vbe, vst or industrialVHDL format vhd or vhdl.

-HIn a structural description, all model of instances are recursively analyzed (By default VASYanalyzes only models with generic parameters). The leaves cells are defined by a file calledCATAL.

-P Specifies a ’file.pkg’ containing a list of logical and physical package name.-v Drives an equivalent description in Verilog format.

-aDrives an equivalent description in Alliance VHDL format vbe and/or vst. We can notethat with this option, all arithmetic operators are expanded in an equivalent set of booleanexpressions, because these operators don’t belong to the Alliance VHDL subset.

-s Drives an equivalent VHDL description (with the extension .vhd) accepted by most ofindustrial synthesis tools.

-r-o Authorizes to overwrite existing files.-i Drives initial signal values (taken into account only with option -s).-p Adds power supply connectors (vdd and vss). Usefull option to enter in Alliance.-S Uses Std logic instead of Bit (taken into account only with option -s).

-CWhen the size of the adder is greater or equal to num a Carry Look Ahead adder is generated,instead of a Ripple Carry adder (taken into account only with option -a).

-EComparators are expanded in an equivalent set of boolean expressions, when their size isgreater than num (taken into account only with option -a).

-LA file .lax (see lax(5) for details) is generated. This file contains the list of all signals thatmust be kept during the synthesis step, using boom. (taken into account only with option-a).

-B Drives a .boom file (with -a only).

Cuadro 1.27: Formatos manejados por la herramienta X2Y.

Opcion Descripcional ALLIANCE netlistap ALLIANCE layoutcct HILO netlistcp VTI layoutedi EDIF netlist or layoutfne VTI extracted netlisthns VTI netlistspi, sp, cir SPICE netlistvlg VERILOG netlistvst VHDL netlist

1.29. XFSM

Esta es una herramienta grafica X-Window para visualizar FSMs (Maquinas de Estados Finitas). No dispo-nemos de manuales ni de opciones.

1.30. XPAT

La herramienta XPAT (X window PAT file visualizer) es un visualizador que nos permite ver los archivos.pat usados por ASIMUT o generados por el. Usamos el siguiente comando:

% xpat [-l file_name] [-xor] [-install] [-force]

Las opciones disponibles para XPAT se muestran en la Tabla 1.28.:

1.31. XSCH 57

Cuadro 1.28: Opciones Disponibles para la herramienta XPAT.

Opcion Descripcion-l filename Load the filename (with or without extension)-xor Two graphic cursor methods can be used, invert (default) or xor.-install Switch to a private color map.-force This option force all graphical objects to be displayed.

1.31. XSCH

Es una herramienta grafica de X-Window que sirve para visualizar esquematicos. Esta herramienta necesitaMOTIF y X11r6. Se acceden a todas sus funcionalidades mediante sus menus:

% xsch [-l file_name] [-xor] [-install] [-force] [-I input_format] [-slide file_name ...]

Las opciones que pueden usarse con XSCH se muestran en la Tabla 1.29.:

Cuadro 1.29: Opciones Disponibles para la herramienta XSCH.

Opcion Descripcion-l file name Load the file file name (with or without extension)-xor Two graphic cursor methods can be used, invert or xor.-force This option force all graphical objects to be displayed.-install Switch to a private color map.-I input format Specifies the input format (vst(5), al(5), vbe(5))

-slide file nameEnables slide mode, all specifies files will be displayed one by one using keys +/- inthe graphic window.

1.32. XVPN

Es una herramienta grafica de X-Window que sirve para visualizar redes Petri. No disponemos de manualesni de opciones de ayuda.


Capıtulo 2

Ejemplos de Diseno Combinacional

En el capıtulo 1, hemos visto brevemente, como usar muchas de las herramientas de Alliance. En este capıtuloexplicaremos el diseno de circuitos combinacionales. Se proporcionaron algunos ejemplos y tambien explicaraquellos ejemplos de diseno proporcionados en la documentacion del directorio de Alliance(usrlocalalliancedocumentationalliance-examples/). Empezaremos con la construccion de un circuito segun el estilo de disenode abajo-arriba (botton-up). Este estilo podrıa ser util cuando disenemos circuitos mas complejos.

2.1. El diseno de un multiplicador de 4 bits usando sumadores enarbol

En esta parte explicaremos el diseno de un circuito multiplicador basico de 4 bits. Un multiplicador puedeser construido usando los tres bloques mostrados en la Figura 2.1. El primer bloque, que produce los productos

Figura 2.1: Los bloques basicos para construir.

parciales, puede ser implementado con una circuiterıa muy simple tal como se muestra en la Figura 2.2. Para los

Figura 2.2: Generador de productos parciales de 4bits.

sumadores en arbol podemos usar muchos esquemas. En la Figura 2.3 se muestran tres esquemas. El primero(el de mas a la izquierda) fue propuesto por Wallace[1]. El esquema del medio es debido a Dadda[2] y el de laderecha es de referencia [3]. Disenaremos el multiplicador de esta seccion usando los tres esquemas para luegocomparar las areas de los circuitos obtenidos con ellos. La propuesta de Wallace es frecuentemente la mas usada

59

60 CAPITULO 2. EJEMPLOS DE DISENO COMBINACIONAL

en disenos comerciales y de investigacion. El arbol de Dadda es un metodo opcional que produce disenos maspequenos. La tercera propuesta es otra forma de estructurar el sumador en arbol. Con este metodo, reducimosel numero de medio-sumadores en el arbol y el numero de bits al final del sumador. Los bloques rectangulares en

(a) (b) (c)

Figura 2.3: Tres esquemas de sumadores en arbol propuestos por: (a) Wallace (b) Dadda (c) Palacios

las representaciones en arbol representan los circuitos de los medio-sumadores y sumadores completos. Detallesde estos circuitos son dados en la Figura 2.4 y Figura 2.5, respectivamente. En este ejemplo, implementaremos

Figura 2.4: Detalles del circuito Medio-sumador (Half-adder, HA).

Figura 2.5: Detalles del circuito Sumador completo (Full-adder, FA).

el ultimo paso del multiplicador con un sumador con acarreo como el mostrado en la figura 2.6. La estructura

Figura 2.6: Sumador con acarreo de 4bits.

jerarquica de nuestro multiplicador esta mostrado en la figura 2.7.

2.1. EL DISENO DE UN MULTIPLICADOR DE 4 BITS USANDO SUMADORES EN ARBOL 61

Figura 2.7: Diseno jerarquico del multiplicador.

2.1.1. Diseno de un generador de productos parciales

Disenaremos el generador de productos parciales mediante la siguiente descripcion comportamental.

-- 4-bit partial product generator

entity myppg4 is

port(a0,a1,a2,a3,b0,b1,b2,b3,vdd,vss : in bit;

p00,p01,p02,p03,p10,p11,p12,p13 : out bit;

p20,p21,p22,p23,p30,p31,p32,p33 : out bit);

end ppg4;

--behavior

architecture vbe of myppg4 is

begin

p00 <= b0 AND a0;

p01 <= b0 AND a1;

p02 <= b0 AND a2;

p03 <= b0 AND a3;

p10 <= b1 AND a0;

p11 <= b1 AND a1;

p12 <= b1 AND a2;

p13 <= b1 AND a3;

p20 <= b2 AND a0;

p21 <= b2 AND a1;

p22 <= b2 AND a2;

p23 <= b2 AND a3;

p30 <= b3 AND a0;

p31 <= b3 AND a1;

p32 <= b3 AND a2;

p33 <= b3 AND a3;

end vbe;

El siguiente paso sera optimizarlo y sintetizarlo usando las herramientas BOOM, BOOG y LOON. UsaremosBOOM con las opcion de optimizar velocidad.

% boom -l 3 -d 0 myppg4 ppg4

@@@@@@@ @@@ @@@

@@ @@ @@ @@

@@ @@ @@@ @@@

@@ @@ @@@ @@@ @@@ @@@

@@ @@ @@ @@ @@ @@ @ @@ @ @@

@@@@@@ @@ @@ @@ @@ @ @@ @ @@

@@ @@ @@ @@ @@ @@ @ @@@ @@

@@ @@ @@ @@ @@ @@ @ @@ @@

@@ @@ @@ @@ @@ @@ @ @ @@

@@ @@ @@ @@ @@ @@ @ @@

@@@@@@@@ @@@ @@@ @@@ @@@@






--> Parse BEH file myppg4.vbe

--> Drive BEH file ppg4


Si se observa el archivo de salida obtenido con BOOM se podra apreciar que este no mejora la descripcion yadada. A continuacion, usamos BOOG optimizando el retardo (la salida ha sido recortada para hacerlo fijo).

% boog ppg4 myppg4 -x 0 -m 4

@@@@@@@ @@@@ @

@@ @@ @@ @@

@@ @@ @@ @

@@ @@ @@@ @@@ @@

@@ @@ @@ @@ @@ @@ @@

@@@@@@ @@ @@ @@ @@ @@ @@@@@

@@ @@ @@ @@ @@ @@ @@ @ @@

@@ @@ @@ @@ @@ @@ @@ @ @@

@@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@@ @@@ @@@ @@@@







100% delay optimization

Reading file ’ppg4.vbe’...

Controlling file ’ppg4.vbe’...



Preparing file ’ppg4.vbe’...

Capacitances on file ’ppg4.vbe’...

Unflattening file ’ppg4.vbe’...

Mapping file ’ppg4.vbe’...

Saving file ’myppg4.vst’...

Quick estimated critical path (no warranty)...324 ps from ’a3’ to ’p33’


Details...

a2_x2: 16

Total: 16

Saving critical path in xsch color file ’myppg4.xsc’...

End of boog...

Al aplicar LOON al archivo .vst se obtiene (la salida ha sido recortada para hacerlo fijo).

% loon -x 0 -m 4 myppg4 ppg4

@@@@@@ @@@ @@@

@@ @@ @

@@ @@@ @

@@ @@@ @@@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @ @@ @@ @@ @@ @ @@@

@@ @ @@ @@ @@ @@ @ @@

@@@@@@@@@@ @@@ @@@ @@@ @@








Reading file ’myppg4.vst’...


Capacitances on file ’myppg4.vst’...

Delays on file ’myppg4.vst’...324 ps

Area on file ’myppg4.vst’...20000 lamda? (with over-cell routing)

Details...

a2_x2: 16 (100%)

Total: 16

Critical path (no warranty)...324 ps from ’a3’ to ’p33’

Saving file ’ppg4.vst’...

Saving critical path in xsch color file ’ppg4.xsc’...

End of loon...


Hasta aquı, hemos tenemos una descripcion estructural sintetizada de nuestro generador original de productosparciales. Para los otros dos bloques, necesitamos como bloque basico circuitos medio-sumadores y sumadorescompletos. El diseno y sıntesis de aquellos es mostrado en la siguiente seccion.

2.1.2. Diseno de un medio-sumador y sumador completo

En el diseno de los sumadores en arbol y en la salida del sumador del multiplicador usaremos el medio-sumador y sumador completo de la Figura 2.4 y 2.5 respectivamente. El medio-sumador esta dado por lasiguiente descripcion comportamental (recuerde que debemos proporcionar la decripcion comportamental yestructural de nuestros disenos).

-- half adder

entity ha is

port(a,b,vdd,vss : in bit;

sum,carry : out bit);

end ha;

--behavior

architecture vbe of ha is

signal a_bar, b_bar : bit;

begin

a_bar <= NOT a;

b_bar <= NOT b;

sum <= (a_bar AND b) OR (a AND b_bar);

carry <= a AND b;

end vbe;

Se puede apreciar que esta descripcion no corresponde al circuito de la Figura 2.4. Obtendremos esa descripcionusando BOOM y optimizando el retrazo.

% boom -l 3 -d 0 myha ha

Se obtiene el siguiente archivo comportamental que es agregado al flujo de descripcion del circuito de laFigura 2.4.

-- VHDL data flow description generated from ‘ha‘

-- date : Mon Feb 14 11:05:26 2005

-- Entity Declaration

ENTITY ha IS

PORT (

a : in BIT; -- a

b : in BIT; -- b

vdd : in BIT; -- vdd

vss : in BIT; -- vss

sum : out BIT; -- sum

carry : out BIT -- carry

);

END ha;

-- Architecture Declaration

ARCHITECTURE behaviour_data_flow OF ha IS

BEGIN

carry <= (b AND a);

sum <= (b XOR a);

END;

Ejecutamos BOOG y LOON sobre este circuito de la siguiente manera:

% boog ha myha -x 0 -m 4

% loon -x 0 -m 4 myha ha


Para el caso del sumador completo, usaremos la siguiente descripcion comportamental que encaja con el circuitode la Figura 2.5.

-- full adder

entity fa is

port(a,b,cin,vdd,vss : in bit;

sum,cout : out bit);

end fa;

--behavior

architecture vbe of fa is

signal xor1 : bit;

begin

xor1 <= a XOR b;

cout <= b when xor1 = ’0’ else cin;

sum <= cin XOR xor1;

end vbe;

Al igual que para el medio-sumador, ejecutaremos sobre este circuito las herramientas BOOM, BOOG y LOONoptimizando velocidad (retrazo).

% boom -l 3 -d 0 myfa fa

% boog fa myfa -x 0 -m 4

% loon -x 0 -m 4 myfa fa

Usted puede apreciar que el multiplexor del circuito inicial ha sido cambiado por la celda oa2ao222 x2 duranteel proceso de sıntesis. Por tanto, estamos listos para disenar los sumadores en arbol y el sumador de salida delmultiplicador. Mostraremos en la siguiente seccion el diseno de los sumadores en arbol.

2.1.3. Arbol sumador

De acuerdo a lo mostrado en la Figura 2.3, hay muchas formas de implementar los sumadores en arbolo arbol sumador utilizado en un multiplicador. Explicaremos aquı el diseno del arbol usando la propuesta deWallace [1]. La descripcion comportamental de dicha propuesta es la siguiente:

entity wallace4 is

port(p01,p02,p03 : in bit;

p10,p11,p12,p13 : in bit;

p20,p21,p22,p23 : in bit;

p30,p31,p32,p33 : in bit;

vdd,vss : in bit;

p1,p2,p3a,p3b,p4a,p4b,p5a,p5b,p6a,p6b,p7b : out bit);

end wallace4;

architecture structural of wallace4 is

Component ha

port(a,b : in bit;

vdd,vss : in bit;


end component;

component fa

port(a,b,cin : in bit;

vdd,vss : in bit;


end component;

signal h1c,f1s,f1c,f2s,f2c : bit;

signal f3s,f3c,h2s,h2c : bit;


begin

-- Wallace tree

-- first level

ha1 : ha

port map(a => p01, b => p10,

vdd => vdd, vss => vss,

sum => p1, carry => h1c);

fa1 : fa

port map(a => p02, b => p11, cin => p20,


sum => f1s, cout => f1c);

fa2 : fa




fa3 : fa




ha2 : ha

port map(a => p23, b => p32,


sum => h2s, carry => h2c);

-- second level

ha3 : ha

port map(a => f1s, b => h1c,


sum => p2, carry => p3b);

fa4 : fa

port map(a => f2s, b => f1c, cin => p30,


sum => p3a, cout => p4b);

ha4 : ha

port map(a => f3s, b => f2c,


sum => p4a, carry => p5b);

ha5 : ha

port map(a => h2s, b => f3c,



ha6 : ha

port map(a => p33, b => h2c,



end structural;

Debido a que ya sintetizamos los bloques basicos podemos describir el arbol como antes en el programaescrito. Para el proceso de sıntesis tenemos muchas opciones. Aplicaremos en este caso FlatBeh para obtener ladescripcion comportamental del arbol sumador.

% flatbeh mywallace mywallace

A continuacion le aplicaremos sucesivamente las herramientas BOOM, BOOG y LOON (de hecho, podemossolamente aplicarle a nuestro arbol BOOG y LOON).

% boom -l 3 -d 0 mywallace wallace

% boog wallace swallace -x 0 -m 4

% loon -x 0 -m 4 swallace wallace


Lo anterior completa el proceso de sıntesis del arbol sumador. En la siguiente seccion disenaremos el ultimobloque requerido por el multiplicador.

2.1.4. Sumador de salida

El diseno del sumador de salida es muy simple. A continuacion se tiene la descripcion estructural del diseno.

entity add5 is

port(a3,a4,a5,a6 : in bit;

b3,b4,b5,b6,b7 : in bit;

vdd,vss : in bit;

s3,s4,s5,s6,s7,c7 : out bit);

end add5;

architecture structural of add5 is

Component ha

port(a,b : in bit;

vdd,vss : in bit;


end component;

component fa

port(a,b,cin : in bit;

vdd,vss : in bit;


end component;

signal c3,c4,c5,c6 : bit;

begin

-- carry ripple adder for the 4-bit multiplier

ha1 : ha

port map(a => a3, b => b3,


sum => s3, carry => c3);

fa1 : fa

port map(a => a4, b => b4, cin => c3,


sum => s4, cout => c4);

fa2 : fa



sum => s5, cout => c5);

fa3 : fa



sum => s6, cout => c6);

ha2 : ha

port map(a => c6, b => b7,


sum => s7, carry => c7);

end structural;

Aquı igualmente usamos FlatBeh, BOOM, BOOG y LOON para sintetizar el diseno.

% flatbeh myadd5 myadd5

% boom -l 3 -d 0 myadd5 add5

% boog add5 sadd5 -x 0 -m 4

% loon -x 0 -m 4 sadd5 add5

Ahora podemos proceder con el diseno del multiplicador lo cual sera descrito en la siguiente seccion.


2.1.5. Multiplicador de 4 bits

Considerando que tenemos todos los componentes de nuestro multiplicador podemos empezar con una des-cripcion estructural de el.

entity multiplier4 is


b0,b1,b2,b3 : in bit;

vdd,vss : in bit;

p0,p1,p2,p3,p4,p5,p6,p7,p8 : out bit);

end multiplier4;

architecture structural of multiplier4 is

Component ppg4


b0,b1,b2,b3 : in bit;

vdd,vss : in bit;

p00,p01,p02,p03 : out bit;

p10,p11,p12,p13 : out bit;

p20,p21,p22,p23 : out bit;

p30,p31,p32,p33 : out bit);

end component;

Component wallace

port(p01,p02,p03 : in bit;

p10,p11,p12,p13 : in bit;

p20,p21,p22,p23 : in bit;

p30,p31,p32,p33 : in bit;

vdd,vss : in bit;

p1,p2,p3a,p3b,p4a,p4b,p5a,p5b,p6a,p6b,p7b : out bit);

end component;

Component add5


b3,b4,b5,b6,b7 : in bit;

vdd,vss : in bit;

s3,s4,s5,s6,s7,c7 : out bit);

end component;

signal p01,p02,p03 : bit;

signal p10,p11,p12,p13 : bit;



signal p3a,p3b,p4a,p4b,p5a,p5b,p6a,p6b,p7b : bit;

begin

-- partial product generation

ppg : ppg4

port map(a0 => a0, a1 => a1, a2 => a2, a3 => a3,

b0 => b0, b1 => b1, b2 => b2, b3 => b3,


p00 => p0, p01 => p01, p02 => p02, p03 => p03,

p10 => p10, p11 => p11, p12 => p12, p13 => p13,

p20 => p20, p21 => p21, p22 => p22, p23 => p23,

p30 => p30, p31 => p31, p32 => p32, p33 => p33);

-- Wallace tree

w4 : wallace

port map(p01 => p01, p02 => p02, p03 => p03,

p10 => p10, p11 => p11, p12 => p12, p13 =>p13,

p20 => p20, p21 =>p21, p22 => p22, p23 =>p23,

p30 => p30, p31 => p31, p32 => p32, p33 =>p33,


p1 => p1 , p2 => p2, p3a => p3a, p3b => p3b, p4a => p4a,

p4b => p4b, p5a => p5a, p5b => p5b, p6a => p6a, p6b => p6b,

p7b => p7b);

-- output adder

add : add5

port map(a3 => p3a, a4 => p4a, a5 => p5a, a6 => p6a,

b3 => p3b, b4 => p4b, b5 => p5b, b6 => p6b, b7 => p7b,


s3 => p3, s4 => p4, s5 => p5, s6 => p6, s7 => p7, c7 => p8);

end structural;


Tal como hemos realizado anteriormente, primero usaremos el FlatBeh para obtener una representacion com-portamental de nuestro multiplicador.

% flatbeh mymultiplier4 mymultiplier4

@@@@@@@@@ @@@@ @@@@@@@ @@@

@@ @ @@ @ @@ @@ @@

@@ @ @@ @@ @@ @@ @@

@@ @@ @@@@ @@ @@ @@ @@@@@ @@ @@@

@@ @ @@ @@ @ @@@@@@@@ @@ @@ @ @ @@@ @@

@@@@@@ @@ @@ @@ @@ @@@@@@ @@ @@ @@ @@

@@ @ @@ @@@@@ @@ @@ @@ @@@@@@@@@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @@ @ @@ @@

@@ @@ @@ @@@ @@ @ @@ @@ @@ @@ @@ @@

@@@@@@ @@@@@@ @@@@ @@ @@@@ @@@@@@@@ @@@@ @@@@ @@@@

a netlist abstractor

Alliance CAD System 5.0 20040928, flatbeh 5.0 [2000/11/01]


Author(s): Fran?ois DONNET, Huu Nghia VUONG


========================= Environnement =========================

MBK_WORK_LIB = .

MBK_CATA_LIB = .:/usr/local/alliance/cells/sxlib:/usr/local/alliance/cells/dp_sxlib:

/usr/local/alliance/cells/rflib:/usr/local/alliance/cells/romlib:

/usr/local/alliance/cells/ramlib:/usr/local/alliance/cells/padlib

MBK_CATAL_NAME = CATAL

============================== Files ==============================

Netlist file = mymultiplier4.vst

Output file = mymultiplier4.vbe

===================================================================

Loading ’./mymultiplier4.vst’

flattening figure mymultiplier4

loading buf_x2

loading oa2a22_x2

loading oa2ao222_x2

loading o3_x2

loading inv_x2

loading noa2ao222_x1

loading o2_x2

loading mx2_x2

loading nao22_x1

loading xr2_x1

loading noa22_x1

loading nxr2_x1

loading no2_x1

loading no3_x1

loading na2_x1

loading an12_x1

loading a2_x2

Restoring array’s orders

BEH : Saving ’mymultiplier4’ in a vhdl file (vbe)

Con la descripcion comportamental, entonces podemos optimizarlo primero usando BOOM.

% boom -l 3 -d 0 mymultiplier4 multiplier4

@@@@@@@ @@@ @@@

@@ @@ @@ @@

@@ @@ @@@ @@@

@@ @@ @@@ @@@ @@@ @@@

@@ @@ @@ @@ @@ @@ @ @@ @ @@

@@@@@@ @@ @@ @@ @@ @ @@ @ @@

@@ @@ @@ @@ @@ @@ @ @@@ @@

@@ @@ @@ @@ @@ @@ @ @@ @@

@@ @@ @@ @@ @@ @@ @ @ @@

@@ @@ @@ @@ @@ @@ @ @@

@@@@@@@@ @@@ @@@ @@@ @@@@






--> Parse BEH file mymultiplier4.vbe

--> Drive BEH file multiplier4


Luego usamos BOOG para mapear la descripcion en la librerıa de celdas proporcionada por Alliance.

% boog multiplier4 smultiplier4 -x 0 -m 4

@@@@@@@ @@@@ @

@@ @@ @@ @@

@@ @@ @@ @

@@ @@ @@@ @@@ @@

@@ @@ @@ @@ @@ @@ @@

@@@@@@ @@ @@ @@ @@ @@ @@@@@

@@ @@ @@ @@ @@ @@ @@ @ @@

@@ @@ @@ @@ @@ @@ @@ @ @@

@@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@@ @@@ @@@ @@@@






MBK_VDD : vdd

MBK_VSS : vss

MBK_IN_LO : vst

MBK_OUT_LO : vst

MBK_WORK_LIB : .




Reading file ’multiplier4.vbe’...

Controlling file ’multiplier4.vbe’...







Preparing file ’multiplier4.vbe’...

Capacitances on file ’multiplier4.vbe’...

Unflattening file ’multiplier4.vbe’...

Mapping file ’multiplier4.vbe’...

Saving file ’smultiplier4.vst’...

Quick estimated critical path (no warranty)...2990 ps from ’b2’ to ’p4’


Details...

na2_x1: 39

no2_x1: 32

a2_x2: 31

inv_x2: 12

oa22_x2: 11

na3_x1: 11

o2_x2: 11

noa22_x1: 10

nao22_x1: 7

on12_x1: 6

xr2_x1: 6

a3_x2: 5

ao22_x2: 5

nxr2_x1: 5

no3_x1: 4

mx3_x2: 4

oa2ao222_x2: 4

nao2o22_x1: 4

o3_x2: 3

na4_x1: 2

noa2ao222_x1: 2

zero_x0: 1

ao2o22_x2: 1

a4_x2: 1

mx2_x2: 1

no4_x1: 1

buf_x2: 1

Total: 220

Saving critical path in xsch color file ’smultiplier4.xsc’...

End of boog...


Finalmente con LOON reducimos retardos (el cual insertara buffers donde sea apropiado).

% loon -x 0 -m 4 smultiplier4 multiplier4

@@@@@@ @@@ @@@

@@ @@ @

@@ @@@ @

@@ @@@ @@@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @ @@ @@ @@ @@ @ @@@

@@ @ @@ @@ @@ @@ @ @@

@@@@@@@@@@ @@@ @@@ @@@ @@






MBK_IN_LO : vst

MBK_OUT_LO : vst




Reading file ’smultiplier4.vst’...


Capacitances on file ’smultiplier4.vst’...

Delays on file ’smultiplier4.vst’...3304 ps

Area on file ’smultiplier4.vst’...291000 lamda? (with over-cell routing)

Worst RC on file ’smultiplier4.vst’...634 ps

Inserting buffers on critical path for file ’multiplier4.vst’...1 buffer inserted -> 3263 ps

Improving RC on critical path for file ’multiplier4.vst’...3246 ps

Improving all RC for file ’multiplier4.vst’...

Worst RC on file ’multiplier4.vst’...373 ps

Area on file ’multiplier4.vst’...293000 lamda? (with over-cell routing)

Details...

na2_x1: 39 (13%)

no2_x1: 32 (10%)

a2_x2: 31 (13%)

oa22_x2: 11 (5%)

na3_x1: 11 (4%)

o2_x2: 11 (4%)

inv_x2: 11 (2%)

noa22_x1: 10 (5%)

nao22_x1: 7 (3%)

on12_x1: 6 (2%)

xr2_x1: 6 (4%)

a3_x2: 5 (2%)

ao22_x2: 5 (2%)

nxr2_x1: 5 (3%)

no3_x1: 4 (1%)

mx3_x2: 4 (4%)

oa2ao222_x2: 4 (3%)

nao2o22_x1: 4 (2%)

o3_x2: 3 (1%)

buf_x2: 2 (0%)

na4_x1: 2 (1%)

noa2ao222_x1: 2 (1%)

zero_x0: 1 (0%)

ao2o22_x2: 1 (0%)

a4_x2: 1 (0%)

mx2_x2: 1 (0%)

no4_x1: 1 (0%)

inv_x8: 1 (0%)

Total: 221

Critical path (no warranty)...3246 ps from ’b2’ to ’p4’

Saving file ’multiplier4.vst’...

Saving critical path in xsch color file ’multiplier4.xsc’...

End of loon...


Con todo lo realizado estamos listos para pasar nuestro diseno a la fase del layout como etapa siguiente delproceso de diseno. Para esto usamos primero OCP para ubicarlo.

% ocp -ring multiplier4 mymultiplier4

@@@ @@@@ @ @@@@@@@

@@ @@ @@ @@ @@ @@

@@ @@ @@ @ @@ @@

@@ @@ @@ @ @@ @@

@@ @@ @@ @@ @@

@@ @@ @@ @@@@@

@@ @@ @@ @@

@@ @@ @@ @@

@@ @@ @@ @ @@

@@ @@ @@ @@ @@

@@@ @@@@ @@@@@@







...............................................................


Con el circuito ubicado o posicionado procedemos a enrutarlo o enlazarlo con NERO.

% nero -V -2 -p mymultiplier4 multiplier4 multiplier4

En este punto, es util verificar el flujo de diseno que hemos seguido. Esto se muestra en la Figura 2.8. Como

Figura 2.8: Flujo de diseno en un diseno jerarquico hasta el paso de ubicacion o posicionamiento.

puede ser notado de esta figura, nosotros podemos extraer usando COUGAR una descripcion estructural desde


el archivo de diseno enrutado o enlazado para proceder a compararlo con aquel sintetizado mediante LOON.Hagamoslo:

% cougar -f -v multiplier4 multiplier4_lay

Esto nos dara una descripcion estructural de nuestro diseno. Usemos LVX para compararlo con el obtenido conLOON.

% lvx vst vst multiplier4 multiplier4_lay

@@@@@@ @@@@ @@@ @@@@ @@@@

@@ @@ @ @@ @

@@ @@ @ @@ @

@@ @@ @ @@ @

@@ @@ @ @@

@@ @@ @ @@

@@ @@ @ @@@

@@ @@@ @ @@

@@ @ @@@ @ @@

@@ @ @ @ @@

@@@@@@@@@@ @ @@@ @@@@





***** Loading multiplier4 (vst)...

Warning 2 : consistency checks will be disabled

***** Loading multiplier4_lay (vst)...

***** Compare Terminals ..............

***** O.K. (0 sec)

***** Compare Instances .............

***** O.K. (0 sec)

***** Compare Connections ............................

***** O.K. (0 sec)

===== Terminals .......... 19

===== Instances .......... 221

===== Connectors ......... 1213


La comparacion nos dice que los dos netlists son identicos. Verifiquemos ahora las reglas de diseno del layoutusando DRUC.

% druc multiplier4

@@@@@@@ @@@@@@@ @@@@ @

@@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @

@@ @@ @@ @@ @@@ @@@@ @@ @

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@@@@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @

@@ @@ @@ @@ @@ @@@ @@ @@

@@@@@@@ @@@@@ @@@ @@@@ @@ @@@@

Design Rule Checker




Flatten DRC on: multiplier4

Delete MBK figure : multiplier4

Load Flatten Rules : /usr/local/alliance/etc/cmos.rds

Unify : multiplier4

Create Ring : multiplier4_rng

Merge Errorfiles:



End DRC on: multiplier4


Done

0

File: multiplier4.drc is empty: no errors detected.


Luego de esto, estamos listos para convertir nuestro diseno simbolico a uno real (usando la tecnologıa propor-cionada por Alliance). Para esto, usamos S2R.

% s2r multiplier4

@@@@

@ @@

@@ @@

@@@@@@ @@@ @@ @@@ @@@

@@ @ @ @@ @@@ @@

@@@ @ @@ @@

@@@@ @ @@

@@@@ @ @@

@ @@@ @ @ @@

@@ @@ @@@@@@ @@

@ @@@@@ @@@@@@@ @@@@





o loading technology file : /usr/local/alliance/etc/cmos.rds

o loading all level of symbolic layout : multiplier4





with signal names,

without scotch.

o saving multiplier4.cif

Para visualizar el layout obtenido usamos DREAL.

% dreal

El layout obtenido con S2R es mostrado en la Figura 2.9.

Figura 2.9: Layout mostrado por DREAL.


Los otros dos arboles mostrados en la Figura pueden ser implementados usando las hojas de diseno que seproporcionan con las fuentes del libro.

2.2. El uso de Makefiles para automatizar el flujo de diseno

Aquı usaremos el diseno del multiplicador de 4bits del directorio de ejemplos de Alliance para explicar conalgun detalle el uso de makefiles para automatizar el proceso de diseno y hacerlo mas facil modificando archivosen nuestros disenos. El ejemplo que nosotros mostraremos aquı ya tiene su propio makefile. Explicaremos comoconstruir uno propio. Al final, usted tendra un makefile propio casi identico al proporcionado con el ejemplo.Debido a que trabajamos todo el texto en un ambiente shell tsch, seguiremos un metodo similar a los usados enlos tutoriales de Alliance. Colocaremos variables de entorno en la lınea de comandos y dejamos ejecutarse lasherramientas para obtener el makefile. Primero obtendremos una descripcion comportamental (Alliance) desdeel archivo VHDL proporcionado en el ejemplo. Para esto usamos VASY. Colocaremos las variables de entornocomo se indican en el makefile original.

setenv MBK_WORK_LIB .; setenv MBK_CATAL_NAME NO_CATAL

Y, editaremos el siguiente makefile.

ALLIANCE_BIN=$(ALLIANCE_TOP)/bin

VASY = $(ALLIANCE_BIN)/vasy

multi4.vbe : multi4.vhdl

$(VASY) -a -B -o -p -I vhdl multi4

Esto es una version simplificada del original Makefile, mostrando solo lo que es necesario para ejecutarVASY. Expliquemos el anterior Makefile. En la lınea superior usamos lo que se suele llamar macros. Los Macrosson similares a las variables. Ellos nos almacenan nombres de archivos, rutas de directorios, etc. En nuestromake file usamos una macro para definir la ruta hacia el directorio bin en Alliance. El segundo macro usa alprimero para apuntar a la herramienta VASY. En el segundo macro expandimos el primero mediante el tipeode $(macro).

La segunda mitad de nuestro make file define una dependencia. El multi4.vbe4 es el destino y el argumentodespues del : es el archivo fuente necesario para acceder al destino. En otras palabras, se tiene el siguiente formatodestino : archivo(s) fuente. En las lıneas siguiendo la definicion de dependencia, definimos los comandos paragenerar el destino usando los archiuvos fuente(s). En este caso, necesitamos un comando para ejecutar VASYsobre el archivo fuente con las correspondientes opciones para obtener la descripcion comportamental de Alliance.Recuerde que las lıneas comando deben ser precedidas por un tab. Con este make file ahora podemos ejecutarVASY de la siguiente manera:

% make multi4.vbe

/usr/local/alliance/bin/vasy -a -B -o -p -I vhdl multi4

@@@@ @@@ @ @@@@ @ @@@@ @@@@

@@ @ @ @ @@ @@ @

@@ @ @@@ @@ @ @@ @

@@ @ @@@ @@@ @@ @

@@ @ @ @@ @@@@ @@

@@ @ @ @@ @@@@ @@

@@ @ @ @@ @@@ @@

@@@ @@@@@@@ @ @@ @@

@@@ @ @@ @@ @@ @@

@ @ @@ @@@ @ @@

@ @@@@ @@@@ @ @@@@ @@@@@@

VHDL Analyzer for SYnthesis

Alliance CAD System 5.0 20040928, vasy 5.0



Contributor(s): Frederic Petrot


--> Run VHDL Compiler

--> Compile file multi4

--> Drive Alliance file multi4

A continuacion, simularemos la descripcion comportamental con el archivo pat proporcionado por el ejemplo.

2.2. EL USO DE MAKEFILES PARA AUTOMATIZAR EL FLUJO DE DISENO 75

Antes de hacer aquello, necesitamos cambiar algunas variables de entorno.

% setenv MBK_CATAL_NAME CATAL_ASIMUT_VASY

% setenv MBK_IN_LO vst

% setenv MBK_OUT_LO vst

Nosotros no cambiamos MBK WORK LIB debido a que es el mismo usado para derivar la descripcion com-portamental. Tenemos que modificar nuestro Makefile de la siguiente manera:



ASIMUT = $(ALLIANCE_BIN)/asimut



res_vasy_1.pat : multi4.vbe

$(ASIMUT) -b multi4 multi4 res_vasy_1

Hemos agregado una macro para usar ASIMUT y una relacion de dependencia mas. El destino en este casodepende del archivo comportamental que nosotros ya hemos obtenido. Si el no estuviera disponible la primerarelacion de dependencia serıa ejecutada antes de ejecutar la segunda.

Los Makefiles no solo verifican dependencias, tambien se usan para modificar tiempos de los archivos. Portanto, en caso que el archivo VHDL sea mas nuevo que el archivo comportamental cuando tratemos de ejecutarla simulacion sobre el, el comportamental se actualizara ejecutando VASY sobre el archivo VHDL modificado.Ejecutemos el Makefile sobre el segundo destino para simular el archivo comportamental.

% make res_vasy_1.pat

/usr/local/alliance/bin/asimut -b multi4 multi4 res_vasy_1

@ @@@@ @ @ @@@@@@@@@@

@ @ @@ @@@ @ @@ @

@@@ @@ @ @ @ @@ @

@@@ @@@ @@@ @@ @@@ @@@ @@@@ @@

@ @@ @@@@ @@@@ @@@ @@ @@ @@ @@ @@

@ @@ @@@@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@ @ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @ @@ @@ @@ @@ @@ @@@ @@

@@@@ @@@@ @ @@@@ @@@@@@ @@@@ @@@ @@@ @@@@ @@ @@@@@@

A SIMUlation Tool





initializing ...

searching ‘multi4‘ ...

BEH : Compiling ‘multi4.vbe‘ (Behaviour) ...

making GEX ...

searching pattern file : ‘multi4‘ ...

restoring ...

linking ...

executing ...



...




Estamos listos para empezar el proceso de sıntesis con BOOM, BOOG y LOON. Primero modifiquemos nuestromakefile para hacerlo ejecutable con BOOM. Para esto agregamos las lıneas definiendo TOUCH y tambien


agregamos la relacion de dependencia correspondiente.



ASIMUT = $(ALLIANCE_BIN)/asimut

BOOM = $(ALLIANCE_BIN)/boom

TOUCH = touch



res_vasy_1.pat : multi4.vbe

$(ASIMUT) -b multi4 multi4 res_vasy_1

boom.done : multi4_o.vbe

@$(TOUCH) boom.done

multi4_o.vbe : multi4.vbe multi4.boom res_vasy_1.pat

$(BOOM) -VP multi4 multi4_o

La primera dependencia, solicitando la generacion del archivo boo.done, nos permitira verificar si boom ha sidoejecutado y tambien ejecutara BOOM indirectamente. El sımbolo @ antes del comando touch evitara el rebotede el (cada linea de comando que empieza con @ no se mostrara). Antes y como primer paso modificaremosuna variable de entorno.

% setenv MBK_CATAL_NAME CATAL

Luego llamamos a BOOM con la siguiente expresion: (La salida ha sido recortada para hacerlo fijo).

% make boom.done

/usr/local/alliance/bin/boom -VP multi4 multi4_o

@@@@@@@ @@@ @@@

@@ @@ @@ @@

@@ @@ @@@ @@@

@@ @@ @@@ @@@ @@@ @@@

@@ @@ @@ @@ @@ @@ @ @@ @ @@

@@@@@@ @@ @@ @@ @@ @ @@ @ @@

@@ @@ @@ @@ @@ @@ @ @@@ @@

@@ @@ @@ @@ @@ @@ @ @@ @@

@@ @@ @@ @@ @@ @@ @ @ @@

@@ @@ @@ @@ @@ @@ @ @@

@@@@@@@@ @@@ @@@ @@@ @@@@






--> Parse BEH file multi4.vbe

--> Check figure multi4

--> Parse parameter file multi4.boom

keep signal ’rtlcarry_0 7’

...

keep signal ’rtlcarry_4 1’

--> Optimization parameters

Algorithm : simulated annealing

Keep aux : no

Area : 100 %

Delay : 0 %

Level : 0

--> Initial cost

Surface : 216250

Depth : 25

Literals : 194

--> Translate Abl to Bdd

Total Bdd nodes 518

--> Optimization % 100

--> Final cost

Surface : 295000

Depth : 18

Literals : 251

--> Post treat figure multi4

--> Drive BEH file multi4_o


Lo anterior generara un archivo vacıo con el nombre boom.done que indicara que BOOM ha sido ejecutadoy que la correspondiente descripcion comportamental minimizada ha sido generada. Ahora, modificaremos elmakefile para ejecutar BOOG. Agregaremos las siguientes lıneas a nuestro Makefile.

BOOG = $(ALLIANCE_BIN)/boog

TARGET_LIB = $(ALLIANCE_TOP)/cells/sxlib

boog.done : multi4_o.vst

@$(TOUCH) boog.done

multi4_o.vst : multi4_o.vbe

$(BOOG) multi4_o

Antes de la ejecucion debemos colocar la librerıa destino (de acuerdo a las variables de entorno del makefileoriginal ya ubicadas).

% setenv TARGET_LIB $ALLIANCE_TOP/cells/sxlib

Hasta este punto solamente esta variable aun no ha sido ubicada. Despues de esto, estamos listos para ejecutarBOOG tal como hemos hecho con BOOM (la salida ha sido recortada para hacerlo fijo).

% make boog.done

/usr/local/alliance/bin/boog multi4_o

@@@@@@@ @@@@ @

@@ @@ @@ @@

@@ @@ @@ @

@@ @@ @@@ @@@ @@

@@ @@ @@ @@ @@ @@ @@

@@@@@@ @@ @@ @@ @@ @@ @@@@@

@@ @@ @@ @@ @@ @@ @@ @ @@

@@ @@ @@ @@ @@ @@ @@ @ @@

@@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@@ @@@ @@@ @@@@






MBK_VDD : vdd

MBK_VSS : vss

MBK_IN_LO : vst

MBK_OUT_LO : vst

MBK_WORK_LIB : .




Reading file ’multi4_o.vbe’...

Controlling file ’multi4_o.vbe’...



...


Preparing file ’multi4_o.vbe’...

Capacitances on file ’multi4_o.vbe’...

Unflattening file ’multi4_o.vbe’...

Mapping file ’multi4_o.vbe’...

Saving file ’multi4_o.vst’...

Quick estimated critical path (no warranty)...3362 ps from ’x 0’ to ’r 3’


Details...

xr2_x1: 26

...

ao2o22_x2: 1

Total: 145

Saving critical path in xsch color file ’multi4_o.xsc’...

End of boog...

Ahora colocamos nuestro Makefile para ejecutar LOON. Debido a que el entorno es el mismo que el usado por


BOOG, no necesitamos modificarlo. Agregamos a nuestro Makefile las siguientes lıneas.

LOON = $(ALLIANCE_BIN)/loon

loon.done : multi4.vst

@$(TOUCH) loon.done

multi4.vst : multi4_o.vst

$(LOON) multi4_o multi4

A continuacion realizamos la ejecucion de la siguiente manera (la salida ha sido fijada).

% make loon.done

/usr/local/alliance/bin/loon multi4_o multi4

@@@@@@ @@@ @@@

@@ @@ @

@@ @@@ @

@@ @@@ @@@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @@ @@ @@ @@ @ @@ @

@@ @ @@ @@ @@ @@ @ @@@

@@ @ @@ @@ @@ @@ @ @@

@@@@@@@@@@ @@@ @@@ @@@ @@






MBK_IN_LO : vst

MBK_OUT_LO : vst




Reading file ’multi4_o.vst’...


Capacitances on file ’multi4_o.vst’...

Delays on file ’multi4_o.vst’...5635 ps

Area on file ’multi4_o.vst’...218250 lamda? (with over-cell routing)

Details...

xr2_x1: 26 (26%)

...

ao2o22_x2: 1 (1%)

Total: 145

Worst RC on file ’multi4_o.vst’...321 ps

Inserting buffers on critical path for file ’multi4.vst’...6 buffers inserted -> 5409 ps

Improving RC on critical path for file ’multi4.vst’...5265 ps

Improving all RC for file ’multi4.vst’...

Worst RC on file ’multi4.vst’...321 ps

Area on file ’multi4.vst’...224500 lamda? (with over-cell routing)

Details...

xr2_x1: 26 (26%)

...

ao2o22_x2: 1 (1%)

Total: 151

Critical path (no warranty)...5265 ps from ’y 2’ to ’r 7’

Saving file ’multi4.vst’...

Saving critical path in xsch color file ’multi4.xsc’...

End of loon...

Antes de proceder a colocar nuestro diseno, lo probaremos con ASIMUT usando el archivo patron que usamospara verificar la descripcion comportamental producida por VASY. Para esto, agregamos las siguientes lıneas anuestro Makefile.

res_synth_1.pat : multi4.vst

$(ASIMUT) multi4 multi4 res_synth_1

Antes de ejecutar la simulacion, necesitamos ubicar o colocar la variable MBK CATAL LIB (todas las demas


no se necesita cambiarlas).

% setenv MBK_CATAL_LIB $TARGET_LIB

Por tanto ejecutamos ASIMUT usando el siguiente commando make (la salida ha sido promovida).

% make res_synth_1.pat

/usr/local/alliance/bin/asimut multi4 multi4 res_synth_1

@ @@@@ @ @ @@@@@@@@@@

@ @ @@ @@@ @ @@ @

@@@ @@ @ @ @ @@ @

@@@ @@@ @@@ @@ @@@ @@@ @@@@ @@

@ @@ @@@@ @@@@ @@@ @@ @@ @@ @@ @@

@ @@ @@@@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @@ @@ @@ @@ @@ @@ @@

@@@@@@@ @ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@

@ @@ @@@ @ @@ @@ @@ @@ @@ @@@ @@

@@@@ @@@@ @ @@@@ @@@@@@ @@@@ @@@ @@@ @@@@ @@ @@@@@@

A SIMUlation Tool





initializing ...

searching ‘multi4‘ ...

compiling ‘multi4‘ (Structural) ...

flattening the root figure ...

searching ‘ao2o22_x2‘ ...

BEH : Compiling ‘ao2o22_x2.vbe‘ (Behaviour) ...

making GEX ...

...

searching ‘buf_x2‘ ...

BEH : Compiling ‘buf_x2.vbe‘ (Behaviour) ...

making GEX ...

searching pattern file : ‘multi4‘ ...

restoring ...

linking ...

executing ...


...


Ahora podemos abrir el archivo .pat generado por ASIMUT y verificar que despues de cada cambio de senalla salida correcta es obtenida en el ciclo de 10ns utilizado en la entrada del archivo patron. El comando diffpermite verificar que la salida obtenida en esta oportunidad es identica a aquella cuando ASIMUT fue aplicada ala descripcion comportamental. Sin embargo debe tomarse en cuenta que en el caso del archivo comportamentalel retrazo usado por ASIMUT es cero y los unos usados anteriormente son los correspondientes a las celdasusadas en la implementacion del diseno. Ellos suman hasta 5.3ns (ver salida de LOON y el retrazo de latrayectoria crıtica), por tanto en el momento de cambiar las entradas, las salidas del diseno en los archivos patde salidas diferiran. Ahora estamos listos para colocar nuestro diseno usando OCP. Necesitamos agregar lassiguientes lıneas a nuestro Makefile y en este caso ninguna variable especial es necesaria (todas ellas son puestascorrectamente con todos los cambios hechos en los pasos previos).

OCP = $(ALLIANCE_BIN)/ocp

multi4_p.ap : res_synth_1.pat

$(OCP) -v -gnuplot -ioc multi4 multi4 multi4_p


Colocamos el diseno usando el siguiente comando (las salidas han sido recortadas para fijarlas).

% make multi4_p.ap

/usr/local/alliance/bin/ocp -v -gnuplot -ioc multi4 multi4 multi4_p

@@@ @@@@ @ @@@@@@@

@@ @@ @@ @@ @@ @@

@@ @@ @@ @ @@ @@

@@ @@ @@ @ @@ @@

@@ @@ @@ @@ @@

@@ @@ @@ @@@@@

@@ @@ @@ @@

@@ @@ @@ @@

@@ @@ @@ @ @@

@@ @@ @@ @@ @@

@@@ @@@@ @@@@@@





o ALLIANCE environment:

o ALLIANCE_TOP : /usr/local/alliance

o MBK environment:

o MBK_IN_LO : vst

...

o MBK_CATA_LIB : .


...



o Number total of instances is .... 151

o Number of instances to place is .... 151

o Number of instances already placed is .... 0

o Number of nets is .... 159

o Computing Initial Placement ...

o User Margin : 0.2

o Number of Rows : 10

o Width of the abutment box : 108

o Height of the abutment box : 100

o conspace : 13.5 1st connector : 6.75

o conspace : 13.5 1st connector : 6.75

o Initial Placement Computing ... done.

o Beginning global placement ....

o Initial RowCost = 73.6

o Initial BinCost = 88

o Initial NetCost = 14396

o Initial Cost = 1

o Computing Initial Temperature ...

Loop = 1, Temperature = 0.351534, Cost = 1.0917

RowCost = 65.2, BinCost = 156, NetCost = 14861

Success Ratio = 99.4941%, Dist = 1, Delta = 0.5

...

Loop = 49, Temperature = 5.62198e-05, Cost = 0.552694

RowCost = 34, BinCost = 60, NetCost = 7887.5

Success Ratio = 1.872%, Dist = 0.1, Delta = 0.590525

o Global Placement finished .....

o Gain for RowCost = 53.8043%

o Gain for BinCost = 31.8182%

o Gain for NetCost = 45.2105%

o NetCost Estimated = 7887.5

o Final Optimization in process ...

o Net Cost before Final Optimization... 8405.5

o Final Optimization succeeded ...

o Final Net Cost ..... 6358.5

o Final Net Cost Optimization ..... 24.3531%

o Total Net Optimization .... 55.8315%


gnuplot files created - in order to use them, please type :

..

gnuplot view.gpl

NO PREPLACEMENT GIVEN

o Destruction of DATABASE ....

El siguiente paso es enlazar el diseno usando NERO. Para esto, modificamos nuestro Makefile agregando las


siguientes lıneas.

NERO = $(ALLIANCE_BIN)/nero

multi4.ap : multi4_p.ap multi4.vst

$(NERO) -V -$(METAL_LEVEL) -p multi4_p multi4 multi4

El entorno que necesita NERO es casi el mismo que el utilizado por OCP, por tanto, esta vez no modificamosnada. Sin embargo, definimos una nueva variable para ubicar el numero de capas usadas en el enlazamiento oenrutamiento del diseno.

% setenv METAL_LEVEL 2

Por tanto, ahora ejecutamos NERO con el siguiente comando (las salidas han sido recortadas para fijarlas).

% make multi4.ap

/usr/local/alliance/bin/nero -V -2 -p multi4_p multi4 multi4

@@@ @@@ @@@@@@@

@@ @ @@ @@

@@@ @ @@ @@

@ @@ @ @@@@@ @@ @@ @@@

@ @@ @ @ @ @@ @@ @@ @@

@ @@ @ @@ @@ @@@@@ @@ @@

@ @@ @ @@@@@@@@@ @@ @@ @@ @@

@ @@ @ @@ @@ @@ @@ @@

@ @@@ @@ @ @@ @@ @@ @@

@ @@ @@ @@ @@ @@ @@ @@

@@@ @@ @@@@ @@@@@ @@@ @@@

Negotiating Router

Alliance CAD System 5.0 20040928, nero 5.0



S/N 20021117.1

o MBK environment :

MBK_IN_LO := vst

...

MBK_CATA_LIB := .


...


MBK_CATAL_NAME := CATAL

MBK_VDD := vdd

MBK_VSS := vss

MBK_SEPAR := .

o Loading netlist "multi4"...

o Loading layout "multi4_p"...

o Flattening layout...

o Flattening netlist...

o Building netlist dual representation (lofigchain)...

o Binding logical & physical views...

o Loading design into grid...

o Local routing stage.

- [ 158] (hp := 9) "r 0"

...

- [ 0] (hp := 192) "x 1"

o Routing stats :

- routing iterations := 314327

- re-routing iterations := 22122

- ratio := 6.57514%.

o Dumping routing grid.

o Saving MBK figure "multi4".

o Saving layout as "multi4"...

Ahora podemos verificar la correccion del diseno usando Cougar y LVX. Debemos colocar algunas variables


para ejecutar el primero.

% setenv RDS_TECHNO ../etc/techno-035.rds

% setenv RDS_TECHNO_NAME $RDS_TECHNO

% setenv MBK_IN_LO al

% setenv MBK_OUT_LO al

% setenv MBK_CATAL_LIB $TARGET_LIB

Modificamos nuestro Makefile adecuadamente y agregamos la relacion de dependencia correspondiente y elcomando respectivo.

COUGAR = $(ALLIANCE_BIN)/cougar

RDS_TECHNO = ../etc/techno-035.rds

multi4_e.al : multi4.ap

$(COUGAR) -v -ac multi4 multi4_e

Utilizamos el siguiente comando make:

% make multi4_e.al

/usr/local/alliance/bin/cougar -v -ac multi4 multi4_e

@@@@ @

@@ @@

@@ @

@@ @ @@@ @@@ @@@@ @@@@@@ @@@@ @@@ @@@

@@ @@ @@ @@ @@ @@ @@ @@ @ @@@ @@

@@ @@ @@ @@ @@ @ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @ @ @@@@@ @@

@@ @@ @@ @@ @@ @@@ @@ @@ @@

@@ @ @@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@@ @@@@@@ @@ @@@ @@

@@@@ @@@ @@@@ @@ @@ @@@ @@@@ @@ @@@@

@ @

@@@@@


Alliance CAD System 5.0 20040928, cougar 1.21





---> Parse technological file ../etc/techno-035.rds

RDS_LAMBDA = 24

RDS_UNIT = 80

RDS_PHYSICAL_GRID = 2

MBK_SCALE_X = 100

---> Extract symbolic figure multi4

---> Translate Mbk -> Rds

---> Build windows

<--- 288

---> Rectangles : 4895

---> Figure size : ( -100, -116 )

( 54100, 50116 )

---> Cut transistors

<--- 0

---> Build equis

<--- 170

---> Delete windows

---> Build signals

<--- 170

---> Build instances

<--- 246

---> Build transistors

<--- 0

---> Save netlist

<--- done !


<--- 4.5pF

Para extraer el archivo SPICE con Cougar cambiamos las siguientes variables.

% setenv MBK_IN_LO spi

% setenv MBK_OUT_LO spi


y colocar unas pocas nuevas:

% setenv SPI_MODEL $ALLIANCE_TOP/etc/spimodel.cfg

% setenv MBK_SPI_MODEL $SPI_MODEL

% setenv MBK_SPI_ONE_NODE_NORC "true"

% setenv MBK_SPI_NAMEDNODES "true"

y agregamos las siguientes lıneas para nuestro Makefile.

SPI_MODEL = $(ALLIANCE_TOP)/etc/spimodel.cfg

multi4_e.spi : multi4.ap

$(COUGAR) -v -ac multi4 multi4_e

Ahora podemos ejecutar Cougar otra vez usando el siguiente comando.

% make multi4_e.spi

/usr/local/alliance/bin/cougar -v -ac multi4 multi4_e

@@@@ @

@@ @@

@@ @

@@ @ @@@ @@@ @@@@ @@@@@@ @@@@ @@@ @@@

@@ @@ @@ @@ @@ @@ @@ @@ @ @@@ @@

@@ @@ @@ @@ @@ @ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @ @ @@@@@ @@

@@ @@ @@ @@ @@ @@@ @@ @@ @@

@@ @ @@ @@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@@ @@@@@@ @@ @@@ @@

@@@@ @@@ @@@@ @@ @@ @@@ @@@@ @@ @@@@

@ @

@@@@@


Alliance CAD System 5.0 20040928, cougar 1.21





---> Parse technological file ../etc/techno-035.rds

RDS_LAMBDA = 24

RDS_UNIT = 80

RDS_PHYSICAL_GRID = 2

MBK_SCALE_X = 100

---> Extract symbolic figure multi4

---> Translate Mbk -> Rds

---> Build windows

<--- 288

---> Rectangles : 4895

---> Figure size : ( -100, -116 )

( 54100, 50116 )

---> Cut transistors

<--- 0

---> Build equis

<--- 170

---> Delete windows

---> Build signals

<--- 170

---> Build instances

<--- 246

---> Build transistors

<--- 0

---> Save netlist

<--- done !


<--- 4.5pF

Ahora usaremos LVX para comparar la descripcion estructural de nuestro diseno con la primera que fue


extranda con Cougar. Debemos cambiar algunas variables de entorno tal como se muestra:

% setenv MBK_IN_LO vst

% setenv MBK_OUT_LO vst

Todas las demas variables son colocadas y procedemos a agregar las siguientes lıneas para nuestro Makefile.

LVX = $(ALLIANCE_BIN)/lvx

lvx.done : multi4.vst multi4_e.al multi4_e.spi

$(LVX) vst al multi4 multi4_e -f

$(TOUCH) lvx.done

y ejecutamos la comparacion de la siguiente manera:

% make lvx.done

/usr/local/alliance/bin/lvx vst al multi4 multi4_e -f

@@@@@@ @@@@ @@@ @@@@ @@@@

@@ @@ @ @@ @

@@ @@ @ @@ @

@@ @@ @ @@ @

@@ @@ @ @@

@@ @@ @ @@

@@ @@ @ @@@

@@ @@@ @ @@

@@ @ @@@ @ @@

@@ @ @ @ @@

@@@@@@@@@@ @ @@@ @@@@





***** Loading and flattening multi4 (vst)...

***** Loading and flattening multi4_e (al)...

***** Compare Terminals ..............

***** O.K. (0 sec)

***** Compare Instances ............

***** O.K. (0 sec)

***** Compare Connections ......................

***** O.K. (0 sec)

===== Terminals .......... 18

===== Instances .......... 151

===== Connectors ......... 812


touch lvx.done

Esto nos dice que las dos descripciones son identicas. A continuacion podemos usar DRUC para verificar lasreglas utilizadas en el diseno simbolico. Para poder hacerlo necesitamos definir una nueva variable y cambiaruna de las presentes:

% setenv RDS_TECHNO_SYMB ../etc/techno-symb.rds

% setenv RDS_TECHNO_NAME $RDS_TECHNO_SYMB

Tambien debemos agregar la variable relacionada, la definicion correspondiente y la relacion de dependencia


correspondiente a nuestro Makefile.

DRUC = $(ALLIANCE_BIN)/druc

RDS_TECHNO_SYMB = ../etc/techno-symb.rds

druc.done : lvx.done multi4.ap

$(DRUC) multi4

$(TOUCH) druc.done

luego podemos ejecutar DRUC con el siguiente commando:

% make druc.done

/usr/local/alliance/bin/druc multi4

@@@@@@@ @@@@@@@ @@@@ @

@@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @

@@ @@ @@ @@ @@@ @@@@ @@ @

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@@@@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@

@@ @@ @@ @@ @@ @@ @@ @

@@ @@ @@ @@ @@ @@@ @@ @@

@@@@@@@ @@@@@ @@@ @@@@ @@ @@@@

Design Rule Checker




Flatten DRC on: multi4

Delete MBK figure : multi4

Load Flatten Rules : ../etc/techno-symb.rds

Unify : multi4

Create Ring : multi4_rng

Merge Errorfiles:



End DRC on: multi4


Done

0

File: multi4.drc is empty: no errors detected.

touch druc.done

Esto nos dice que no existe violacion de reglas de diseno en nuestro trabajo. El siguiente paso es convertirnuestro diseno simbolico a uno real y para esto usamos S2R. Primero colocamos una variable como se indica:

% setenv RDS_TECHNO_NAME $RDS_TECHNO

Todas la demas variables son correctamente colocadas en este punto y agregamos las siguientes lıneas a nuestroMakefile.

S2R = $(ALLIANCE_BIN)/s2r

multi4.cif : druc.done

$(S2R) -v multi4


Ahora podemos ejecutar S2R como se muestra(la salida ha sido recortada para fijarla).

% make multi4.cif

/usr/local/alliance/bin/s2r -v multi4

@@@@

@ @@

@@ @@

@@@@@@ @@@ @@ @@@ @@@

@@ @ @ @@ @@@ @@

@@@ @ @@ @@

@@@@ @ @@

@@@@ @ @@

@ @@@ @ @ @@

@@ @@ @@@@@@ @@

@ @@@@@ @@@@@@@ @@@@





o loading technology file : ../etc/techno-035.rds

o loading all level of symbolic layout : multi4





with signal names,

without scotch.

--> post-treating model no2_x1

rectangle merging :

. RDS_NWELL .................................

. RDS_PWELL .................................

. RDS_NIMP .................................

. RDS_PIMP .................................

. RDS_ACTIV .................................

. RDS_POLY .................................

. RDS_ALU1 .................................

...

--> post-treating model tie_x0

rectangle merging :

. RDS_NWELL .................................

. RDS_PWELL .................................

. RDS_NIMP .................................

. RDS_PIMP .................................

. RDS_ACTIV .................................

. RDS_ALU1 .................................

--> post-treating model rowend_x0

rectangle merging :

. RDS_NWELL .................................

. RDS_ALU1 .................................

--> post-treating model multi4

ring flattenning :

. RDS_NWELL .................................

. RDS_NIMP .................................

. RDS_PIMP .................................

. RDS_ACTIV .................................

. RDS_POLY .................................

rectangle merging :

. RDS_NWELL .................................

. RDS_NIMP .................................

. RDS_PIMP .................................

. RDS_ACTIV .................................

. RDS_POLY .................................

. RDS_ALU1 .................................

. RDS_ALU2 .................................

. RDS_ALU3 .................................

o saving multi4.cif

o memory allocation informations

--> required rectangles = 4913 really allocated = 7

--> Number of allocated bytes: 298508

Lo anterior nos da un archivo cif de nuestro diseno lo cual puede ser visualizado usando dreal.

Bibliografıa

[1] C. S. Wallace, .A suggestion for a fast multiplier,”IEEE Trans. Electron. Comput., Vol. EC-13, No.1, pp.14-17, Feb., 1964.

[2] L. Dadda, ”Some schemes for parallel multipliers,”Alta Frequenza Vol. 34, pp. 349-356, December, 1965.

[3] Alberto Palacios Pawlovsky, .A new algorithm for the configuration of fast adder trees,”IEICE Trans. Fun-damentals Vol. E83-A, No.12, pp. 2426-2430, December, 2000.

87

Documents

Introduccion al Diseno˜ de Circuitos VLSI en CMOS 1 · Cap´ıtulo 1 Introducci´on a las Herramientas de Alliance El sistema de herramientas proporcionados por Alliance nos permite