The Device Modeling Language (DML) is a domain-specific language for writing fast functional or transaction-level device models for virtual platforms. DML provides high-level abstractions suitable for functional device models, including constructs like register banks, registers, bit fields, event posting, interfaces between models, and logging. DML code is compiled by the DML Compiler (DMLC), producing C code with API calls tailored for a particular simulator.
Currently, the compiler supports building models for the Intel® Simics® simulator, but other back-ends may be added in the future.
To build DMLC, you need to have a Simics simulator installation and a Simics project set up.
If you do not already have a Simics simulator installation or access to the Simics simulator via commercial channels, install the Public Release of the Intel Simics simulator and create a Simics project (automatic in the default installation flow).
In your Simics project, check out the DML repository into the modules/dmlc
directory. At the top-level of the project, do make dmlc
(or bin\make dmlc
on Windows).
To run the unit tests provided with DMLC, run make test-dmlc
or
bin/test-runner --suite modules/dmlc/test
from the top-level
of the project.
The following environment variables are handy when developing DMLC. If you work
regularly with a locally built DMLC, then consider setting the variables
DMLC_DIR
T126_JOBS
, DMLC_PATHSUBST
and PY_SYMLINKS
in your
.bashrc
. Remaining variables are better to only enable when needed.
After building DMLC, you need to set DMLC_DIR
to <your-project>/<hosttype>/bin
in subsequent invocations of make
in order to build devices with the locally
build compiler. <hosttype>
is either linux64
or win64
depending on your
host type.
When set, the given number of tests are run in parallel.
The DMLC build copies a few DML library files, e.g. dml-builtins.dml
, into
<hosttype>/bin
. When a compile error happens, error messages will normally point
to this copy rather than the source. By setting DMLC_PATHSUBST
to
<hosttype>/bin/dml=modules/dmlc/lib
, error messages will be rewritten to point
to the source file instead. <hosttype>
is either linux64
or win64
depending on your host type.
When set to 1
, make dmlc
will symlink Python files instead of copying
them. This has two effects: Python tracebacks will bring you to the source file
in the repository, and you don't need to re-run make
after editing Python
files.
When set to 1
, unexpected exceptions in the compiler are echoed to
stderr. The default is to hide tracebacks in a file dmlc-error.log
.
Override the default compiler in unit tests.
When set, DMLC does self-profiling and writes the profile to a .prof file.
When set, DMLC emits a .tar.xz
archive containing all DML source files,
packaged on a form that can be compiled standalone. This is useful when a DML
problem appears within a complex build environment, and you want to reproduce
the problem in isolation. In the created archive, all DML files are located in
the same directory (either top level or under a series of subdirectories called
_
), and relative imports are handled by also including symlinks in the
archive. On Windows, DMLC is sometimes unable to resolve these symlinks
correctly; for this reason, it is recommended that the archive is only
extracted and compiled on Linux.