Síntesis con HDL


Comentarios generales (y) de algunas herramientas específicas

Due to "strange" and unexplained (at least for me) policies/changes  of this server, this page/site is out of date since Jun 2009. The new page/site with this content is


Copyright (C) 2007 Fernando G. Tinetti

Modelización a partir de HDL (no importa cuál)

En todos los casos se hace la especificación que corresponda y el módulo o como se llame que hace la prueba de la especificación en el mismo HDL. Esta prueba incluye los patrones de verificación, normalmente a nivel de E/S.

Como "valor agregado" se tiene una verificación de sintaxis de la especificación que indica que no hay ambigüedades (como en cualquier lenguaje de programación).

Se supone que en este punto se hace la verificación/simulación lógica, de los valores y señales involucradas en la especificación.

Síntesis a partir de HDL (no importa cuál)

1) Herramientas acopladas con Cadence (o que parecen):
Synopsys
BuildGates
Synplify

Synopsys y Synplify son de terceros, es decir que hay que comprarlos aparte y "acoplarlos". Esto además genera ciertas
complicaciones extras, debido al manejo de las licencias que tiene Cadence. BuildGates no es ajeno a este problema, pero
al menos la empresa de una herramienta no puede acusar a la otra de mal funcionamiento. Por otro lado, Europractice parece que incluye BuildGates y ya se tienen los tutoriales de estas herramientas.

2) Otras herramientas, de uso libre:
Alliance
Electric

Son mucho más sencillas y en cierto modo más prácticas (con menos tiempo de setup). Se desconocen "destinos de síntesis"
en cuanto a que se desconocen si los fabricantes que se tienen bajo Europractice proveen bibliotecas para las herramientas y/o funcionalidades que estas herramientas proveen.

3) Otras herramientas, propietarias:
De las empresas de FPGAs
De los "competidores" de Cadence

Se supone que en ambos casos debería haber un ciclo de diseño que incorpore HDLs como una de las etapas iniciales (o como la etapa inicial). En el caso de las empresas de FPGAs, lo más probable es que haya disponible un conjunto de hardware y/o software de desarrollo (kits de desarrollo) donde con lo que se pueda especificar y simular a partir de HDL llegue a la implementación sobre la propia FPGA o familia de FPGAs del fabricante que sea. En el caso de los competidores de Cadence, se tiene el mismo problema que con las herramientas de uso libre: se desconoce cómo llegar a la tecnología/fabricación que, nuevamente, es de otra empresa.


Para aprender HDL

En parte, se tiene una base general a partir de los lenguajes de programación procedurales y de los conocimientos imprescindibles de las tecnologías involucradas (ASICs y/o FPGAs). Todo parece indicar que ambos tipos de conocimientos
son necesarios para usar y aprovechar de manera efectiva los HDLs y al menos las herramientas de simulación que todos
estos lenguajes tienen. Como varios autores lo reconocen explícitamente, los HDLs fueron creados y siguen siendo utilizados primariamente como lenguajes de especificación y herramientas de simulación de hardware. Estas tareas en sí mismas reducen el tiempo de diseño/desarrollo y facilitan las tareas asociadas, aumentando significativamente la productividad. Sin embargo, desde hace varios años y dentro del proceso de automatización del desarrollo de hardware se han incorporado herramientas de síntetisis a partir de las especificaciones de/en HDLs.

Los HDLs no son necesariamente lenguages procedurales como C o Pascal, muchos autores indican que son más parecidos a ADA o algún otro lenguage concurrente. En realidad, en parte son ciertas todas estas afirmaciones, pero no completamente. Es decir: los HDLs han hecho un gran esfuerzo (bueno, no es claro si se esforzaron o fue y es una característica de facto propia de los HDLs) por asimilar construcciones, sintaxis y semántica de los lenguajes procedurales. Por otro lado, Ada tiene incorporado al lenguaje estructuras para procesamiento concurrente vía tasks, pero el rendezvous de Ada es demasiado estricto respecto a lo que puede suceder y de hecho sucede en hardware.

De hecho, quizás uno de los "problemas" (si se puede mencionar como tal) más serios de Ada al ser comparado con cualquier HDL es que, justamente, Ada incorpora la concurrencia. Las ideas de concurrencia en cualquier lenguaje de programación tienden a especificar/"capturar" las tareas que "podrían" suceder en paralelo, pero no necesariamente de manera simultánea. Esta es la idea básica de la concurrencia en los sistemas operativos y en muchos sistemas "embebidos" de menor escala. No se puede evitar, en cierto modo, hacer referencia a o tener en mente un procesador que hace "multitasking" entre las tasks definidas en Ada. Por otro lado, los HDLs tienden a asumir la simultaneidad por el tipo de "procesamiento" que se lleva a cabo a nivel de hardware y se debe hacer un esfuerzo muy explícito (y complejo, que es peor) para especificar "multitasking" con la idea subyacente de varios  procesos que comparten un elemento de procesamiento o procesador.

