====== Icarus Attribute Naming Conventions ======
<code>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.</code>