RE: [sv-ac] RE: minor comments on 1549

This proposal seems inconsistent with the general meaning of const in
the rest of the language: A const declaration is computed after
elaboration and what I believe you want here is to have the semantics of
a parameter. Wouldn't it be simpler to trigger an error when the delay
or repetition argument was not an elaboration time constant - the
desired semantics - rather than require users to specify this additional
check using a const modifier? 

I don't understand what it means when you say "this is strongly
recommended for all parameters". Since a property is instantiated at
elaboration time, how could the parameters be anything other than
constants? Surely they cannot be depend on procedural code.

 

Also, there is a slight mistake in the example: It should be (the = and
; are incorrect): `define my_delay 2

 

            Arturo

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Lisa
Piper
Sent: Thursday, August 31, 2006 8:50 AM
To: john.havlicek@freescale.com; sv-ac@eda-stds.org
Subject: [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