Más específicamente, el comportamiento de las señales en un circuito es muy dificil de ser "capturado" (o expresado o especificado) en un lenguaje de programación en general y en Ada en particular. De hecho, es por esto que se definieron y siguen utilizándose lenguajes específicos (HDLs), no lenguages de programación procedurales, o concurrentes, u orientados a objetos, o funcionales, etc.

Independientemente de las comparaciones con los lenguajes de programación "tradicionales", siempre es posible abocarse a la tarea de aprender un lenguaje de programación. Esto también se aplica a los lenguajes de descripción de hardware, y tiene en parte las complejidades propias de los lenguajes de programación más las complejidades de especificar hardware más las complejidades que surgen de esta "mezcla", si se quiere, de ideas subyacentes. En cierto modo, se debe convivir (y de hecho especificar y utilizar) el modelo de von Neumann que mantienen los lenguajes procedurales y, al mismo tiempo, con la idea subyacente del procesamiento de las señales que se llevan a cabo en los circuitos de hardware (y esto, además, se puede pensar y expresar en distintos niveles de abstracción, pero no se avanzará sobre esto ahora...). Esta tarea de aprendizaje parece más complicada si se toma como estrategia la idea de "paso a paso" para comprender cada estructura, sintaxis y semántica del lenguaje. Todo esto para justificar lo que es más o menos claro: conviene tomar tutoriales.

Los tutoriales disponibles se podrían clasificar en "orientados al lenguaje" y "orientados a la o las herramientas". Como es de sospechar, los orientados al lenguaje intentan mostrar de manera compendiada y acotada (no parecen ser compatibles ambas cosas...) todas las capacidades del lenguaje en cuanto a expresión y a simulación. Tienen de bueno que las herramientas que
utilizan tienden a ser de uso libre y son "replicables" (utilizables) en diferentes "compiladores" y simuladores del HDL que sea. Los orientados a las herramientas son más difíciles de sostener en cuanto a generalidad (como también era de sospechar), pero tienen varias ventajas:
a) Son mucho más específicos, no intentan mostrar todas las características/potencialidades del lenguaje, sino cómo se
hacen las cosas con las herramientas que se describen. En general, toman un ejemplo sencillo, lo especifican en el HDL
y continúan el ciclo de desarrollo a partir de allí.
b) Se describen herramientas o conjuntos de herramientas complejas, que en cierto modo siguen las complejidades del
lenguaje mismo. En cierta forma es preferible conocer las herramientas con detalle dado que a la hora de desarrollar en el contexto de producción se utilizará un conjunto bien delimitado de herramientas, no cualquiera (por múltiples razones, fuera del alcance de esta explicación) y conviene conocerlas lo antes posible. Más explícitamente: no hay muchos tutoriales que describan con detalle cada una de las herramientas que finalmente se utilizarán, sí hay muchos tutoriales que describen el lenguaje. Si hay algo del lenguaje que no se entiende, se puede recurrir a los manuales de referencia, a libros del lenguaje (hay varios y de autores muy respetados) o a múltiples tutoriales. No sucede lo mismo con las herramientas a utilizar en producción.
c) Las herramientas son mucho más específicas que el lenguaje, desde muchos puntos de vista. Uno de los más importantes, es el que corresponde a la integración de los HDLs con el resto del ciclo de desarrollo de hardware. Esta integración es casi imprescindible si se quiere llegar a la síntesis a partir de HDL.
d) Como es conocido y aceptado desde que se introdujeron las herramientas de síntesis, no todo lo que se puede especificar en un HDL se puede sintetizar, y podría decirse que la síntesis (lo que "se puede" o "no se puede" sintetizar) depende de las herramientas de síntesis, así que sería bastante complicado aprender un HDL de manera totalmente "independiente" de la síntesis y llegar luego a que se tienen que aprender los límites (que son bastantes, de hecho).


Tutoriales Relacionados de Cadence (o parecen)

Synthesis Rapid Adoption Kit (o Synthesis RAK), 182 pp.
Verilog Datapath Extension Reference, 106 pp.
Synthesis Place-and-Route (SP&R) Flow Guide, 104 pp.

