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.Received on Sun Mar 18 07:46:57 2007
This archive was generated by hypermail 2.1.8 : Sun Mar 18 2007 - 07:47:05 PDT