Hi Ben,
I disagree with you. This capability is important, and passing temporal expressions to other properties, sequences and checkers is already supported in SV. Many people do pass temporal expressions to other sequences and properties in practice, and this is convenient. As for Jacob's proposal, consider an example described in 17.9. Without this capability you won't be able to pass Boolean values to the checker assert_windows.
E.g., the following instantiation
assert_window check_cond(cond, req, gnt);
is currently illegal if req and gnt are design variables. To make the invocation legal you should write
sequence req_seq; req; endsequence
sequence gnt_seq; gnt; endsequence
assert_window check_cond(cond, req_seq, gnt_seq);
which is inacceptable from the user point of view.
Regards,
Dmitry
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of ben cohen
Sent: Wednesday, February 16, 2011 19:25
To: Katz, Jacob
Cc: thomas.thatcher@oracle.com; sv-ac >> "sv-ac@eda.org"
Subject: Re: [sv-ac] 3191: Allow sequence methods with sequence expressions
Jacob,
I hear what you're saying. However, I am a bit of stickler on style, and keeping it simple. On simple expressions being passed as argument to a module [e.g, dut dut1(a&&b, 2*3, ...);] I can see value because these expressions are not temporal; this is unlike sequences, which can be more complex as they are temporal. Allowing temporal expressions to be passed as arguments to another sequence or property declaration is very much in the "spirit of Verilog", meaning "giving them everything, and let them hang themselves".
I come from a strong VHDL background, which has a contrarian direction to the Verilog philosophy. The new VHDL has migrated a bit into the Verilog concepts, and the reverse is also true.
I still vote NO on this proposal. However, don't let that stop you. It takes more than one negative vote to kill it.
Regards,
Ben
On Tue, Feb 15, 2011 at 11:23 PM, Katz, Jacob <jacob.katz@intel.com<mailto:jacob.katz@intel.com>> wrote:
Hi Ben,
Can't the same be said about arguments to function calls or module instances? There is no requirement from the LRM to assign big and complex expressions to temporary variables/nets before sending them as arguments. Although there also the code may become less beautiful (or ugly), but the convenience of being able to send simple expressions without creating unnecessary temporaries is of a great value; so the choice is left to the coder.
I guess the same reasoning applies to arguments of properties and checkers. It would be highly inconvenient to create named sequences even for the simplest Boolean expressions to be able to send them as arguments to a checker which internally applies 'triggered' on it. I think in this case the style issue should be left to the coder...
Makes sense?
--------------------------------
Jacob M. Katz | jacob.katz@intel.com<mailto:jacob.katz@intel.com> | Work: +972-4-865-5726 | iNet: (8)-465-5726
From: owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org> [mailto:owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org>] On Behalf Of ben cohen
Sent: Tuesday, February 15, 2011 20:53
To: thomas.thatcher@oracle.com<mailto:thomas.thatcher@oracle.com>
Cc: sv-ac >> "sv-ac@eda.org<mailto:sv-ac@eda.org>"
Subject: [sv-ac] 3191: Allow sequence methods with sequence expressions
After more thoughts, I am NOT in favor of this proposition because it could lead to bad coding style. sequences can be fairly complex with and, or, intersect, throughout, etc oeprators). Passing all of that as an argument is definitely NOT desirable.
Ben Cohen SystemVerilog.us
----
3191: Allow sequence methods with sequence expressions
Jacob: Would allow passing sequence expressions as actual arguments
Ben: On one hand it could be convenient.
on the other hand it could lead to bad coding style.
On Tue, Feb 15, 2011 at 10:30 AM, Thomas J Thatcher <thomas.thatcher@oracle.com<mailto:thomas.thatcher@oracle.com>> wrote:
Minutes of SV-AC Meeting
Date: 2011-02-08
Time: 16:30 UTC (8:30 PST)
Duration: 1.5 hours
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Feb 16 10:47:29 2011
This archive was generated by hypermail 2.1.8 : Wed Feb 16 2011 - 10:47:36 PST