Overview documentation for loadable targets.
This commit is contained in:
parent
9680de25cd
commit
d7fcd66826
|
|
@ -0,0 +1,61 @@
|
||||||
|
|
||||||
|
LOADABLE TARGETS
|
||||||
|
|
||||||
|
Icarus Verilog supports dynamically loading code generator modules to
|
||||||
|
perform the back-end processing of the completed design. The user
|
||||||
|
specifies on the command line the module to load. The compiler loads
|
||||||
|
the module (once the design is compiled and elaborated) and calls it
|
||||||
|
to finally handle the design.
|
||||||
|
|
||||||
|
Loadable target modules implement a set of functions that the core
|
||||||
|
compiler calls to pass the design to it, and the module in turn uses a
|
||||||
|
collection of functions in the core (the API) to access details of the
|
||||||
|
design.
|
||||||
|
|
||||||
|
LOADING TARGET MODULES
|
||||||
|
|
||||||
|
The target module loader is invoked with the ivl flag "-tdll". That
|
||||||
|
is, the DLL loader is a linked in target type. The name of the target
|
||||||
|
module to load is then specified with the DLL flag, i.e. "-fDLL=<path>".
|
||||||
|
|
||||||
|
|
||||||
|
LOADABLE TARGET MODULE API
|
||||||
|
|
||||||
|
The target module API is defined in the ivl_target.h header file. This
|
||||||
|
declares all the type and functions that a loadable module needs to
|
||||||
|
access the design.
|
||||||
|
|
||||||
|
|
||||||
|
PROCESSES
|
||||||
|
|
||||||
|
A process is an always or initial construct with its associated
|
||||||
|
statement. The target gets from the compiler an ivl_process_t object,
|
||||||
|
that holds the process type (always or initial) and the statement,
|
||||||
|
which is an ivl_statement_t.
|
||||||
|
|
||||||
|
All the interesting stuff happens in the ivl_statement_t object. This
|
||||||
|
is a generic object that represents any single Verilog statement. If
|
||||||
|
the statement is compound, then it also holds references to the
|
||||||
|
contained statements. The target module can access statements in any
|
||||||
|
way it chooses, once it is handed the process that contains the
|
||||||
|
statement.
|
||||||
|
|
||||||
|
|
||||||
|
EXPRESSIONS
|
||||||
|
|
||||||
|
In behavioral code (and some combinational code) expressions are
|
||||||
|
passed on to the target as ivl_expr_t objects. Each object is a node
|
||||||
|
in a tree that represents the expression from the source. All the
|
||||||
|
issues of width and sign are taken care of so that it is clear an easy
|
||||||
|
to know exactly what you have.
|
||||||
|
|
||||||
|
All expressions have a width, available with the ivl_expr_width()
|
||||||
|
function. Each node in an expression tree may have a different width,
|
||||||
|
the compiler figures out everything and eliminates the ambiguity.
|
||||||
|
|
||||||
|
All expressions are also "signed" or "unsigned" -- mostly
|
||||||
|
unsigned. The ivl_expr_signed() function returns true if the
|
||||||
|
expression node is signed. A node may be signed, for example, if it is
|
||||||
|
a reference to an integer or a signed wire. The compiler figures out
|
||||||
|
whether or not each node is signed, the target need not guess.
|
||||||
|
|
||||||
Loading…
Reference in New Issue