Este art铆culo describir谩 la instalaci贸n y el uso de software gratuito para modelar circuitos l贸gicos digitales en Verilog como una alternativa a los productos comerciales Incisve de Cadense y ModelSim de MentorGraphics. Comparaci贸n de simulaciones en ModelSim y Verilator. Tambi茅n se considerar谩 una metodolog铆a de verificaci贸n universal, UVM.
Instalaci贸n del software SystemC UVM
1. El verilador
Uno de los lenguajes de descripci贸n de hardware es verilog. Puedes escribir un m贸dulo en este idioma.
Por ejemplo, hay un esquema de contador:
Su c贸digo se ver谩 as铆:
reg [3:0]counter; always @(posedge clk or posedge reset) if(reset) counter <= 4'd0; else counter <= counter + 1'd1;
Despu茅s de la simulaci贸n, obtenemos las formas de onda:
Se puede ver que el siguiente valor, uno m谩s que el anterior, se escribir谩 en los registros del contador a lo largo del frente de la frecuencia del reloj.
Un m贸dulo escrito puede tener una estructura m谩s compleja, que ser谩 dif铆cil de verificar manualmente todos los estados de. Necesitaremos pruebas automatizadas. Para esto, es necesario desarrollar un entorno de prueba en uno de los lenguajes de programaci贸n. El entorno de prueba nos dar谩 la oportunidad de realizar una verificaci贸n funcional completa del dispositivo.
Para probar el c贸digo del proyecto, adem谩s de lenguajes como Verilog, SystemVerilog, Python (para escribir modelos), puede usar el lenguaje
SystemC . SystemC es un lenguaje de dise帽o y verificaci贸n a nivel de sistema para modelos a nivel de sistema implementado como una biblioteca C ++ de c贸digo abierto.
Una forma de verificar los m贸dulos Verilog usando SystemC es traducir los archivos Verilog a C ++. Ay煤danos con este verilador.
Verilator es el simulador HDL Verilog gratuito m谩s r谩pido que supera la mayor铆a de los simuladores comerciales. Verilator compila SystemVerilog sintetizado (por lo general, este no es el c贸digo del banco de pruebas), as铆 como algunas declaraciones de SystemVerilog y Synthesis en c贸digo C ++ o SystemC de subproceso 煤nico o multiproceso. Verilator fue dise帽ado para grandes proyectos donde el rendimiento de la simulaci贸n es primordial y es particularmente adecuado para generar modelos de procesadores ejecutables para equipos de desarrollo de software embebido. Verilator se utiliza para simular muchos dise帽os de puerta de enlace multimillonarios muy grandes con miles de m贸dulos y es compatible con muchos proveedores de tecnolog铆a IP, incluida la IP de Arm y todos los famosos proveedores de IP RISC-V.
Verilator puede no ser la mejor opci贸n si espera un reemplazo completo para NC-Verilog, VCS u otro simulador comercial de Verilog, o el simulador de comportamiento Verilog para un proyecto muy peque帽o. Sin embargo, si est谩 buscando una forma de portar Verilog sintetizado a C ++ o SystemC, y su equipo es libre de escribir solo c贸digo C ++, este es un compilador de Verilog gratuito para usted.
Para instalar la 煤ltima versi贸n en Ubuntu: descargue el archivo
desde el enlace desde el sitio oficial .
Instalar:
2. GTK Wave
GTKWave es un visor de forma de onda con todas las funciones y tambi茅n le permite convertir archivos de formato vcd a fst, m谩s conveniente y m谩s r谩pido.
Instalar:
sudo apt-get install gtkwave
3. SYSTEMC
Un lenguaje para dise帽ar y verificar modelos a nivel de sistema implementados en forma de una biblioteca C ++ de c贸digo abierto.
Como se mencion贸 anteriormente, verilator es compatible con systemc, por lo que debe crear un proyecto en el que el punto de referencia de prueba se describir谩 en systemc y los archivos de origen en verilog sintetizado. Para hacer esto, necesitamos las bibliotecas del compilador g ++ proporcionadas por Accelera. Accellera Systems Initiative es una organizaci贸n independiente y sin fines de lucro dedicada a crear, respaldar, promover y promover est谩ndares de dise帽o, simulaci贸n y verificaci贸n a nivel de sistema para su uso en la industria electr贸nica mundial.
Descargar el archivo:
http://accellera.org/images/downloads/standards/systemc/systemc-2.3.1a.tar.gzInstalar:
tar -xvf systemc-2.3.1a.tar.gz cd systemc-2.3.1a mkdir objdir sudo ./configure --prefix=/usr/local/systemc-2.3.1a/ sudo make sudo make install cd ../
4. UVM para SYSTEMC
Este art铆culo revisar谩 un proyecto que implementa herramientas de verificaci贸n UVM. La verificaci贸n es una confirmaci贸n de la conformidad del producto final con los requisitos de referencia predefinidos. Una de sus herramientas de verificaci贸n pueden ser las pruebas. Para ejecutar secuencias de prueba en modelos de dispositivos reales al nivel de descripciones RTL, es necesario desarrollar un entorno de prueba.
UVM - (Metodolog铆a de verificaci贸n universal) es una metodolog铆a de verificaci贸n universal, un est谩ndar que permite el desarrollo eficiente y la reutilizaci贸n de entornos de validaci贸n de bloque de IP. UVM es una metodolog铆a de verificaci贸n cuyas tareas incluyen organizar un entorno efectivo alrededor de la unidad bajo prueba. Sus ventajas:
- estructura clara en forma de bloques dedicados que deciden espec铆ficos
- tareas
- la capacidad de reutilizar bloques en proyectos posteriores;
- la m谩xima automatizaci贸n posible de la verificaci贸n;
- la informaci贸n de informes m谩s completa que permite, cuando ocurre un error, identificar sus causas de la manera m谩s r谩pida y precisa posible y sugerir soluciones.
Las metodolog铆as UVM constan de dos partes: un conjunto de reglas para construir un entorno de prueba y una biblioteca de bloques en blanco para verificaci贸n, por ejemplo, un generador de texto, un colector de estad铆sticas, etc. La principal ventaja de UVM es su versatilidad y compatibilidad con entornos de terceros.
Como systemc admite la metodolog铆a UVM, pasemos a instalar las bibliotecas necesarias.
Descargar el archivo:
https://www.accellera.org/images/downloads/drafts-review/uvm-systemc-1.0-beta2.tar.gzInstalar:
tar -xvf uvm-systemc-1.0-beta2.tar.gz cd uvm-systemc-1.0-beta2/ mkdir objdir sudo ./configure --prefix=/usr/local/systemc_uvm/ --with-systemc=/usr/local/systemc-2.3.1a sudo make sudo make install
Creamos una alianza:
sudo mkdir /usr/local/uvm_systemc_aliance
Copie el contenido de las carpetas / usr / local / uvm_systemc_aliance / y /usr/local/systemc-2.3.1/ a esta carpeta
Descargue el proyecto terminado en el enlace:
https://github.com/paprikun/SYSTEMC/Abra la carpeta de ejemplos de verilator.
La carpeta rtl contiene una descripci贸n del dispositivo. En este ejemplo, es un controlador PWM.
En el archivo makefile de la carpeta sim para construir el proyecto.
En la carpeta tb est谩 el c贸digo para el verificador. La carpeta tb / uvm contiene un ejemplo de entorno uvm. El archivo principal es un punto de entrada en las pruebas; conecta el dispositivo bajo prueba con el entorno uvm.
Intentamos construir el proyecto desde la carpeta sim con el comando make all. Vemos un error:
/usr/local/uvm_systemc_aliance//include/systemc.h:120:16: error: 'std::gets' has not been declared using std::gets;
Lo arreglamos reemplazando la l铆nea 120:
#if defined(__cplusplus) && (__cplusplus < 201103L) using std::gets; #endif
Una vez m谩s, intentamos ejecutar el banco de pruebas y tropezar con la advertencia:
/usr/local/uvm_systemc_aliance//include/sysc/packages/boost/get_pointer.hpp:21:40: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations] template<class T> T * get_pointer(std::auto_ptr<T> const& p)
Cambia auto_ptr a unique_ptr.
Proyecto de montaje y simulaci贸n
Ahora que las bibliotecas est谩n instaladas y funcionando, estamos construyendo el proyecto: hacer todo. El archivo ejecutable simu debe aparecer en la carpeta sim. Este es un objeto creado por el compilador. Comenzamos con el equipo ./simu. Deber铆a aparecer lo siguiente:
SystemC 2.3.1-Accellera --- Jun 28 2019 11:39:29 Copyright (c) 1996-2014 by all Contributors, ALL RIGHTS RESERVED Universal Verification Methodology for SystemC (UVM-SystemC) Version: 1.0-beta2 Date: 2018-10-24 Copyright (c) 2006 - 2018 by all Contributors See NOTICE file for all Contributors ALL RIGHTS RESERVED Licensed under the Apache License, Version 2.0 UVM_INFO @ 0 s: reporter [RNTST] Running test ... simulation real time = 9 sec UVM_INFO uvm_default_report_server.cpp(666) @ 179490249010 ps: reporter [UVM/REPORT/SERVER] --- UVM Report Summary --- ** Report counts by severity UVM_INFO : 1 UVM_WARNING : 0 UVM_ERROR : 0 UVM_FATAL : 0 ** Report counts by id [RNTST] 1 UVM_INFO @ 179490249010 ps: reporter [FINISH] UVM-SystemC phasing completed; simulation finished
Cuando finaliza la simulaci贸n, finaliza la grabaci贸n en forma de onda. El archivo simu.vcd se puede abrir con gtkwave:
Para mostrar las se帽ales a la izquierda, seleccione SystemC, luego manteniendo presionada la tecla May煤s, seleccione cualquier se帽al y haga clic en Anexar. La informaci贸n sobre herramientas aparece en la barra de herramientas cuando pasa el mouse por encima. El desplazamiento del mouse funciona, debe mantener presionada la tecla May煤s o Ctrl.
Tambi茅n hay formas de convertir este archivo a otro m谩s peque帽o.
Si hay modelosim har谩 la conversi贸n. En la terminal, ingrese el comando vsim. En el terminal modelsim:
vcd2wlf simu.vcd simu.wlf
O usando gtkwave en la terminal de Linux:
vcd2lxt simu.vcd simu.lxt vcd2lxt2 simu.vcd simu.lxt2
Para comparar el tiempo de simulaci贸n, se cre贸 un proyecto similar, pero ya para
Modelsim . Modelos de carpetasim_example. Del mismo modo creado entorno UVM. La sintaxis es similar a pesar del hecho de que hay diferentes idiomas. Si instal贸 Modelsim con soporte para uvm, puede ejecutar el comando make all.
Adem谩s del entorno en ambos proyectos, se tom贸 una simulaci贸n en tiempo real de las mediciones.
Con el tiempo, la diferencia result贸:
Como puede ver en la tabla, el verilador tiene una ventaja. Los datos se presentan para una PC con 8GB de RAM, un procesador de 8 n煤cleos, 800 MHz, cargando un n煤cleo.
Compare el tama帽o del archivo:
Aqu铆 el verificador pierde, pero puede experimentar creando formas de onda y trazar profundidad, el per铆odo de grabaci贸n (el comienzo y el final de la grabaci贸n de forma de onda se pueden cambiar). Con qu茅 archivo trabajar depende de usted.
Durante las pruebas, adem谩s del tiempo de la simulaci贸n en s铆, se encontr贸 una discrepancia en la lectura de los datos de entrada del bus. Si los datos del bus en el bus cambian durante el frente clk, Modelsim lee los datos despu茅s del frente, verificador antes:
input clk; input [7:0] in; reg [7:0] in_last_ ; ... always @(posedge clk) begin ... in_last_ <= in; ... end
Durante las pruebas, este punto debe tenerse en cuenta, ya que parte del entorno de prueba para diferentes simuladores funcionar谩 de manera diferente.
Adem谩s, el verificador no tiene en cuenta el estado "x" de la se帽al y traduce todo a "0";
BANCO DE PRUEBA UVM
Considere el entorno de prueba, la carpeta tb / uvm.
El banco de pruebas UVM es el entorno sobre el dispositivo. En este ejemplo, el dispositivo es un controlador PWM. Diagrama del entorno UVM:
Como puede ver en el diagrama, UVM consiste en bloques (clases). Cada bloque realiza sus funciones. El ejemplo muestra uno de los posibles dise帽os del entorno de prueba. El nombre y la funcionalidad de cada clase corresponde a la clase de la que se hereda. Consideremos cada clase con m谩s detalle.
Archivo de entorno env.h o env.svh. Esta es una clase que puede contener una o m谩s clases de agente, en las que se conectan tres clases: secuenciador, controlador, monitor. No hay agente en el ejemplo, pero su funci贸n se implementa en la clase env. Para la prueba necesitamos escribir alguna secuencia de acciones: secuenciaci贸n.
Pasemos al c贸digo de inicio de secuenciaci贸n:
sequence_[n]->start(sqr, NULL);
Secuenciador (secuenciador) - archivo sequncer.h. En el sistema verilog, result贸 utilizar el secuenciador predeterminado. Una clase que contiene una o m谩s secuencias (secuencia) (archivos secuencia_a.h, secuencia_a.svh). Cada secuencia es una cadena de acciones. Una de estas acciones puede ser enviar una transacci贸n. Transacci贸n: transferir datos de una clase a otra. La clase en la que se describen las transacciones es bus_trans. A continuaci贸n se muestra una descripci贸n de dos clases, cada una de las cuales ideol贸gicamente tiene sus propias funciones espec铆ficas: controlador y monitor.
Controlador: archivo drv.h, drv.svh. Una clase que recibe transacciones de un secuenciador y las traduce en se帽ales. El conductor sirve como asistente de secuenciador en un nivel inferior. Considere enviar un paquete.
La secuencia abre una ventana de transacci贸n, el controlador detecta este evento y comienza a recibir datos. La secuencia est谩 esperando una respuesta del conductor. El controlador simula las se帽ales para el dispositivo, luego le indica al secuenciador que la ventana se puede cerrar. La idea es que el secuenciador funcione a un nivel alto y el controlador a un nivel inferior.
Las se帽ales se conectan a trav茅s del bus de interfaz al dispositivo. La interfaz se describe en los archivos vip_if.h, vip_if.svh.
A continuaci贸n, debe verificar si las se帽ales de salida coinciden con las esperadas. Hay dos soluciones:
- Escribir un modelo para un dispositivo
- Verificaci贸n de se帽al a trav茅s del agente UVM
En el ejemplo, se considera la segunda opci贸n. Para probar el dispositivo a nivel funcional, es necesario comparar la salida con la esperada. El requisito para el dispositivo era la correcci贸n del ciclo de trabajo dado de la se帽al y el per铆odo de la se帽al. Para monitorear las se帽ales de salida, se escribe una nueva clase: Monitor (archivo monitor.h, monitor.svh). Por lo general, en un entorno de prueba, el monitor transfiere las se帽ales en la transacci贸n (a un nivel superior) y se env铆a a la clase de comparaci贸n: cuadro de indicadores.
En este ejemplo, las se帽ales se verifican de inmediato. En caso de discrepancia entre el valor esperado y el medido, la prueba se detiene.