Os atributos foram adicionados no Verilog 2001 para definir propriedades especiais de algum objeto ou declaração para uso em simuladores e sintetizadores. Porém o Verilog 2001 não especifica quais atributos devem ser declarados, isso é definido pela ferramenta ou outros padrões.

Podem ser usados como prefixo de alguma declaração, itens do módulo, conexões de porta. E como sufixo para um operador ou chamada a função.

Atributos que não tem valor designado tem o valor “1” como padrão. Multiplos atributos são declarados como uma lista separa por vírgula.

Exemplos

Prefixado em uma declaração case.

1
2
3

(* full_case, parallel_case *) case (state)

endcase

Sufixo para um operador.

1

assign sum = a + (* CLA=1 *) b;

iVerilog

O iVerilog possui alguns atributos que são úteis para simulação e sintese, abaixo segue o original da listagem obtido no fonte do GitHub.

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 *)

1
2
3
4
5
6
7
8

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 *)

1
2
3
4

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 *)

1
2
3

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 *)

1
2
3
4

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 = “" *)

1
2
3
4
5

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 *)

1
2
3
4
5
6

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.