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