Síntesis con HDL
Comentarios generales (y) de algunas herramientas específicas
Copyright (C) 2007 Fernando G. Tinetti
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 otras
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"