RE: [sv-ec] "const ref" for parameters and consts

I wasn't complaining. I'm just trying to keep parameters the users first choice for specifying what they think as of constants.

Dave

From: Steven Sharp [mailto:sharp@cadence.com]
Sent: Thursday, August 25, 2011 7:50 PM
To: Rich, Dave; Daniel Mlynek
Cc: sv-ec@eda.org
Subject: RE: [sv-ec] "const ref" for parameters and consts

Because a const variable can be passed by const ref, and a parameter cannot. Why would you insist on using an inappropriate construct, and then complain when it doesn't work, instead of using the correct one?

From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: Thursday, August 25, 2011 10:41 PM
To: Steven Sharp; Daniel Mlynek
Cc: sv-ec@eda.org
Subject: RE: [sv-ec] "const ref" for parameters and consts

Why would you use a const variable when you could be using a parameter? My reason not to use a parameter is when the initialization expression cannot be constant expression.

By the way, there was a very similar discussion for Mantis 1575<http://www.eda.org/svdb/view.php?id=1575> that wanted to change the definition of const ref arguments to allow for other kinds of things, but that seemed to be too broad a change at the time.

Dave

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Steven Sharp
Sent: Thursday, August 25, 2011 7:01 PM
To: Daniel Mlynek
Cc: sv-ec@eda.org
Subject: RE: [sv-ec] "const ref" for parameters and consts

Why would you use a parameter instead of a const variable?

From: Daniel Mlynek [mailto:danielm@aldec.com.pl]
Sent: Thursday, August 25, 2011 2:09 AM
To: Steven Sharp
Cc: sv-ec@eda.org
Subject: Re: [sv-ec] "const ref" for parameters and consts

Parameters in SV can be a fixed size array (I'm not sure how about dynamic arrays etc if they can be parameters bcos their dynamic nature is in contrast with parmeter constant nature).
From performance point of view It would be nice if we can pass such array by reference instead making copy of it each time - this is my motivation.
I think that internal details of implementation should not stop us from extending the LRM in this case there will be no back-compatibility issue - user will have more posssibilities.

DANiel

On 8/25/2011 2:29 AM, Steven Sharp wrote:
It may not be clear from the LRM text, but the intent is that a const variable can be passed to a const ref argument. The only restriction on a const variable is that it cannot be written. Since you cannot write to a const ref argument, passing a const variable to a const ref argument cannot result in its being written, so it would be legal. One reason this might not have been explicitly specified is that the const qualifier was borrowed from C, and the authors of the LRM text may have automatically assumed the behavior from C without specifying it in the LRM.

Parameters are another matter, as they are not just variables you aren't allowed to write to. An implementation may not keep a copy of the value available in the format that variables are stored in, suitable for passing to a ref argument. Doing so would only be a minor burden on the implementation. But it is also trivial for the user to set a const variable to the value of the parameter and pass that. I don't think we want to start down that slippery slope that leads to arbitrary expressions being passed to ref arguments.

From: owner-sv-ec@eda.org<mailto:owner-sv-ec@eda.org> [mailto:owner-sv-ec@eda.org] On Behalf Of Daniel Mlynek
Sent: Wednesday, August 24, 2011 8:31 AM
To: sv-ec@eda.org<mailto:sv-ec@eda.org>
Subject: [sv-ec] "const ref" for parameters and consts

LRM about refs says:
Only the following shall be legal to pass by reference:
- a variable,
- a class property,
- a member of an unpacked structure, or
- an element of an unpacked array.

So only variables are allowed for ref ports (no word about const, parameter)
But then const ref was added to the standart.
IMHO there is no sensible argument to forbid parameters to be passed by "const ref" like in below case.

module top;
 parameter byte a = 1;
 task automatic t (const ref byte a);
  $display(a);
 endtask
 initial
  t(a);
endmodule

Maybe LRM should allow parameters and const explicitly for const ref only.

Should I register a mantis - there is no similar yet?

DANiel

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.