Subject: RE: [sv-cc] RE: pragmas action item
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Fri Apr 11 2003 - 07:57:28 PDT
Francoise,
Please don't misunderstand me: I agree that this is a fixable issue; I just
think that it is a large change, and it is coming
a bit too late to be addressable in this revision of the SystemVerilog.
Specifically, making this change would require redoing
the entirety of section 28.3 (3 pages).
As I said before, I would much rather make this kind of change when there is
time for meaningful debate and resolution
of issues, so that we can get a solution that is widely acceptable to users
while also being implementable. Doing it in a rush
today would at best only get our (yours and mine) points of view and even
then would not give us time to carefully
deliberate on the consequences of all the decisions we would need to make.
For these reasons I proposed that we explicitly raise this as an issue to
address in SV 3.2
Joao
============================================================================
==
Joao Geada, PhD Principal Engineer
Verif Tech Group
Synopsys, Inc TEL: (508)
263-8083
377 Simarano Drive, Suite 300, FAX: (508)
263-8069
Marlboro, MA 01752, USA
============================================================================
==
-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of
Francoise Martinolle
Sent: Friday, April 11, 2003 10:10 AM
To: Joao.Geada@synopsys.COM
Cc: sv-cc
Subject: [sv-cc] RE: pragmas action item
Joao
another way (which I did not highlight in this proposal) to minimally
disrupt the Systemverilog state is to associate the attribute with
the alias declaration instead of with the part select or concatenation.
That way we don't have to enhance the attributes because attributes can be
attached to declared items.
Francoise
'
At 02:24 PM 4/10/2003 -0400, Joao Geada wrote:
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 : Fri Apr 11 2003 - 07:59:21 PDT