El RAK parece el más apropiado para empezar, dado que: lo primero que tiene es Verilog y desde allí parece ir directo (bueno, directo es una forma de expresarlo) a la síntesis. El de Verilog Datapath Extension Reference no parece recomendable para comenzar por dos cosas: Extension y Reference. Para Cadence estas extensiones a Verilog hacen que se denomine Verilog-DP y lo hacen más apropiado para la síntesis integrada en su entorno. Pero para comenzar sin conocer al detalle el lenguaje no parece apropiado. Parece muy útil una vez que se conoce Verilog y se pudo sintetizar al menos algo sencillo. Por otro lado, la idea de Manual de Referencia parece descartarlo para aprender. Todo parece indicar que SP&R no es lo primero que se piensa/hace en desarrollo, así que parece apropiado no comenzar por el SP&R (el último de los tutoriales mencionados).

Del Synthesis RAK

Básicamente todo trata sobre el bg o bgx. El bg se podría decir que es la herramienta "original" o más sencilla y el bgx la más avanzada. Se supone que bgx es para aplicar funcionalidades extra específicamente en lo que se refiere a síntesis a partir de HDL. El tutorial tiene cuatro "módulos" (un término que tiende  aconfundir un poco): los dos primeros a realizarse sobre bg y los otros dos sobre bgx. Lista de comandos (en línea de comandos del OS):

cp -rf your_install_path/doc/syntut/RAK/RAK.tar.gz my_tutorial/.cd my_tutorial
gzip -dc RAK.tar.gz|tar -xvf -
INSTALL_LIB
bg_shell

Es posible que INSTALL_LIB requiera el uso de perl. El uso del comando bg_shell implica interfase de consola, no gráfica. Para interfase gráfica, el comando sería 

bg_shell -gui

pero al menos la primera parte será con línea de comandos y quizás sea mejor, dado que se explica cada paso con bastante detalle. A partir del comando bg_shell aparece el prompt de la consola de bg y se continúan con comandos dentro de esta consola. Estos comandos se pondrán en esta página precedidos con el signo > (son comandos del lenguaje de script TCL):

> source ../tcl/setup.tcl
> source $tcl_dir/set_globals.tcl
> source $tcl_dir/read_lib.tcl
> report_library
> source $tcl_dir/read_rtl.tcl
> do_build_generic
> check_netlist

Todos los comandos "source" corresponden a "scripts" a ser interpretados dentro de bg. De hecho, cada uno de los comandos dentro del source son comandos de bg. Tanto report_library como check_netlist son para mostrar información, no necesariamente son necesarios para sintetizar o para avanzar con la síntesis, sino para conocer algunos detalles de bg en cuanto a la sesión o al trabajo que se está llevando a cabo. Dentro del script tcl read_lib.tcl está la incorporación de las bibliotecas a utilizar en la síntesis. Las bibliotecas están en formato .tlf (Timing Library Format) o .alf (Ambit Library Format) y ambos formatos con "compatibles" con el formato .lib de Synopsis. Sin embargo, se aclara que si se tiene un .lib del fabricante se puede usar el comando syn2tlf que vieen con el propio Cadence y que convierte un formato (.lib) al otro (.tlf). El script read_rtl.tcl tiene una sucesión de comandos bg read_verilog que son los que incorporan una descripción verilog al proyecto a sintetizar. Si la especificación está hecha en vhdl el comando bg a usar es read_vhdl. Estos comandos no solamente incorporan especificaciones de HDL al proyecto a sintetizar sino que además al menos se verifica la sintaxis de las especificaciones.

A partir de este punto comienza lo que se llama "test synthesis" que sería algo así como lógica agregada al propio diseño que es usada con el propósito de verificar el funcionamiento correcto del diseño mismo desde la perspectiva de fabricación (eso es lo que entiendo ahora, ?eh?). En principio, bg tiene su propia manera de hacer/poner esta lógica sin utilizar metodologías más estándares como ATPG (Automatic Test Pattern Generation), boundary scan/JTAG o BIST. Toda esta parte de DFT (Design-For-Test) corresponde a lo que se denomina en bg como Setting Test Synthesis Assertions. En el tutorial ya está todo hecho en scripts (con muchas y variados comandos incluidos con sus correspondientes opciones) pero no queda claro si hay que pensar todas estas assertions desde cero o si son provistas por los fabricantes o cualquier intermedio entre éstos). Varias de estas assertions están relacionadas con la tecnología...

Sobre Verilog - QII - Analizador Lógico

QII tiene la posibilidad de simulación lógica y de timing. La simulación lógica no tiene en cuenta ningún tipo de hardware (como era de esperar) y la simulación física sí. En cualquier caso, el hardware (tipo/familia de FPGA o CPLD) se debe especificar al principio de la especificación de un proyecto, pero luego no se tiene en cuenta en la simulación lógica. Sí es
necesario para la simulación de tiempos y para la programación misma del dispositivo, por supuesto.

La comunicación por puerto paralelo entre el analizador lógico y la placa de desarrollo de la FPGA funciona normalmente, sin
problemas. Esto significa que se puede programar la FPGA desde el mismo simulador lógico con el que se puede medir lo que sucede en la FPGA/placa de desarrollo gracias al ruteo de los pines.

