intel/device-modeling-languageLenguaje de dominio específico para escribir modelos rápidos de dispositivos funcionales para plataformas virtuales. Compila DML a C con llamadas API adaptadas para el simulador Intel Simics, lo que permite la simulación de hardware y las pruebas de seguridad.
El Lenguaje de Modelado de Dispositivos (DML) es un lenguaje específico de dominio para escribir modelos de dispositivos funcionales o a nivel de transacción rápidos para plataformas virtuales. DML proporciona abstracciones de alto nivel adecuadas para modelos funcionales de dispositivos, incluyendo construcciones como bancos de registros, registros, campos de bits, publicación de eventos, interfaces entre modelos y registro de eventos (logging). El código DML es compilado por el Compilador DML (DMLC), produciendo código C con llamadas a la API adaptadas para un simulador particular.
Actualmente, el compilador soporta la construcción de modelos para el simulador Intel® Simics®, pero otros back-ends pueden añadirse en el futuro.
Para construir DMLC, necesitas tener una instalación del simulador Simics y un proyecto Simics configurado.
Si aún no tienes una instalación del simulador Simics o acceso al simulador Simics a través de canales comerciales, instala la Versión Pública del simulador Intel Simics y crea un proyecto Simics (automático en el flujo de instalación predeterminado).
En tu proyecto Simics, clona el repositorio DML en el directorio modules/dmlc. En el nivel superior del proyecto, ejecuta make dmlc
(o bin\make dmlc en Windows).
Para ejecutar las pruebas unitarias proporcionadas con DMLC, ejecuta make test-dmlc o
bin/test-runner --suite modules/dmlc/test desde el nivel superior del proyecto.
Las siguientes variables de entorno son útiles al desarrollar DMLC. Si trabajas regularmente con un DMLC construido localmente, considera establecer las variables DMLC_DIR, T126_JOBS, DMLC_PATHSUBST y PY_SYMLINKS en tu .bashrc. El resto de variables es mejor habilitarlas solo cuando sea necesario.
Después de construir DMLC, necesitas establecer DMLC_DIR en <tu-proyecto>/<tipo-de-anfitrión>/bin
en invocaciones posteriores de make para construir dispositivos con el compilador construido localmente. <hosttype> es linux64 o win64 dependiendo de tu tipo de anfitrión.
Cuando se establece, el número dado de pruebas se ejecutan en paralelo.
La construcción de DMLC copia algunos archivos de la biblioteca DML, por ejemplo dml-builtins.dml, en
<hosttype>/bin. Cuando ocurre un error de compilación, los mensajes de error normalmente apuntarán
a esta copia en lugar de a la fuente. Al establecer DMLC_PATHSUBST en
<hosttype>/bin/dml=modules/dmlc/lib, los mensajes de error se reescribirán para apuntar
al archivo fuente en su lugar. <hosttype> es linux64 o win64 dependiendo de tu tipo de anfitrión.
Cuando se establece en 1, make dmlc creará enlaces simbólicos a los archivos Python en lugar de copiarlos. Esto tiene dos efectos: los tracebacks de Python te llevarán al archivo fuente en el repositorio, y no necesitarás volver a ejecutar make después de editar archivos Python.
Cuando se establece en 1, las excepciones inesperadas en el compilador se muestran en stderr. El valor predeterminado es ocultar los tracebacks en un archivo dmlc-error.log.
Sobrescribe el compilador predeterminado en las pruebas unitarias.
Cuando se establece, DMLC realiza autoperfilado y escribe el perfil en un archivo .prof.
Cuando se establece, DMLC genera un archivo .tar.bz2 que contiene todos los archivos fuente DML, empaquetados en un formato que puede compilarse de forma independiente. Esto es útil cuando aparece un problema de DML dentro de un entorno de compilación complejo, y deseas reproducir el problema de forma aislada. En el archivo creado, todos los archivos DML están ubicados en el mismo directorio (ya sea en el nivel superior o bajo una serie de subdirectorios llamados _), y las importaciones relativas se manejan incluyendo también enlaces simbólicos en el archivo. En Windows, DMLC a veces no puede resolver estos enlaces simbólicos correctamente; por esta razón, se recomienda que el archivo solo se extraiga y compile en Linux.
Cuando se establece, DMLC genera un archivo que termina en -size-stats.json, el cual muestra estadísticas de generación de código útiles para reducir el tamaño del código generado y aumentar la velocidad de compilación. El archivo enumera cuánto código C se genera para cada método DML. La salida es una lista de tripletes [tot_size, location, num], donde tot_size es el número total de bytes de código C generado a partir de una declaración de método, num es cuántas veces se generó código C a partir de esta declaración (porque fue expandida por una plantilla), y location es la ubicación fuente de la declaración.
Una entrada con un tot_size grande y un num grande puede reducirse declarando el método como shared; esto debería dividir aproximadamente el tamaño por num. Una entrada con un tot_size grande con num igual a 1 generalmente significa que el método está dominado por una construcción como #foreach o #select, y puede reducirse extrayendo el cuerpo del bucle en un método separado, o reestructurando el bucle en alguna otra construcción como foreach.
Ten en cuenta que las estadísticas solo incluyen código generado directamente a partir de declaraciones de método; el tamaño total del código incluye mucho más. Un megabyte de tamaño de código proveniente de declaraciones de método generalmente contribuye con unos pocos segundos de tiempo de compilación.
