Subject: RE: [sv-cc] RE: pragmas action item
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Apr 11 2003 - 08:44:26 PDT
Yes, I agree it is a little bit too late unfortunately.
Francoise
'
At 10:57 AM 4/11/2003 -0400, Joao Geada wrote:
>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 - 08:45:34 PDT