Estoy buscando una alternativa UVM (SystemVerilog). Hay algunos documentos para esto y no sé si realmente es el futuro del estándar de simulación como UVM. ¿Cuál es tu opinión?

Answer 1

Python no es adecuado para aplicaciones que exigen alto rendimiento y capacidad. Es un lenguaje de secuencias de comandos que no es adecuado para entornos con grandes cantidades de subprocesos concurrentes, de eso se trata el hardware.

Si usted es un equipo de verificación de una persona que no necesita interactuar con nadie más, puedo ver el deseo de encontrar algo más, dada la curva de aprendizaje empinada de la UVM. Pero tan pronto como presente a otra persona, incluso si esa persona es la que se hace cargo de su código después de abandonar el proyecto, el beneficio de la UVM es abrumador. Ahora tiene una metodología estándar y documentada para ejecutar su prueba sin tener que inventar y documentar todo usted mismo.

A pesar de que el UVM parece excesivo, no hay razón para que tenga que aprender y usar todo. Si solo utiliza la base de datos de configuración y el mecanismo de informes del UVM, se ahorrará mucho trabajo.

Answer 2

Como señaló Elik Cohen, el futuro cercano parece estar con UVM. Muchas compañías se están moviendo hacia él y también los vendedores. La biblioteca ha recorrido un largo camino desde los días de VMM / OVM y lo empuja a trabajar de cierta manera.

Dicho esto, tengo algunos problemas con el proyecto UVM. Sí, las fuentes son visibles, lo que permite una fácil depuración, pero tiene una buena cantidad de errores. Intentar informar sobre un error y obtener una solución en la línea principal es una molestia. Hace que algunas empresas creen su propia capa para corregir errores, lo cual es una pena.

Las empresas de desarrollo ASIC y los proveedores de servicios de verificación tienen una cultura de código cerrado. Me encantaría ver más proyectos en github para colaboración en bibliotecas y marcos basados ​​en SystemVerilog. El desarrollo de un entorno de verificación se ha convertido en una tarea bastante elaborada de desarrollo de software.

Creo que se puede aprender mucho compartiendo datos y creando marcos de prueba, bibliotecas avanzadas, modularización y más. Impulsará a los proveedores de EDA aún más, haciéndolos corregir errores pendientes. También podría empujar a algunos ingenieros de verificación a trabajar juntos en otras herramientas como planificadores de verificación, registrar generadores de modelos y más.

Como Dave Rich señaló que UVM parece una exageración, pero al final del día, si crea una buena API y comparte sus clases correctamente, obtendrá un componente reutilizable. Mi mayor elogio después de dejar un lugar de trabajo anterior cuando recibí una llamada de un ex colega (Yossi Nivin te estoy mirando), afirmando que logró fácilmente reutilizar un agente que había escrito para otro proyecto.

He estado en una compañía donde utilizaron el enfoque de Greg London de mezclar C ++ con SystemVerilog. Fue un desastre. Al depurar el código, preferiría no tener que saltar entre idiomas. Hace las cosas mucho más complicadas. Una vez más, espero un futuro en el que los ingenieros de verificación y las empresas compartan más de su conocimiento en beneficio de todos.

Puede que nunca suceda, pero oye, uno puede soñar 🙂

Answer 3

SystemVerilog (IEEE 1800) es, con mucho, el lenguaje de modelado más utilizado para hardware sintetizable y software de verificación de comportamiento. UVM no es más que un conjunto de bibliotecas escritas en SystemVerilog, y es el marco de trabajo más utilizado tanto para la verificación de señal mixta analógica (AMS) como para la verificación de sistemas digitales en chip (SoC). Si desea adoptar el entorno más utilizado que dominará el mercado de diseño y verificación de IC en el futuro previsible, le recomendaría que se adhiera a SystemVerilog.

Dicho esto, hay alternativas. Verilog (IEEE 1364) sigue siendo una alternativa muy atractiva para la verificación de modelos complejos de diseño de circuitos integrados (se ha utilizado durante siglos antes de que SystemVerilog cobrara vida). SystemC (IEEE 1666) es una biblioteca probada basada en C ++, que junto con un simulador de lenguaje mixto es un excelente lenguaje de modelado para modelar y verificar sistemas. (Por cierto, UVM también se ha extendido a SystemC)

