Subject: [sv-cc] RE: pragmas action item
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Thu Apr 10 2003 - 11:24:40 PDT
Francoise,
I have an issue with trying to get rid of pragmas at this late stage. The
notion of replacing the FSM pragmas
by use of attributes has been raised a number of times in the past and in
each and every case the attribute approach
was rejected due its limitations.
Making these kinds of changes now, leaves very little time for deliberate
discussion and would require a significant
rewrite of the pragma section, which I do not believe we have the freedom to
do at this time.
Sure, I agree that there is a very valid point to move to use of attributes,
but attributes as currently defined are
not quite capable enough for the purpose. Because of these limitations of
attributes, your examples all show
some amount of recoding of declarations and FSM coding style. Further, one
of the proposals even requires extending attribute
usage to be permitted on expression primaries, specifically where you
suggest applying an attribute to a part-select state vector
used in an expression. As currently defined, attributes in expressions can
only be attached to operators.
It is my opinion that we should leave the existing pragmas based proposal as
is, but make this an issue for both sv-bc
and sv-cc for the next revision (SV 3.2)
Joao
============================================================================
==
Joao Geada, PhD Principal Engineer Verif Tech
Group
Synopsys, Inc TEL: (508)
263-8083
344 Simarano Drive, Suite 300, FAX: (508)
263-8069
Marlboro, MA 01752, USA
============================================================================
==
-----Original Message-----
From: Francoise Martinolle [mailto:fm@cadence.com]
Sent: Wednesday, April 09, 2003 10:45 AM
To: fm@cadence.com; Joao.Geada@synopsys.COM
Subject: pragmas action item
Joao,
I tried to rewrite all the fsm examples and define a set of new fsm
attributes.
Also I propose some extensions to attributes.
Let me know what you think.
I read section 2.8 of the 1364 Verilog LRM. Attributes instances can be
put as a prefix to a declaration, module item, statement or port connection.
It can be a suffix to an operator or
a Verilog function name in an expression.
If a value is not specified in an attribute instance, then its default
value is 1.
SystemVerilog adds attributes to interfaces section 6 of draft 4).
"An example of defining an attribute for an interface declaration is:
(* interface_att = 10 *) interface bus1.... endinterface
The default type of an attribute with no value is bit, with a value of 1.
Otherwise, the attribute takes the type of the expression."
In the coverage API, pragmas need to be put on signals declarations, part
selects and concatenations. Placing attribute son part selects and
concatenation is currently
not part of Verilog neither systemVerilog.
I don't think we need the keyword tool since the proposed attributes
should be recognized
by all tools (if they support FSM coverage).
1. attribute fsm_state_vector of type bit
This new attribute is to be used to specify the current signal/part-select
or concatenation which holds the current fsm tate.
reg/var state vectors:
I rewrote the examples with using attributes:
/* tool state_vector signal_name */
reg [7:0] /* tool enum enumeration_name */ signal_name;
is replaced with: (fsm_state_vector is a new attribute, its default value
is 1 in
the following reg declaration. It indicates that the <signal_name> is a
fsm_state vector.
I don't see the need for using the keyword enum.
(* fsm_state_vector *) reg [7:0] signal_name;
Part select state vectors:
The following :
/* tool state_vector signal_name[n:n] FSM_name enum enumeration_name */
is rewritten as:
signal_name[n:m] (* fsm_state_vector *) whenever this part-select is
used as an expression in the Verilog code.
Q: is it possible that the part select is not used in the Verilog code?
In that case I suggest to use an alias to declare a signal name for the
part select
then attach an attribute to the alias.
alias my_state_vector = signal_name[n : m] (* fsm_state_vector *);
Q: do we need to add 2 more attributes of type string, for FSM_name and
enumeration name?
alias my_state_vector = signal_name[n : m] (* fsm_state_vector, fsm_name
= "string_name", fsm_enum_name = "my_enum_name"*) ;
Q:What is the enumeration name used for?
Concatenation state vectors:
/* tool state_vector {signal_name , signal_name, ...} FSM_name enum
enumeration_name */
I think here also I would use the alias declaration.
alias my_state_vector = {signal_name1, signal_name2, ...} (*
fsm_state_vector *);
Q: do we need to more string attributes for fsm_name and enumeration
_name?
2. attribute fsm_next_state of type bit
This new attribute is to be used to specify the signal/part-select or
concatenation which holds the next fsm state.
The following example:
reg [7:0] /* tool enum enumeration_name */
signal_name
is rewritten as:
(* fsm_next_state *) reg [7:0] signal_name;
Replace the following paragraph:
Specifying the current and next state signals in the same declaration
The tool assumes the first signal following the pragma holds the current
state and the next signal holds the nextstate when a pragma is used for
specifying the enumeration name in a declaration of multiple signals, e.g.,
/* tool state_vector cs */
reg [1:0] /* tool enum myFSM */ cs, ns, nonstate;
In this example, the tool assumes signal cs holds the current state and
signal ns holds the next state. It assumes nothing about signal nonstate.
With:
You have to use 3 declarations to specify an attribute for cs and another
attribute for ns
because attributes for declarations are inserted as a prefix.
If they were inserted as suffix, we could put all of them in the same
declaration.
(* fsm_state_vector *)reg [1:0] cs;
(* fsm_next_state *) (*fsm_name = "myFSM" *)reg [1:0] ns;
reg [1:0] nonstate;
Replace the following paragraph:
Specifying the possible states of the FSM
The possible states of the FSM can also be specified with a pragma that
includes the enumeration name:
parameter /* tool enum enumeration_name */
S0 = 0,
s1 = 1,
s2 = 2,
s3 = 3;
Put this pragma immediately after the keyword parameter, unless a
bit-width for the parameters is used, in
which case, specify the pragma immediately after the bit-width:
parameter [1:0] /* tool enum enumeration_name */
S0 = 0,
s1 = 1,
s2 = 2,
s3 = 3;
With:
A new attributes "fsm_states" which indicates that the declaration to
which it applies
specifies the enumeration values for the fsm states.
(* fsm_states *) parameter enum [1:0] {s0 = 0, s1 = 1, s2 = 2, s3 = 3}
p;
P is the name of the parameter of an anonymous enum type which enumeration
values are
s0, s1, s2 and s3. The attribute fsm_states specifies that the parameter p
describes the
fsm states.
Even better I think you can get rid of the parameter declaration and
attach the attribute
to the type def.
(* fsm_states *) typedef enum [1:0] {s0 = 0, s1 = 1, s2 = 2, s3 = 3}
state;
Attribute extensions:
We need to extend the attributes so that they can be placed as :
prefix of typdedefs,
suffix of part-select and concatenations.
Let me know what you think.
Francoise
'
This archive was generated by hypermail 2b28 : Thu Apr 10 2003 - 11:27:09 PDT