RE: [sv-ac] P1800 SV-AC: vote on #1549

Hi Manisha,

I am not claiming that. Just it is not natural for a user to write a
default argument in the middle. If there are several default arguments,
the user will be completely lost: my_seq(a,,, b) (compare with my_seq(a,
b)). I am just saying that we are losing the ease of use instead of
gaining it.

Thanks,
Dmitry

-----Original Message-----
From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com] 
Sent: Thursday, October 05, 2006 7:34 PM
To: Korchemny, Dmitry; stuart@sutherland-hdl.com;
john.havlicek@freescale.com; Eduard.Cerny@synopsys.com
Cc: piper@cadence.com; Bassam.Tabbara@synopsys.com; sv-ac@server.eda.org
Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549

Hi Dimitry,

I do not quite understand your argument about specifying default
arguments. Are you saying that the arguments with default arguments can
only occur at the end of the list of arguments ? As far as I know P1800
does not have this restriction for tasks/functions. Here is some text
and example from section 12.4.3:

The syntax to declare a default argument in a subroutine is as follows:
subroutine( [ direction ] [ type ] argument = default_value );
The optional direction can be input, inout, or ref (output ports cannot
specify defaults).
The default_value is an expression. The expression is evaluated in the
scope containing the subroutine
declaration each time a call using the default is made. If the
default_value is not used, the expression is
not evaluated. The use of default values shall only be allowed with the
ANSI style declarations.
When the subroutine is called, arguments with default values can be
omitted from the call, and the compiler
shall insert their corresponding values. Unspecified (or empty)
arguments can be used as placeholders for
default arguments, allowing the use of nonconsecutive default arguments.
If an unspecified argument is used
for an argument that does not have a default value, a compiler error
shall be issued.
task read(int j = 0, int k, int data = 1 );
...
endtask;
This example declares a task read() with two default arguments, j and
data. The task can then be called
using various default arguments:
read( , 5 ); // is equivalent to read( 0, 5, 1 );
read( 2, 5 ); // is equivalent to read( 2, 5, 1 );
read( , 5, ); // is equivalent to read( 0, 5, 1 );
read( , 5, 7 ); // is equivalent to read( 0, 5, 7 );
read( 1, 5, 2 ); // is equivalent to read( 1, 5, 2 );

I think we should follow the same model for properties and sequences for
default arguments.

Manisha

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Korchemny, Dmitry
Sent: Thursday, October 05, 2006 8:46 AM
To: stuart@sutherland-hdl.com; john.havlicek@freescale.com;
Eduard.Cerny@synopsys.com
Cc: piper@cadence.com; Bassam.Tabbara@synopsys.com; sv-ac@server.eda.org
Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549

Hi Stu,

I also taught several SVA class (though my teaching experience is much
more modest), and I found out that the students sometimes just ignore
many issues, but when they become customers, they discover the problems,
and sometimes just stop using SVA because of them.

Back to the examples. Consider the following property:

property stable_for (sig, clk, int n, sys_clk = proj_clk);

You typically don't want to specify a type of sig, clk and sys_clk
because they may be 2- and 4- value signals, and we would like to avoid
a redundant type casting. On the other hand you want to specify a type
of n. If you change the order of arguments (let alone it breaks the
backward compatibility), you won't be able to use a default value of
sys_clk.

As for using a tool specific switch to address the backward
compatibility, unfortunately, it does not solve the problem: sometimes
the designers use many different tools - simulators, model checkers,
debuggers, etc, which may even be provided by different companies. To
keep it backward compatible we'll have to standardize the switch
behavior :)

I agree with you about keeping things simple. But we should distinguish
between two types of the simplicity: for users and for library writers.
I believe that the usage should be made as simple and convenient as
possible. In our example it is just

assert property (stable_for(interrupt, slow_clock, 3));

As for the library writers,

property stable_for (sig, clk, int n, implicit sys_clk = proj_clk);

is quite acceptable.

Thanks,
Dmitry

-----Original Message-----
From: Stuart Sutherland [mailto:stuart@sutherland-hdl.com]
Sent: Thursday, October 05, 2006 4:56 PM
To: Korchemny, Dmitry; john.havlicek@freescale.com;
Eduard.Cerny@synopsys.com
Cc: piper@cadence.com; Bassam.Tabbara@synopsys.com; sv-ac@server.eda.org
Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549


I know the discussion on this topic has evolved far beyond the
keep-it-simple phase, but just for a matter of perspective...

