e es un lenguaje de verificación de hardware (HVL) que está diseñado para implementar bancos de prueba de verificación altamente flexibles y reutilizables .
Paradigma | Orientado a aspectos |
---|---|
Diseñada por | Yoav Hollander |
Apareció por primera vez | 1992 |
Lanzamiento estable | IEEE 1647-2016 / 6 de enero de 2017 |
Extensiones de nombre de archivo | .mi |
Sitio web | TWiki @ eda.org |
Historia
e fue desarrollado por primera vez en 1992 en Israel por Yoav Hollander para su software Specman . En 1995 fundó una empresa, InSpec (más tarde rebautizada como Verisity ), para comercializar el software. El producto se presentó en la Conferencia de Automatización de Diseño de 1996 . [1] Verisity ha sido adquirido por Cadence Design Systems .
Características
Las principales características de e son:
- Generación de estímulos aleatorios y restringidos
- Definición y recopilación de métricas de cobertura funcional
- Lenguaje temporal que se puede utilizar para escribir afirmaciones.
- Lenguaje de programación orientado a aspectos con capacidad de reflexión
- El lenguaje es DUT-neutral en el sentido de que puede usar un solo banco de pruebas electrónico para verificar un modelo SystemC / C ++, un modelo RTL, un modelo de nivel de puerta o incluso un DUT que reside en una caja de aceleración de hardware (usando la Aceleración UVM para la Metodología e )
- Puede crear código altamente reutilizable, especialmente cuando el banco de pruebas está escrito siguiendo la Metodología de Verificación Universal (UVM)
- Anteriormente conocida como e Re-use Methodology ( e RM)
- La biblioteca y la documentación de UVM e se pueden descargar aquí: UVM World
Funciones de idioma
El lenguaje e utiliza un enfoque de programación orientada a aspectos (AOP), que es una extensión del enfoque de programación orientada a objetos para abordar específicamente las necesidades requeridas en la verificación funcional. AOP es una característica clave que permite a los usuarios incorporar fácilmente funcionalidades adicionales al código existente de una manera no invasiva. Esto permite una fácil reutilización y mantenimiento del código, lo que es un gran beneficio en el mundo del hardware, donde los diseños se modifican continuamente para satisfacer las demandas del mercado durante todo el ciclo de vida del proyecto. AOP también aborda preocupaciones transversales (características que atraviesan varias secciones del código) fácilmente al permitir que los usuarios extiendan instancias específicas o todas de una estructura en particular para agregar funcionalidad. Los usuarios pueden extender varias estructuras para agregar funcionalidad relacionada con una característica en particular y agrupar las extensiones en un solo archivo si lo desean, proporcionando una partición de archivos más organizada.
Comentarios
El código e ejecutable se incluye entre los marcadores de segmento de código <'y'>:
Ejemplo
Todo lo que esté fuera de los marcadores es un comentario.<'extender sys { // Este es un comentario al estilo Verilog - Este es un comentario en estilo VHDL post_generate () también es { out ("... y todo lo demás dentro de los marcadores es código ejecutable."); };};'>
Clases
e también tiene dos tipos de clases:
- Las clases dinámicas están etiquetadas con la palabra clave "estructura". Las estructuras se utilizan para crear datos que solo existen temporalmente y pueden ser limpiados por el recolector de basura.
- Las clases estáticas están etiquetadas con la palabra clave 'unidad'. Las unidades se utilizan para crear la estructura del banco de pruebas permanente.
Una clase puede contener campos, métodos, puertos y restricciones. Los campos pueden ser de tipo integer, real, enum, string e incluso objetos complejos. El segmento de código muestra una unidad llamada 'environment_u' siendo instanciada dentro de la raíz e 'sys'. Esta clase environment_u contiene una lista de 5 objetos packet_s y esta clase packet_s contiene dos campos y un método.
Ejemplo
<'// Esta es una clase dinámica con dos camposstruct packet_s { campo0: uint (bits: 32); // Este campo se llama 'campo0' y es un // Entero sin signo de 32 bits de ancho. campo1: byte; // Este campo se llama 'campo1' y es un byte. // Este método se llama una vez que se ha generado un objeto packet_s post_generate () también es { fuera (campo0); // Imprimiendo el valor de 'field0' };};// Esta es una clase estática con una lista de estructura de cinco paquetesunit environment_u { my_pkt [5]: lista de paquetes_s;};// sys es la raíz de cada entorno e y crea una instancia del objeto 'test_env'extender sys { test_env: environment_u es instancia;};'>
Aleatorización
En e, cada campo es aleatorio por defecto. La aleatorización de campo puede controlarse mediante restricciones estrictas, restricciones suaves o incluso desactivarse por completo. Las restricciones blandas se utilizan como restricciones predeterminadas y la capa de prueba puede anularlas automáticamente si se produce un conflicto. De lo contrario, se comporta como una restricción regular.
Ejemplo
<'struct my_pkt_s { dirección_destino: uint (bits: 48); // este campo es aleatorio y no está restringido. data_payload: lista de bytes; ! campo_paridad: uint (bits: 32); // '!' evita que el campo parity_field sea aleatorio. mantener soft data_payload.size () en [64..1500]; // una restricción suave, utilizada para proporcionar una aleatorización predeterminada mantener data_payload.size () no en [128..256]; // esta es una restricción dura};'>
Afirmaciones
e apoya las afirmaciones con expresiones temporales. Una expresión temporal se usa al mismo nivel sintáctico que los campos y métodos y, por lo tanto, es declarativa por naturaleza. Una expresión temporal describe un comportamiento cronometrado.
Ejemplo
<'unit temporal_example_u { evento a; // declarando un evento 'a' evento b; // declarando un evento 'b' evento c; // declarando un evento 'c' // Esta afirmación espera que el siguiente ciclo después del evento // se ha detectado que ocurre el evento b seguido del evento c. esperar @a => {@b; @c}};'>
Cobertura
e es compatible con la cobertura que están agrupados según su caso muestreado y esos grupos están estructurados internamente con artículos. Los elementos pueden ser elementos simples o elementos complejos, como elementos cruzados o elementos de transición.
Ejemplo
unidad de cobertura_ejemplo_u { event cov_event_e; // la recopilación de cobertura estará vinculada a este evento cover cov_event_e es { elemento a: uint (bits: 4); // este artículo tiene 16 cubos de 0 a 15 artículo b: bool; // este elemento tiene dos cubos: VERDADERO y FALSO cruzar a, b; // este elemento contiene una matriz de multiplicación cruzada de ayb trans b; // este artículo se deriva del artículo by tiene cuatro cubos // transición de cada combinación VERDADERO - FALSO };};
Mensajería e informes
La mensajería dentro de e se puede realizar con varios métodos.
Ejemplo
unit message_example_u { example_message_method () es { out ("Este es un mensaje de salida incondicional y sin formato."); outf ("Este es un mensaje de salida formateado incondicional que se muestra en HEX% x", 15); imprimir "Este es un mensaje incondicional."; mensaje (BAJO, "Este es un mensaje condicional, generalmente vinculado a un registrador de mensajes.", "También puede concatenar cadenas como esta e incluso agregar objetos como", yo, "en esta salida". ); messagef (LOW, "Esta salida condicional tiene el formato% x.", 15); };};
Interfaz con otros idiomas
Es probable que un banco de pruebas electrónico se ejecute con RTL o modelos de nivel superior. Teniendo esto en cuenta, e es capaz de interactuar con VHDL , Verilog , C , C ++ y SystemVerilog .
Ejemplo de una conexión e <-> Verilog
// Este código está en un archivo Verilog tb_top.v module testbench_top ; reg a_clk ; siempre # 5 a_clk = ~ a_clk ; inicio inicial a_clk = 0 ; final endmodule
Este código está en un archivo signal_map.e<'unit signal_map_u { // Defina un puerto llamado 'a_clk_p' a_clk_p: en simple_port de bit es instancia; // Establezca la propiedad hdl_path del puerto para que apunte a la señal 'a_clk' en el banco de pruebas de nivel superior mantener a_clk_p.hdl_path () == "~ / testbench_top / a_clk";};'>
Soporte de programación orientada a aspectos en e
El proceso de verificación funcional requiere elevar el nivel de abstracción de cualquier diseño bajo prueba (DUT) más allá del nivel RTL. Esta necesidad exige un lenguaje que sea capaz de encapsular datos y modelos, que esté fácilmente disponible en lenguajes orientados a objetos. Para hacer frente a esta necesidad ha sido diseñado para ser e un lenguaje orientado a objetos y en la parte superior de la que ha sido aumentada con mecanismos orientadas a aspectos que no sólo facilitan la escritura de bancos de pruebas altamente flexibles y reutilizables, sino que también ayuda verificación ingenieros, permitiendo al parche descubrieron RTL errores sin tener que reescribir o tocar ninguno de los códigos base ya existentes.
La programación orientada a aspectos en e permite a los ingenieros de verificación estructurar su banco de pruebas en aspectos. Por tanto, un objeto es la suma de todos sus aspectos, que pueden distribuirse en varios archivos. Las siguientes secciones ilustran los mecanismos básicos orientados a aspectos en e.
Mecanismo de subtipificación
La subtipificación es el mejor ejemplo de lo que los lenguajes orientados a objetos sin características orientadas a aspectos no pueden lograr. El subtipo permite a un ingeniero de verificación agregar funcionalidad a una clase ya definida / implementada sin tener que derivar de una clase base. El siguiente código muestra la implementación original de una clase base y cómo se extiende. Una vez que se llevó a cabo la extensión, todos los objetos de clase base también contienen las extensiones. Las restricciones dadas en los dos subtipos diferentes generalmente causarían una contradicción, sin embargo, ambos subtipos se manejan por separado y, por lo tanto, cada subtipo produce un cálculo de restricción diferente.
Ejemplo de mecanismo de subtipificación
subtyping_example.e<'// Esta definición de tipo de enumeración se usa para declarar los subtipos ODD y EVENescriba ctrl_field_type_t: [IMPAR, PAR];unit base_ex_u { // El subtype_field es el campo determinante al que se está aplicando el cálculo subtype_field: ctrl_field_type_t; palabra_datos: uint (bits: 32); parity_bit: bit; // Subtipado del tipo ODD cuando ODD'subtype_field base_ex_u { // Esta es una restricción simple que aplica XOR al bit de índice 0 de data_word e incrementa ese valor mantener parity_bit == (palabra_datos [0: 0] ^ palabra_datos [0: 0] + 1); }; // Subtipado del tipo PAR cuando EVEN'subtype_field base_ex_u { // Esta restricción es la misma que la anterior, sin embargo, el incremento no se realiza mantener parity_bit == (palabra_datos [0: 0] ^ palabra_datos [0: 0]); };};'>
Ampliación de métodos
La definición de unidad original se da en file1.e. El mecanismo orientado a aspectos utilizado en este ejemplo muestra cómo ejecutar código antes y después de un método ya implementado.
Ejemplo de extensión de método
Este código está en el archivo1.e<'unit aop_example_u { meth_ext () es { out ("Esta es la implementación del método original"); };};'>
Este código está en file2.e<'extender aop_example_u { meth_ext () es el primero { out ("Esta extensión de método se ejecuta antes de la implementación del método original."); }; meth_ext () también es { out ("Esta extensión de método se ejecuta después de la implementación del método original."); };};'>
Referencias
- The e Hardware Verification Language , Sasan Iman y Sunita Joshi, Springer, 28 de mayo de 2004
- Programación orientada a aspectos con el lenguaje de verificación electrónica , David Robinson, 2007
Fuentes
- El blog de idiomas electrónicos (Team Specman)
- http://www.eda.org/twiki/bin/view.cgi/P1647/WebHome IEEE 1647
- http://www.deepchip.com/items/0488-05.html (buenos comentarios de los usuarios sobre sus experiencias con el lenguaje e)
- http://www.cadence.com/products/functional_ver/specman_elite/index.aspx
- http://www.us.design-reuse.com/articles/article5646.html
- Janick Bergeron: Writing Testbenches: Functional Verification of HDL Models , Second Edition, Kluwer Academic Publishers, 2003, ISBN 1-4020-7401-8
- https://web.archive.org/web/20070405162901/http://amiq.ro/eparser.html
- http://www.thinkverification.com/
- http://www.dvteclipse.com/help.html?documentation/e/index.html