Tal como lo indica casi cualquier libro de HDL, se puede especificar no solamente el dispositivo sino que en el mismo HDL
se suele especificar el dispositivo que lo prueba, generando las entradas y analizando si es necesario las salidas. Esto
corresponde normalmente a la simulación lógica. En QII, todo está pensado directamente en función del dispositivo a implementar, donde la simulación no se hace a través de "otro" dispositivo sino usando las propias herramientas de simulación del QII. El problema es que no parece ser muy completo o útil, sobre todo porque no hay muchas alternativas a la hora de la generación de señales de entrada ni análisis de señales de salida.

Las señales de entrada para el dispositivo a simular se pueden generar de dos formas:
1) Señales periódicas, del tipo de las señales de clock, con los parámetros estándares: frecuencia, "duty" (%) y fase.
2) Señales "manuales", que se pueden ingresar valor por valor de manera textual o usando el "editor de señales" de QII.
Lamentablemente, ambas formas de ingresar estas señales parecen ser interactivas (al menos hasta ahora no hay información sobre alguna otra alternativa), con lo cual se "reduce" automáticamente la posibilidad de una simulación relativamente exhaustiva o con variaciones de cientos de valores de señales de entrada. Está claro que más allá de algunas decenas de valores, la tarea interactiva de ingreso de los datos lleva demasiado tiempo y aumenta la probabilidad de valores erróneos, bajando la productividad.

En principio, parecen haber varias alternativas:

1) Prueba sobre la misma FPGA. Se graba el dispositivo en la misma FPGA con QII en el analizador lógico. La idea es que con el mismo analizador lógico se generan las entradas para el dispositivo (salidas del analizador) y las salidas del dispositivo /entradas del analizador). A favor: se utiliza/verifica/prueba el dispositivo tal como estará funcionando en producción. En contra: se necesita hardware de generación de señales en el analizador y también es relativamente complicada la asociación/verificación: señal/es de entrada <---> señal/es de salida
2) Generación de múltiples señales periódicas. En este caso, la idea es utilizar lo que sí se puede variar paramétricamente en el generador de señales de simulación de QII. Es decir que deberían pensarse las señales de entrada en términos de
ciclo - duty - fase
para generar, por ejemplo, todas las combinaciones de patrones de entrada. Si bien las señales no serán aleatorias (tal como pueden ser las señales de entrada en producción), sí se podría hacer una simulación exhaustiva de las posibilidades de entrada. Esto suponiendo que la verificación exhaustiva sea un problema "tratable" (recordar que con n señales de entrada se tienen 2^n posibles valores, es decir que es exponencial).
En cualquier caso, esta posibilidad es tanto para simulación lógica como para simulación de timing, es decir que no es necesario grabar nada en la FPGA. Por otro lado, sigue teniendo como factor en contra que no es sencillo asociar una entrada en particular con la salida que le corresponde.
3) Programar la FPGA con el dispositivo y el dispositivo que lo prueba. Se puede dejar, por ejemplo, una única señal de entrada para el clock. De hecho, generar una señal periódica (tal como un clock) es lo único que actualmente se conoce que se puede generar desde el analizador lógico. Por lo tanto, se puede hacer que tanto el probador del dispositivo como el dispositivo mismo tengan la misma señal de clock de entrada que, de hecho, será la generada por el analizador lógico.
La ventaja en este caso es que se puede simular lógicamente, se puede simular el timing y también, dependiendo de la capacidad de la FPGA se puede programar todo esto para que sea verificado en la misma FPGA. Uno de los problemas es que se "restringe" el dispositivo y la prueba del mismo a algo sincrónico, con referencia de un ciclo de reloj (no se podría hacer un diseño "estrictamente combinatorio", como muchos de los primeros ejemplos de los tutoriales de Verilog). No queda muy claro si esta restricción es realmente un problema o si en realidad todo lo que se termina haciendo como dispositivos (en FPGAs en producción) en realidad siempre incluyen una señal de reloj respecto de la cual se llevan a cabo todas las tareas/cambios de estado/eventos/etc. 

Dado que parece conveniente hacer algo así como un tutorial completo desde HDL hasta la medición de un dispositivo (FPGA) con un analizador lógico, toda esa "cascada de desarrollo" va a estar en otra página web, para no hacer tan extensa ésta y también para poner todo eso como un ejemplo relativamente completo de desarrollo desde un lenguaje de descripción de hardware hasta la implementación medida sobre una FPGA específica.

Sugerencias/reporte de errores/etc.: por favor envíe un e-mail a ftinetti @ gmail . com con con subject "Síntesis con HDL"