VHDL (IEEE 1076) es otro entorno excelente y probado para el diseño y la verificación.

Ha habido otros intentos de usar C ++, Python y varios otros lenguajes para modelar y verificar hardware. Algunos de ellos han sido extremadamente geniales y estimulantes. Ninguno ha florecido.

Answer 4

He experimentado con el sistema c en el banco de pruebas superior (basado en c ++ y usando pli) y el banco de pruebas UVM (sistema verilog)

Desde mi punto de vista, un lenguaje diferente tiene sus diferentes beneficios. Para UVM testbench, sería mucho más fácil verificar IP con restricción aleatoria y es muy popular crear una regresión basada en métrica de cobertura usando qusta / vcs / ncsim usando su editor de planes de prueba.

También UVM testbench ha separado la secuencia basada en eventos y su controlador por secuenciador. Con una secuencia virtual poderosa, puede agregar muchos casos con diferentes estímulos utilizando el mismo entorno mediante anulación de fábrica. La interfaz virtual le permite realizar el comportamiento del controlador y el monitor antes del diseño final.

Todo esto no es fácil en cuanto a systemC, aunque también tenemos la herencia en el lado systemC, ya que SOLO podemos acceder a la base de datos Verilog por pli o dpi.

Sin embargo, el banco de pruebas basado en systemC tiene sus beneficios en cuanto al nivel de chip completo, donde desde el escenario real solo tendremos el registro y el acceso a la memoria al chip además del modo de etiqueta en algunos chips MCU. Escribir un banco de pruebas C ++ aquí será más fácil para los expertos en software para mantener el controlador final en el sistema operativo. También puede tener un caso de prueba directamente para la emulación de simulación y el sistema operativo en chip simplemente cambiando el registro y la rutina de acceso a la memoria

Finalmente UVM es genial. Pero no podemos decir que sea el mejor en todos los aspectos de la verificación. Si quieres aprender bien UVM. Puede comenzar desde uvm_object y uvm_componet. Luego intente comprender la relación entre el secuenciador de secuencia y el controlador. Finalmente, al aprender el mecanismo de fábrica, puede comenzar su propio banco de pruebas

Answer 5

Trabajé en UVM durante un par de años. Comenzó pareciendo una buena idea. Pero después de un año más o menos, comencé a encontrar limitaciones.

Un gran problema para mí es la gran curva de aprendizaje. Muchas funciones de biblioteca para aprender. Otro problema fue la falta de modelos. Restringido al azar solo funciona si tienes un modelo dorado para comparar. Y los modelos siempre tuvieron que modificarse ya que encontramos excepciones a todas y cada una de las reglas. Otro problema era tratar de obtener más y más restricciones en un paquete para crear el caso específico al que estaba tratando de llegar, cada vez más difícil.

Nuestro entorno actual tiene verilog para el diseño. Tenemos algunos bloques testbench en verilog que tienen registros que controlan su comportamiento. Luego, una capa de DPI se conecta con el resto del banco de pruebas escrito en C ++.

Los bloques verilog testbench están diseñados para descargar los requisitos paralelos del software al hardware. Esto permite que las pruebas se escriban sin necesidad de cosas fork / join. En cambio, cargamos diferentes transacciones con datos y les decimos que se vayan. Entonces esperamos. Luego descargamos los resultados y los verificamos.

C ++ es un lenguaje estándar, por lo que la curva de aprendizaje es más fácil. También es un lenguaje más común, por lo que es más probable que las preguntas sean respondidas en foros públicos. (compárelo con UVM, que es extremadamente raro y no tendrá que buscar hasta encontrar otro tipo de UVM que esté luchando con el mismo problema).

Puede hacer clases, paquetes, objetos, instancias, mapas, vectores y todo lo demás, todo con construcciones estándar de C ++. No hay cosas de idiomas especiales para aprender.

Y lo mejor de todo, es GNU, por lo que no necesitamos una licencia adicional para el banco de pruebas.