ISSUE 527

Number 527
Category errata
Synopsis Replication operator on concats involving function calls
State lrmdraft
Class errata-discuss
Arrival-DateJan 07 2004
Originator "Brad Pierce" <Brad.Pierce@synopsys.com>
Release 2001b
Description
In section (4.1.14) it says "If the replication operator is
used on a function call ...". But this is inconsistent with the
language of http://www.boyd.com/1364_btf/report/full_pr/73.html ,
because a replication operator cannot be used on a function
call, but only on a concatenation.

It seems to me that it should not be legal to implement

result = {4(func(w)}
as
result = { func(w), func(w), func(w), func(w) }

and that if there's a side-effect in func, it should happen
exactly once. That is, the replication operator should
replicate the value of the concatentation. Otherwise, why can't
the result of the replication operator be used as an lvalue?

For example, shouldn't the following example unambiguously yield
|0001000100010001|, even though Verilog-XL didn't do it that way?

module m (o);
output [15:0] o ;
reg [15:0] o ;
reg [3:0] t;

function [3:0] f ;
input i ;
begin
t = t + i ;
f = t ;
end
endfunction

initial begin
t = 0 ;
o = {4{f(1'b1)}} ;
$display("|%b|", o) ;
end

endmodule

Is replication an operator or syntactic sugar? If syntactic sugar,
why not allow it in lvalues?

-- Brad




Fix
As pointed out in

http://boydtechinc.com/etf/archive/etf_2004/2251.html

this is a duplicate of 288. Propose to close as such.


Audit-Trail
From: Shalom.Bresticker@motorola.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/527: Replication operator on concats involving function
calls
Date: Thu, 8 Jan 2004 12:50:59 +0200 (IST)

Brad,


> In section (4.1.14) it says "If the replication operator is
> used on a function call ...". But this is inconsistent with the
> language of http://www.boyd.com/1364_btf/report/full_pr/73.html ,
> because a replication operator cannot be used on a function
> call, but only on a concatenation.

Obviously, the text means a concatenation which contains a function call.
If you want to change the language to say that explicitly, OK.


> It seems to me that it should not be legal to implement
>
> result = {4(func(w)}

Obviously, you mean {} instead of ().

> as
> result = { func(w), func(w), func(w), func(w) }
>
> and that if there's a side-effect in func, it should happen
> exactly once. That is, the replication operator should
> replicate the value of the concatentation. Otherwise, why can't
> the result of the replication operator be used as an lvalue?

Because it is not generally useful as an lvalue.
And I think that has nothing to do with how it is evaluated on a RHS.


> For example, shouldn't the following example unambiguously yield
> |0001000100010001|, even though Verilog-XL didn't do it that way?

Your "even though" is the answer to your question.
That is a good enough reason.

I have even been told, I seem to remember, that different simulators have treated {y,y} on LHS differently.

Oh, and this duplicates issue 288, I think.

Shalom


>
> module m (o);
> output [15:0] o ;
> reg [15:0] o ;
> reg [3:0] t;
>
> function [3:0] f ;
> input i ;
> begin
> t = t + i ;
> f = t ;
> end
> endfunction
>
> initial begin
> t = 0 ;
> o = {4{f(1'b1)}} ;
> $display("|%b|", o) ;
> end
>
> endmodule
>
> Is replication an operator or syntactic sugar? If syntactic sugar,
> why not allow it in lvalues?

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design, Verification & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478


From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/527: Re: errata/527: Replication operator on concats involving function calls
Date: Thu, 8 Jan 2004 09:42:43 -0800

>> For example, shouldn't the following example unambiguously yield
>> |0001000100010001|, even though Verilog-XL didn't do it that way?
>
> Your "even though" is the answer to your question.
> That is a good enough reason.

It may have been a good enough reason in the past, but backward
compatibility with every detail of every corner case of Verilog-XL
should not necessarily be a requirement for Verilog-2005. If it
is, then we should revisit issue 402 (also regarding function side
effects) in which Verilog-XL did not implement the intended behavior.

Verilog-XL was a great tool. But it was software, so it wasn't
perfect.

-- Brad


From: Shalom.Bresticker@motorola.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/527: Replication operator on concats involving function
calls
Date: Thu, 8 Jan 2004 21:48:56 +0200 (IST)

But you need very good justification in order to break back-compatibility.

In 402, Steven Sharp wrote:
The situation where XL appears to re-evaluate the case expression is quite
limited, and is due to a particular optimization. It only occurs if the
case expression is an identifier. If it contains any operators, even ones
that don't affect the value (e.g. {i}), then the expression only gets
evaluated once. Even implicit operations, such as extending the width
of the value to match a wider expression in one of the case item expressions,
will ensure it is only evaluated once.

It appears that this is an optimization that determines that the value of
the expression is identical to the value of the identifier, and uses the
value held in the identifier for the comparisons, to save making a copy.
Applying this optimization in this situation, where other expressions
will be evaluated and have side effects before this value is used, results
in the behavior are seeing. This behavior is not intentional, and should
be considered an obscure bug in XL.

If XL is run with all optimizations turned off, this does not happen. The
case expression is only evaluated once. Note that there are other situations
in which XL changes behavior at different optimization levels. In these
cases, turning off all optimizations gives the most consistent and "standard"
behavior.

So 402 was not even really breaking XL.
All the more so because 402 was talking about a case where the LRM was silent,
and here you talk about a case where the LRM explictly allowed more than one
behavior.

Shalom


> It may have been a good enough reason in the past, but backward
> compatibility with every detail of every corner case of Verilog-XL
> should not necessarily be a requirement for Verilog-2005. If it
> is, then we should revisit issue 402 (also regarding function side
> effects) in which Verilog-XL did not implement the intended behavior.
>
> Verilog-XL was a great tool. But it was software, so it wasn't
> perfect.

You mean software is not perfect?????

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design, Verification & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478



Fix replaced by brad.pierce@synopsys.com on Wed Nov 10 22:38:18 2004
As pointed out in

http://boydtechinc.com/etf/archive/etf_2004/2251.html

this is a duplicate of 288. Propose to close as such.




Unformatted


Hosted by Boyd Technology