RE: [sv-ac] meeting on 3/8

From: Miller Hillel-R53776 <r53776@motorola.com>
Date: Tue Mar 09 2004 - 02:03:09 PST

Surrendra,

In the following example I will try make my case with respect to the need to declare datatypes for formal parameters
of properties and sequences.

reg [0:4] f;
reg [0:4] d;
reg [4:0] e;

assert p1(c?d[0:3]:e[2:0], f[2:3], f);

property p1(x, y, z)

x[2:3] and

x[3:2] and

y[2:1] and

z[2:1];

endproperty

After macro substitution then we have the following property.

  property p1;

    c?d[0:3]:e[2:0][2:3] and /* 1 * /

    c?d[0:3]:e[2:0][3:2] and /* 2 */

    f[2:3][2:1] and /* 3 */

    f[2:1]; /* 4 */
  
 endproperty

Here are my problems?

1) To the best of my knowledge, there is no syntax and semantics for this type of code? That is bit slicing and arbitrary expression.
2) If we put parentheses on the substitution are there syntax and semantics?
3) If we tell the vendor to develop a smart compiler to handle this we have the risk of
    vendors providing different semantics. This misses the point of a standard.
4) In line /* 4 */ this is illegal syntax however /* 3 */ should be legal syntax. This is confusing.

A possible workaround is not to allow bit slicing on parameters. This can be achieved by assigning to a local variable and
do the slicing on the local variable.

Hillel

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org]On Behalf Of Surrendra Dudani
Sent: Monday, March 08, 2004 5:28 PM
To: sv-ac@eda.org
Subject: RE: [sv-ac] meeting on 3/8

Hi Hillel,
Please see comments.
Surrendra

At 08:59 AM 3/8/2004 +0200, you wrote:
>Hi,
>
>I would like to discuss the following items:
>
>1) No datatypes of formal paramaters in property definitions. Can we add
>these datatypes?

The original reason for not including data types for formal parameters was
that the sequence and property declarations are closer to macro definitions
than subroutine calls. Although not literally, but in essence, the
declaration is syntactically substituted wherever it is instantiated.
Later, it was also considered to optionally allow data type specification.
However, not all types are defined in SV for the arguments that are allowed
for the declaration, such as property, sequence, and edge expressions. To
define such data types in SV would have required a substantial amount of work.

I do agree that in the future, it is possible to do just that, when there
is sufficient time and justification.

>2) Confusing syntax, according to the BNF you can only do one local
>variable assignment at a time and in the examples you could do more:
>
>sequence_match_item ::=
>variable_assignment <------------- does this mean
>one assignment? where does the comma come in?
>| subroutine_call
>
>there is a an example:
>
>sequence s8;
>int x,y;
>(a ##1 b, x = data, y = data1 ##1 c)
>and (d ##1 'true, x = data ##0 (e==x))) ##1 (y==data2);
>// legal since y is in the difference
>endsequence

The BNF for sequence_expr is
sequence_expr::=
         -
         -
         | ( expression_or_dist {, sequence_match_item } ) [ boolean_abbrev ]
         -
This BNF will allow the user to write one of more assignments.

>3)
>
>-----Original Message-----
>From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org]On Behalf Of
>Surrendra Dudani
>Sent: Friday, March 05, 2004 6:47 PM
>To: sv-ac@eda.org
>Subject: [sv-ac] meeting on 3/8
>
>
>I would like to discuss the following items in Monday's meeting:
>1) Currently, expression (instead of expression_or_dist) is used in two
>constructs: if-else and disable iff. We can possibly change them to
>expression_or_dist.
>2) Replacing variable_assignment in inc_or_dec_expression as
>
>sequence_match_item ::=
>operator_assignment
>| inc_or_dec_expression
>| subroutine_call
>
>This change will allow other kinds of assignment short cuts already allowed
>in SV.
>3) Moving the implication section (17.7.11) under the property section
>(17.11), as suggested by Adam.
>4) list of errata that I have compiled so far.
>
>Surrendra
>
>
>
>**********************************************
>Surrendra A. Dudani
>Synopsys, Inc.
>377 Simarano Drive, Suite 300
>Marlboro, MA 01752
>
>Tel: 508-263-8072
>Fax: 508-263-8123
>email: Surrendra.Dudani@synopsys.com
>**********************************************

**********************************************
Surrendra A. Dudani
Synopsys, Inc.
377 Simarano Drive, Suite 300
Marlboro, MA 01752

Tel: 508-263-8072
Fax: 508-263-8123
email: Surrendra.Dudani@synopsys.com
**********************************************
Received on Tue Mar 9 02:04:18 2004

This archive was generated by hypermail 2.1.8 : Tue Mar 09 2004 - 02:04:35 PST