Subject: [sv-cc] RE: pragmas action item
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Apr 11 2003 - 07:10:02 PDT
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:11:17 PDT