[sv-ac] RE: minor comments on 1549

I have changed the new types proposal as suggested by John with the
exception of the comment about passing delay and repetition values as
compile time constants.  Would people object to my adding the following
to this proposal (versus making it a separate standalone proposal).
There may be other qualifiers that are desired too but they will likely
need more discussion.  I think this an obvious one though that is very
important.

 

In essence, I would state:

 

A const qualifier may appear in front of any type as a way of specifying
that the argument must be statically computable at compile time.  This
is strongly recommended for all parameters that will be used for delay
or repetition values.  If const is used without a specific type, then
the type is implicit. 

 

Any integer type can be used to pass delay and repetition values. For
example, two equivalent ways of passing delay and repetition arguments
are shown below:

 

            sequence delay_arg_example ( const shortint delay1, delay2,
min, max);

            x  ##delay1   y[*min:max]   ##delay2  z;

            endsequence

 

            `define my_delay=2;

            cover property ( delay_arg_example ( `my_delay, `my_delay-1,
3, $) );

 

which is equivalent to:

 

     cover property ( x  ##2  y[*3:$]   ##1  z);

 

 

Of course I'd have to update the BNF too.

 

Lisa

 

 

-----Original Message-----
From: John Havlicek [mailto:john.havlicek@freescale.com] 
Sent: Tuesday, August 29, 2006 10:26 AM
To: Lisa Piper
Cc: sv-ac@eda-stds.org
Subject: minor comments on 1549

 

Hi Lisa:

 

Below are a few minor comments (mostly editorial) on 1549.

 

J.H.

 

========================================================================
==

 

- p. 3, 17.6.1 change.  I am confused by the use of "data type" in the
context 

  of 

 

     "The supported data types for sequence formal arguments are the
types that

      are allowed for operands in assertion expressions (see 17.4.1)."

 

  This suggests that the additional types "sequence" and "implicit" are
not 

  data types.  However, later on p. 6 there is the statement

 

     "The supported data types for property formal arguments include all
the 

      types allowed for sequences plus the addition of the property
type."

 

  This suggests that all the sequence types are considered data types.

[Lisa Piper >>>] good catch.  I will change the latter to : 

 

      "The supported data types for property formal arguments include
all the 

      types allowed for sequences plus the addition of the property
type."

 

- Top of p. 4:  

 

     "For example, three equivalent ways of passing arguments ..."  

 

  I am a bit concerned with saying that these three are equivalent.

  They are not equivalent when the assignment rules for binding actual

  arguments to typed formal arguments are taken into account.  I

  prefer to say

 

     "For example, three similar ways of passing arguments ..."

[Lisa Piper >>>] good point - done

 

  Ways 2 and 3 really are equivalent.

 

- p. 4.  Doron has written a separate comment about passing delay and
repetition 

  values to integer types with constant qualifier.  I think at this time
we should 

  at least review the vision for this sort of argument passing.

  . As Doron points out, it will be nice to specify that the formal
argument is 

    for a compile-time constant expression since it is used in a delay

    or range value.

  . Using integer types means that we impose the assignment rules of 

    binding actual arguments to typed formal arguments.

  . I think we have understood that there is an exception to the
assignment

    rule for binding when the actual argument is $.

 

- p. 5.  I would change

 

     "If the intent is to pass only the name of the signal of an
event_expression ..."

 

  to 

 

     "If the intent is to pass a signal that is not an entire
event_expression ..."

[Lisa Piper >>>] done

 

- p. 5.  In the example with sequence foo, operator associativity makes
the 

  implicit parenthesization like this:

 

     ( (1'b1, loc_a = a) ##0 (t == loc_a)[*0:$] ) ##1 b

 

  and so the [*0:$] cannot match 0 times due to the ##0 fusion.  I
recommend 

changing [*0:$] to [*1:$].

[Lisa Piper >>>] done