I brought up this issue in an SVA training class I presented last week.
I
asked the students what they preferred, using the nearly same scenarios
in
Dimitry's message, below.  Every student preferred requiring all untyped
arguments be listed first, and once an argument is typed, any arguments
without a specific type that follow inherit the type of the preceding
argument.  All the students felt this was the most intuitive behavior.
Some
were very surprised that any other behavior would even be considered.
None
of the students felt it was necessary to switch back to untyped args
once a
type had been specified, regardless of whether an existing keyword were
used, or a new keyword was invented.

Granted, my query to the class was far from a scientific survey.  Only
two
user companies were represented, and though both companies already have
legacy SVA code, the students did not know what, if any, assumptions
regarding untyped/typed arguments had been made in their existing SVA
properties and sequences.

No matter what is done, there will be a backward compatibility issue.
Since
it is an issue no matter what, I am in favor of doing what is simple and
intuitive to users.  Any untyped args must be listed first in the
argument
list.  Once an arg type is specified, subsequent args without a type
inherit
the type of the previous arg.  If some tool was already interpreting the
standard this way, then users of that tool will not have a backward
compatibility problem.  If some tool was already interpreting the
standard
differently, that tool can provide a backward compatibility switch.  

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
  

> -----Original Message-----
> From: owner-sv-ac@server.eda.org 
> [mailto:owner-sv-ac@server.eda.org] On Behalf Of Korchemny, Dmitry
> Sent: Wednesday, October 04, 2006 11:42 PM
> To: john.havlicek@freescale.com; Eduard.Cerny@synopsys.com
> Cc: piper@cadence.com; Bassam.Tabbara@synopsys.com; 
> sv-ac@server.eda.org
> Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549
> 
> One more issue is the backward compatibility. We had initially a
> discussion about interpreting parameter types in properties/sequences.
> E.g.,
> 
> sequence s(bit a, b);
> ...
> endsequence
> 
> One interpretation was that a is typed while b is untyped. 
> The other one
> (which won) was that both a and b are of type bit. But there 
> were people
> who wrote their property library according the first 
> interpretation. It
> is acceptable to request from them to change the implementation:
> 
> sequence s(bit a, implicit b);
> 
> but to change the usage
> 
> sequence s(b, bit a);
> 
> in unacceptable.
> 
> Thanks,
> Dmitry
> 
> -----Original Message-----
> From: owner-sv-ac@server.eda.org 
> [mailto:owner-sv-ac@server.eda.org] On
> Behalf Of John Havlicek
> Sent: Monday, September 11, 2006 7:40 PM
> To: Eduard.Cerny@synopsys.com
> Cc: piper@cadence.com; Bassam.Tabbara@synopsys.com; 
> sv-ac@server.eda.org
> Subject: Re: [sv-ac] P1800 SV-AC: vote on #1549
> 
> Hi Ed:
> 
> I think Dmitry and, perhaps, others did not like requiring the
> implicitly typed arguments to be placed first in the argument list.
> 
> It is fair enough to ask the other committees to have a look at
> "implicit" to see what it can do for them.
> 
> I am a little worried that if we remove "implicit" then we may be
> discarding our first choice solution on the rumor of pushback from the
> champions.
> 
> J.H.
> 
> 
> > X-Authentication-Warning: server.eda-stds.org: majordom set 
> sender to
> owner-sv-ac@eda.org using -f
> > X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
> > Content-class: urn:content-classes:message
> > Date: Mon, 11 Sep 2006 08:19:11 -0700
> > Thread-Topic: [sv-ac] P1800 SV-AC: vote on #1549 
> > Thread-Index: AcbTb8rEWEqxRyu2Qp2lo5jzRQiFrgCQZHCQAAD3XpA=
> > From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
> > X-OriginalArrivalTime: 11 Sep 2006 15:19:13.0109 (UTC)
> FILETIME=[A33C9050:01C6D5B5]
> > X-Virus-Status: Clean
> > Sender: owner-sv-ac@eda.org
> > 
> > This is a multi-part message in MIME format.
> > 
> > ------_=_NextPart_001_01C6D5B5.A32CA156
> > Content-Type: text/plain;
> > 	charset="US-ASCII"
> > Content-Transfer-Encoding: quoted-printable
> > 
> > I think that the issue is that we introduce a new keyword "implicit"
> and
> > there is generally resistance to introducing new keywords 
> that have a
> > very narrow usage, in this case only in the list of arguments to
> > properties and sequences. Therefore, either the other 
> committees find
> it
> > useful in other contexts or we perhaps may have to retract it. In
> fact,
> > it is not obvious to me that we do really need it, because we could
> > require that all untyped arguments be placed first on the list.
> > =20
> > Best regards
> > ed
> > =20
> > 
> > 
> 
>