Any answers on what should be the consistent behavior here

[parag_paul@hotmail.com]

module top;
byte a[0:4];
initial begin
// Illustration of array copy bug: we initialize an array and
// then perform an overlapping slice copy.
a = '{ 0,1,2,3,4 };
$display(a[0],a[1],a[2],a[3],a[4]);
a[1:4] = a[0:3];
$display(a[0],a[1],a[2],a[3],a[4]);

a = '{ 0,1,2,3,4 };
$display(a[0],a[1],a[2],a[3],a[4]);
a[0:3] = a[1:4];
$display(a[0],a[1],a[2],a[3],a[4]);


Any ideas, what should be the consistent behavior

 

[Jonathan Bromley]

On Thu, 26 Jun 2008 12:43:41 -0700 (PDT), "parag_paul@hotmail.com"
<parag_paul@hotmail.com> wrote:

module top;
byte a[0:4];
initial begin
// Illustration of array copy bug: we initialize an array and
// then perform an overlapping slice copy.
a = '{ 0,1,2,3,4 };
$display(a[0],a[1],a[2],a[3],a[4]);
0 1 2 3 4
a[1:4] = a[0:3];
$display(a[0],a[1],a[2],a[3],a[4]);
0 0 1 2 3
a = '{ 0,1,2,3,4 };
$display(a[0],a[1],a[2],a[3],a[4]);
0 1 2 3 4
a[0:3] = a[1:4];
$display(a[0],a[1],a[2],a[3],a[4]);
1 2 3 4 4

I'm sure everyone agrees that the result I show above
is the only sensible answer. The SV LRM is not brilliantly
clear about it (it mentions "element by element copy" without
specifying how the copy direction is chosen) but this has
been chewed-over in the SV committees and there is wide
agreement that the whole right-hand-side (RHS) expression
should be evaluated before anything is done to the LHS.

I know that at least one tool got this completely wrong
in an early SV implementation, some years ago;
but I thought that all the major tools now do this
correctly... have you found a tool inconsistency here?

Note that if you use nonblocking assignment
a[0:3] <= a[1:4]
then it is absolutely certain that the results I gave
would be correct (after the NBA has had time to settle)
because NBA inevitably involves taking a temporary copy
of the expression and, later, updating the LHS target
from the temporary copy.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jonathan Bromley]

On Fri, 27 Jun 2008 04:26:37 -0700 (PDT), parag_paul wrote:

So is there any way we can say that a consensus is there about it.

Yes, there is a consensus. The copy *should* act as though
the RHS expression is first copied to a temporary location,
and then that temporary is copied to the LHS target.

If what you show is correct then tehre is one simulator that does not
do that

Really? As I said, one simulator got this wrong in the
very early days, but that error was quickly fixed.

I just ran your testcase in three major simulators:

Sim A: compile error, doesn't yet support
slices of unpacked arrays
Sim B: correct answer
Sim C: correct answer

Which tool do you find giving the wrong answer?
(I understand you may not wish to expose this information
in a public group. If you get the chance, I would much
appreciate a private email with the information.)

And I will correct it by tonight

???
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[parag_paul@hotmail.com]

On Jun 27, 12:29 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Thu, 26 Jun 2008 12:43:41 -0700 (PDT), "parag_p...@hotmail.com"

parag_p...@hotmail.com> wrote:
module top;
byte    a[0:4];
initial begin
   // Illustration of array copy bug: we initialize an array and
   // then perform an overlapping slice copy.
   a = '{ 0,1,2,3,4 };
   $display(a[0],a[1],a[2],a[3],a[4]);

                0    1    2    3    4>    a[1:4] = a[0:3];
   $display(a[0],a[1],a[2],a[3],a[4]);

                0    0    1    2    3>    a = '{ 0,1,2,3,4 };
   $display(a[0],a[1],a[2],a[3],a[4]);

                0    1    2    3    4>    a[0:3] = a[1:4];
   $display(a[0],a[1],a[2],a[3],a[4]);

                1    2    3    4    4

I'm sure everyone agrees that the result I show above
is the only sensible answer.  The SV LRM is not brilliantly
clear about it (it mentions "element by element copy" without
specifying how the copy direction is chosen) but this has
been chewed-over in the SV committees and there is wide
agreement that the whole right-hand-side (RHS) expression
should be evaluated before anything is done to the LHS.

I know that at least one tool got this completely wrong
in an early SV implementation, some years ago;
but I thought that all the major tools now do this
correctly... have you found a tool inconsistency here?

Note that if you use nonblocking assignment
   a[0:3] <= a[1:4]
then it is absolutely certain that the results I gave
would be correct (after the NBA has had time to settle)
because NBA inevitably involves taking a temporary copy
of the expression and, later, updating the LHS target
from the temporary copy.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Hmm,

So is there any way we can say that a consensus is there about it.
If what you show is correct then tehre is one simulator that does not
do that

And I will correct it by tonight
-Parag