RE: [sv-ac] non-urgency of 1668

From: Korchemny, Dmitry <dmitry.korchemny_at_.....>
Date: Mon Mar 19 2007 - 08:46:06 PDT
Hi Doron,

Even with your suggestion this definition should work.

Thanks,
Dmitry

-----Original Message-----
From: dbustan [mailto:dbustan@freescale.com] 
Sent: Sunday, March 18, 2007 11:53 PM
To: Korchemny, Dmitry; john.havlicek@freescale.com; sv-ac@eda-stds.org
Subject: RE: [sv-ac] non-urgency of 1668

Dmitry,

The plan is to avoid name conflicts. The names of the local variables of
q
will be made unique w.r.t. to p before the substitution.
 

Doron

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Korchemny, Dmitry
Sent: Sunday, March 18, 2007 9:46 AM
To: john.havlicek@freescale.com; sv-ac@eda-stds.org
Subject: RE: [sv-ac] non-urgency of 1668

Hi John,

It highly depends on the parameter passing semantics. If we adopt the
substitution semantics, then the meaning of passing a local variable
will be slightly different. E.g.,

property q;
    (v, v = !v) |-> b ##1 v ##1 c;
endproperty

property p;
    bit v;
    (a, v = a) |=> q;
endproperty

assert property (@(posedge clk) p);

is equivalent to (I am using pseudo syntax here):

assert property (@(posedge clk) ( bit v: (a, v = a) |=> (v, v = !v) |->
b ##1 v ##1 c));

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of John Havlicek
Sent: Friday, March 09, 2007 2:24 PM
To: sv-ac@server.eda-stds.org
Subject: [sv-ac] non-urgency of 1668

Hi All:

In our last meeting, we decided that 1668 is not urgent.

I have thought some more about this and realized that 
more of 1667 than just assignments in the formal argument
list is dependent on 1668.

Indeed, the basic semantics of binding an actual argument 
expression to a local variable formal argument will be the 
same as a similar local variable declaration assignment, as in
the current sketch for 1667:

   property p(local <type> v, ...);
      ...
   endproperty

   ...

   p(.v(e),...)

should have the same semantics as

   property p(<type> v1, ...);
      <type> v = v1;
      ...
   endproperty

   ...

   p(.v1(e),...)


It is clear to me that for 1667 we do not want a restriction 
that says that e must be a constant expression.

So, I am of the mind now that we really do need to make 
progress to converge on 1668 before I can do anything with
1667.

Best regards,

J.H.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Mar 19 08:47:09 2007

This archive was generated by hypermail 2.1.8 : Mon Mar 19 2007 - 08:47:14 PDT