Re: [sv-ac] 3191: Allow sequence methods with sequence expressions

My comments to this mantis are are
http://bit.ly/h1ZBqp
Ben Cohen
Ben@systemverilog.us

On Thu, Feb 17, 2011 at 7:03 AM, Korchemny, Dmitry <
dmitry.korchemny@intel.com> wrote:

> Thanks, Ben. This is not the final proposal yet, just an initial draft.
>
>
>
> Dmitry
>
>
>
> *From:* ben cohen [mailto:hdlcohen@gmail.com]
> *Sent:* Wednesday, February 16, 2011 21:01
> *To:* Korchemny, Dmitry
> *Cc:* Katz, Jacob; thomas.thatcher@oracle.com; sv-ac >> "sv-ac@eda.org"
>
> *Subject:* Re: [sv-ac] 3191: Allow sequence methods with sequence
> expressions
>
>
>
> Dmitry,
>
> I was referring to passing the temporal expressions as what's in the body
> of a sequence . Yes, you can pass them today if they are declared
> sequences.
>
>
>
> In any case, in the meeting I had mixed views on Jacob's proposal. In
> light of what's you and Jacob wrote, I am willing to vote *YES* on this.
> If it is appropriate, I would like to add a note to the proposal with
> wordings such as: "*For complex temporal expressions, it is recommended
> that the sequence argument be passed as a named sequence rather than a
> complex expression*".
>
> Thanks for your feedback,
>
> Ben
>
> On Wed, Feb 16, 2011 at 10:46 AM, Korchemny, Dmitry <
> dmitry.korchemny@intel.com> wrote:
>
> 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>
> 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 | *Work:* +972-4-865-5726 | *iNet:
> *(8)-465-5726
>
>
>
> *From:* 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
> *Cc:* sv-ac >> "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> 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.
>
>
> ---------------------------------------------------------------------
> 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.