Subject: [sv-bc] attributes on SV constructs and beyond
From: Jacobi, Dan (dan.jacobi@intel.com)
Date: Sun Nov 02 2003 - 05:56:51 PST
Hello All,
In the last SV-BC meeting, I was asked to send my opinion regarding the
definition of the attributes in System-Verilog. Following is a bunch of
ideas and thoughts, if the committee members think that the general
ideas should be added to system-Verilog, then I will try to compose some
formal proposals.
The Current Situation
===============
The attributes syntax is well defined in Verilog 2001 and SV standards,
meaning how we should write each attribute, and should the attribute be
attached to the corresponding RTL object.
However the on the semantics side of the attribute definition, meaning
what should each tool do with these attributes, more or less depends on
how each CAD tool decides to use these attributes. Only in two places
(as best of my knowledge) do the standards define what to do with these
attributes.
1. Tools that support PLI, need to support the PLI routines (
fetch_attribute routines)
2. Synthesis tools should support synthesis attributes as define in
the IEEE 1364.1 synthesis level standard (section 6.1) (even though that
in the same standard section 7.1.8 specifies that attributes should be
ignored)
The IEEE 1364-2001 specifies (section 2.8):
"With the proliferation of tools other than simulators that use Verilog
HDL as their source, a mechanism is
included for specifying properties about objects, statements and groups
of statements in the HDL source that
may be used by various tools, including simulators, to control the
operation or behavior of the tool. These
properties shall be referred to as "attributes". This subclause
specifies the syntactic mechanism that shall be
used for specifying attributes, without standardizing on any particular
attributes."
My Opinion
=========
In my opinion, attributes are trap doors for CAD tools, these trap doors
may be used by any tool that process any Verilog RTL for any propose.
This is the same use as the old style pragma meta-comments (such as : //
synthesis full_case) however these meta-comments had no standardization
at all (not even a standard specification of where the pragma should be
allocated).
The CAD tools using the Verilog attribute mechanism may be the
"traditional" main stream tools such as simulation and synthesis tools,
and may be new tools such as lint tools, tools that "process" the RTL
in a pre-elaboration stage, and other future uses ...
Due to my previous claims, I think that the use of attributes should not
be limited to constructs that are viewable by the PLI routines, maybe
some language should be added to the PLI section in the SV/V2K standard
specifying which attributes are viewable by the PLI routines and which
are not.
Missing attributes
=============
Following are the constructs that, in my opinion, an option to specify
an attribute should be added.
1. Attributes on parameter declarations in parameter port lists
enable such RTLs
module M1 #( (* attr *) parameter p1 = 1) (input i1); ....
Note the following is already supported in SV3.1
module (input i1); ....
(* attr*) parameter p1 = 1;
Proposal :
Under A.1.4
REPLACE
parameter_port_list ::= # ( parameter_declaration { ,
parameter_declaration } )
WITH
parameter_port_list ::= # ({ attribute_instance }
parameter_declaration { , { attribute_instance } parameter_declaration }
)
2. Attributes for generated module items / generated interface items
Assume the following RTL that has a bug (if WIDTH == 4 than no adder is
generated)
parameter WIDTH = 4;
wire [WIDTH -1 : 0] op1, op2, res;
generate
(* full_case *) case (1'b1) // let a static tool check that
all the width possibilities are treated
(WIDTH == 0) : (*
black_box_for_synthesis = 1*) error_message_module i1();
(WIDTH == 1) : xor(res,op1,op2);
(WIDTH > 1 && WIDTH < 4 ) : simple_adder sa1
(res,op1,op2);
(WIDTH > 4 ) :
carry_look_ahead_adder ca1 (res,op1,op2);
endcase
endgenerate
3. Attributes for Verilog 95 style ports
The following is not supported
module M1 ( (* attr *) p1, (* attr *) p2);
However the following is
module M1 ((* attr *) input p1, (* attr *) input p2);
4. Attributes for modport items
These will enable RTLs such as
Interface i1();
logic a,b;
modport (* big_modport *) master (input a,output b); (*
small_modport *) master (output a, input b);
...
However the current RTL is currently O.K.
Interface i1();
logic a,b;
(* big_modport *) modport master (input a,output b);
(* small_modport *) modport master (output a, input b);
...
Note that this is the case with module declarations.
5. Attributes for System Verilog assertion
a. SVA operators such as |-?, |=>, not, and, intersects, or, first
match, through out, within, ##, etc...
b. Formal list items
c. Assertion variable declarations
d. Sequences
6. Attributes for Inside expressions
This will enable RTL expressions such as
a inside (* deep_search *) b ;
7. Attributes for unsized literals
such as
'0, '1, 'x, 'X, `z, `Z
8. Attributes for aggregated expression
such as
c = {int:1,default :0};
or
d = {field1:0,default :x};
9. Attributes for explicit casts
such as
int'(2.5);
10. Attributes for enumerated values casts
This will enable RTL expressions such as:
enum { green = 00, yellow = 01, red = 11, (*
illegal_state__verification_tool_check_that_this_is_never_used *) bad=
10 } traffic_light;
Enjoy,
Dan Jacobi
Tel : 972-4-8655855
This archive was generated by hypermail 2b28 : Sun Nov 02 2003 - 06:00:20 PST