86 lines
2.8 KiB
Plaintext
86 lines
2.8 KiB
Plaintext
|
|
ATTRIBUTE NAMING CONVENTIONS
|
|
|
|
Attributes that are specific to Icarus Verilog, and are intended to be
|
|
of use to programmers, start with the prefix "ivl_".
|
|
|
|
Attributes with the "_ivl_" prefix are set aside for internal
|
|
use. They may be generated internally by the compiler. They need not
|
|
be documented here.
|
|
|
|
ATTRIBUTES TO CONTROL SYNTHESIS
|
|
|
|
The following is a summary of Verilog attributes that Icarus Verilog
|
|
understands within Verilog source files to control synthesis
|
|
behavior. This section documents generic synthesis attributes. For
|
|
target specific attributes, see target specific documentation.
|
|
|
|
These attributes only effect the behavior of the synthesizer. For
|
|
example, the ivl_combinational will not generate an error message
|
|
if the Verilog is being compiled for simulation. (It may generate a
|
|
warning.)
|
|
|
|
|
|
* Attributes for "always" and "initial" statements
|
|
|
|
(* ivl_combinational *)
|
|
|
|
This attribute tells the compiler that the statement models
|
|
combinational logic. If the compiler finds that it cannot make
|
|
combinational logic out of a marked always statement, it will
|
|
report an error.
|
|
|
|
This attribute can be used to prevent accidentally inferring
|
|
latches or flip-flops where the user intended combinational
|
|
logic.
|
|
|
|
(* ivl_synthesis_on *)
|
|
|
|
This attribute tells the compiler that the marked always statement
|
|
is synthesizable. The compiler will attempt to synthesize the
|
|
code in the marked "always" statement. If it cannot in any way
|
|
synthesize it, then it will report an error.
|
|
|
|
(* ivl_synthesis_off *)
|
|
|
|
If this value is attached to an "always" statement, then the
|
|
compiler will *not* synthesize the "always" statement. This can be
|
|
used, for example, to mark embedded test bench code.
|
|
|
|
|
|
* Attributes for modules
|
|
|
|
(* ivl_synthesis_cell *)
|
|
|
|
If this value is attached to a module during synthesis, that
|
|
module will be considered a target architecture primitive, and
|
|
its interior will not be synthesized further. The module can
|
|
therefore hold a model for simulation purposes.
|
|
|
|
|
|
* Attributes for signals (wire/reg/integer/tri/etc.)
|
|
|
|
(* PAD = "<pad assignment list>" *)
|
|
|
|
If this attribute is attached to a signal that happens to be a
|
|
root module port, then targets that support it will use the string
|
|
value as a list of pin assignments for the port/signal. The format
|
|
is a comma separated list of location tokens, with the format of
|
|
the token itself defined by the back-end tools in use.
|
|
|
|
* Other Attributes
|
|
|
|
[ none defined yet ]
|
|
|
|
|
|
MISC
|
|
|
|
(* _ivl_schedule_push *)
|
|
|
|
If this attribute is attached to a thread object (always or
|
|
initial statement) then the vvp code generator will generate code
|
|
that causes the scheduler to push this thread at compile time. The
|
|
compiler may internally add this attribute to always statements if
|
|
it detects that it is combinational. This helps resolve time-0
|
|
races.
|