RE: [sv-bc] Re: Self-assignment of slice of unpacked array

I believe this erratum is really about assignment of unpacked arrays when
source and target overlap. The simplest case would be:

reg [7:0] A [15:0];
A[15:1] = A[14:0];

But there are more complicated cases with ref port aliases, where it
is not obvious that the source and target overlap and may overlap
differently on different calls:

task cpy(const ref reg [7:0] X [14:0], ref reg [7:0] Y [14:0]);
    Y = X;
endtask

reg [7:0] A [15:0];
cpy(A[14:0], A[15:1});
cpy(A[15:1], A[14:0});

It is not clear to me from reading sections 4.2 and 4.7 on array assignments
that this is what was indented.

Overlapped array assignment can be useful for shift registers. If we want to
allow it, I think we need to add some text in section 4.7 to say this
is allowed and how it works, rather than just adding this change in 7.16.

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of Rich,
> Dave
> Sent: Monday, November 08, 2004 3:10 PM
> To: Greg Jaxon; Brad.Pierce@synopsys.COM
> Cc: sv-bc@eda.org; Surrendra Dudani
> Subject: RE: [sv-bc] Re: Self-assignment of slice of unpacked array
>
>
> Greg,
>
> I believe this is already covered by the definition of blocking and
> non-blocking assignments in the 1364 LRM, section 9.2 (If not then it
> should be a 1364 errata)
>
> Otherwise the following would not have defined behavior:
>
> reg [15:0] A;
> A[15:1] = A[14:0];
>
>
> Dave
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg
> Jaxon
> Sent: Monday, November 08, 2004 2:34 PM
> To: Brad.Pierce@synopsys.com
> Cc: sv-bc@eda.org; Surrendra Dudani
> Subject: [sv-bc] Re: Self-assignment of slice of unpacked array
>
> There have been some disagreements about the meaning of aggregate
> expressions.
> For an example, see the discussion at
> http://www.eda.org/sv-bc/hm/2198.html
>
> Here is an Erratum proposal that makes clear what I'd always understood
> to
> be the LRM intent.
>
> ---------------
>
> ADD to the end of section 7.16 (Aggregate expressions)
>
> When an aggregate expression is copied, it shall be fully evaluated
> before the
> destination of the copy is modified.
>
> ----------------
>
> Since this is a property common to most expression languages, I think
> the LRM
> authors expected it to be universally understood. There are, of course,
> many
> ways to optimize aggregate data movement. This sentence may remind
> implementers
> that they need to handle the case where an "input" data dependence
> exists between
> a RHS read of a source location and a LHS write to that location. The
> integrity
> of the RHS value needs to be maintained.
>
> I suppose there is a larger philosophical question here about whether
> the
> destination can be atomically modified in one simulation event. I am
> not
> competent to judge where aggregate assignment belongs in the simulation
> model.
>
> In the special case of continuous assignment, the data dependence
> cycles that this proposal explicitly breaks reemerge anyway; I expect
> classical optimization to still have a freehand in deciding what events
> are necessary to model continuous assignments with self-input
> dependences.
> But those optimizations should not apply to procedural assignments.
>
> Greg Jaxon
>
>
> Brad Pierce wrote:
> > Greg,
> >
> > Then could you please follow up to my message
> >
> >
> >
> > correcting my comment. Also, we need two STARs about this test
> > case, one against DC and one against VCS. This is an
> > example where it would have better to keep the discussion
> > on sv-forum --
> >
> > http://wwwin/hypermail/sv-forum/1280.html
> >
> > instead of cutting back the mailing list so that people don't
> > feel spammed.
> >
> > -- Brad
> >
> > -----Original Message-----
> > From: Greg Jaxon [mailto:Jaxon@synopsys.COM]
> > Sent: Friday, November 05, 2004 4:46 PM
> > To: Mark Hartoog; Surrendra Dudani; Brad Pierce
> > Subject: Re: FW: RE: Self-assignment of slice of unpacked array
> >
> >
> > Mark,
> >
> > 4.7 does not say that the assignments occur element-by-element.
> > It only says that the elements "correspond", meaning positionally,
> > as Doug's clarification is trying to make clear.
> >
> > Your reading of this as a shorthand "for" loop is way off, and
> > doesn't recognize the classical sources of this syntax in APL, VECTRAN
> > Fortran90 and similar predecessors of (s)Verilog. Even the memcpy()
> > routine in libc does not implement what you're suggesting: it actively
> > detects overlap so it can choose the right loop direction.
> >
> > The same thing is done with runtime dependence chacking in
> > compiled vector languages.
> >
> > Array slices need to behave as if they were copied into array
> > temporaries and used without reference to the original array locations
> > while they are being modified.
> >
> > The LRM authors let you down here, but I strongly feel that they
> > intended that we implement something like a classical data parallel
> > language.
> >
> > Greg
> >
> >
> >
> >>-----Original Message-----
> >>From: Mark Hartoog [mailto:markh@synopsys.COM]
> >>Sent: Tuesday, October 26, 2004 3:07 PM
> >>To: Surrendra Dudani; logie@synopsys.COM
> >>Cc: bpierce@synopsys.COM
> >>Subject: RE: RE: Self-assignment of slice of unpacked array
> >>
> >>
> >>The LRM in sections 4.2 and 4.7 says that unpacked arrays are
> >>assigned element by element, but does not specify the order, and
> >>packed arrays are "treated as a vector" in assignement.
> >>
> >>That is why this array slice example gives different results for
> >>packed and unpacked arrays.
> >>
> >>I vaguely remember once discussing the question of overlapping
> >>source and destination in array assignment. I think we should
> >>either specify an order for element assignment or we should
> >>say that the order is undefined. With ref ports it can be
> >>very difficult to tell if an assignment is overlapping or not.
> >>
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: Surrendra Dudani [mailto:Surrendra.Dudani@synopsys.COM]
> >>>Sent: Tuesday, October 26, 2004 11:18 AM
> >>>To: logie@synopsys.COM; markh@synopsys.COM
> >>>Cc: bpierce@synopsys.COM
> >>>Subject: Fwd: RE: Self-assignment of slice of unpacked array
> >>>
> >>>
> >>>Hi Logie/Mark,
> >>>This seems to be a problem. What do you think?
> >>>Surrendra
> >>>
> >>>
> >>>>X-Original-To: dudani@us04.synopsys.com
> >>>>Reply-To: <bpierce@synopsys.COM>
> >>>>From: "Brad Pierce" <bpierce@synopsys.COM>
> >>>>To: "Surrendra Dudani" <Surrendra.Dudani@synopsys.COM>
> >>>>Subject: RE: Self-assignment of slice of unpacked array
> >>>>Date: Tue, 26 Oct 2004 11:11:53 -0700
> >>>>X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
> >>>>Importance: Normal
> >>>>
> >>>>The following order gives the expected result
> >>>>
> >>>> A[4] = A[3];
> >>>> A[3] = A[2];
> >>>> A[2] = A[1];
> >>>>
> >>>>Either the LRM should say that the order of assignments is
> >>>>not specified, or it should say that the assignment happens
> >>>>all at once, as if there were some intervening temp variable.
> >>>>
> >>>>-- Brad
> >>>>
> >>>>
> >>>>-----Original Message-----
> >>>>From: Surrendra Dudani [mailto:Surrendra.Dudani@synopsys.COM]
> >>>>Sent: Tuesday, October 26, 2004 10:10 AM
> >>>>To: bpierce@synopsys.COM
> >>>>Subject: RE: Self-assignment of slice of unpacked array
> >>>>
> >>>>
> >>>>I see what is happening. For A, it is unpacked, so the rewrite
> happens
> >>>>sequentially as
> >>>>A[2] = A[1];
> >>>>A[3] = A[2];
> >>>>A[4] = A[3];
> >>>>This results in All A indices getting the value of A[1], which is 1.
> >>>>
> >>>>For B, it is packed, so a vector is assigned to another vector,
> without
> >>
> >>any
> >>
> >>
> >>>>sequential rewrite of individual elements, as
> >>>>B[2:4] = B[1:3];
> >>>>
> >>>>As I mentioned before, this is a problem with SV, as it allows one
> to
> >>
> >>view
> >>
> >>
> >>>>packed quantities as vectors and arrays at the same time. Either one
> is
> >>>>semantically valid, producing different results.
> >>>>
> >>>>Good example!
> >>>>Surrendra
> >>>>At 09:48 AM 10/26/2004 -0700, you wrote:
> >>>>
> >>>>
> >>>>>They are not equal with either tool. For example, using
> >>>>>
> >>>>> /build/vcsnightly/solaris_Base_32/bin/vcs
> >>>>>
> >>>>>Chronologic VCS simulator copyright 1991-2004
> >>>>>Contains Synopsys proprietary information.
> >>>>>Compiler version 8.0_PreAlphaExperimental; Runtime version
> >>>>>8.0_PreAlphaExperimental; Oct 26 09:45 2004
> >>>>>
> >>>>>A|1|1|2|3|| 1| 1| 1| 1|
> >>>>>B|1|1|2|3|| 1| 1| 2| 3|
> >>>>> V C S S i m u l a t i o n R e p o r t
> >>>>>
> >>>>>Likewise for the latest internal DC build.
> >>>>>
> >>>>>-- Brad
> >>>>>
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: Surrendra Dudani [mailto:Surrendra.Dudani@synopsys.COM]
> >>>>>Sent: Tuesday, October 26, 2004 9:37 AM
> >>>>>To: bpierce@synopsys.COM
> >>>>>Subject: RE: Self-assignment of slice of unpacked array
> >>>>>
> >>>>>
> >>>>>Seems to me that A and B should display the same values. Are they
> no
> >>
> >>equal
> >>
> >>
> >>>>>in DC and VCS?
> >>>>>Surrendra
> >>>>>At 09:31 AM 10/26/2004 -0700, you wrote:
> >>>>>
> >>>>>
> >>>>>>Surrendra,
> >>>>>>
> >>>>>>This test case seems like a bug to me. What do you think?
> >>>>>>The only difference between the two assignments is the
> >>>>>>packedness of the targets.
> >>>>>>
> >>>>>>-- Brad
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: owner-sv-forum@synopsys.COM
> >>
> >>[mailto:owner-sv-forum@synopsys.COM]On
> >>
> >>
> >>>>>>Behalf Of Brad Pierce
> >>>>>>Sent: Friday, October 22, 2004 7:39 PM
> >>>>>>To: sv-forum@synopsys.COM
> >>>>>>Subject: Self-assignment of slice of unpacked array
> >>>>>>
> >>>>>>
> >>>>>>Should A and B display the same values in the following example?
> >>>>>>Why do our tools say 'no'?
> >>>>>>
> >>>>>>-- Brad
> >>>>>>
> >>>>>>module m;
> >>>>>>always begin
> >>>>>> reg [31:0] A[1:4];
> >>>>>> reg [1:4] [31:0] B;
> >>>>>> A[1] = 1; A[2] = 2; A[3] = 3; A[4] = 4;
> >>>>>> B[1] = 1; B[2] = 2; B[3] = 3; B[4] = 4;
> >>>>>>
> >>>>>> A[2:4] = A[1:3];
> >>>>>> B[2:4] = B[1:3];
> >>>>>> $display("A|1|1|2|3||%d|%d|%d|%d|", A[1], A[2], A[3], A[4]);
> >>>>>> $display("B|1|1|2|3||%d|%d|%d|%d|", B[1], B[2], B[3], B[4]);
> >>>>>> end
> >>>>>>endmodule
> >>>>>>Archive: http://wwwindev.synopsys.com/hypermail/sv-forum/
> >>>>>
> >>>>>
> >>>>>
> >>>>>**********************************************
> >>>>>Surrendra A. Dudani
> >>>>>Synopsys, Inc.
> >>>>>377 Simarano Drive, Suite 300
> >>>>>Marlboro, MA 01752
> >>>>>
> >>>>>Tel: 508-263-8072
> >>>>>Fax: 508-263-8123
> >>>>>email: Surrendra.Dudani@synopsys.com
> >>>>>**********************************************
> >>>>
> >>>>
> >>>>
> >>>>**********************************************
> >>>>Surrendra A. Dudani
> >>>>Synopsys, Inc.
> >>>>377 Simarano Drive, Suite 300
> >>>>Marlboro, MA 01752
> >>>>
> >>>>Tel: 508-263-8072
> >>>>Fax: 508-263-8123
> >>>>email: Surrendra.Dudani@synopsys.com
> >>>>**********************************************
> >>>
> >>>
> >>>
> >>>**********************************************
> >>>Surrendra A. Dudani
> >>>Synopsys, Inc.
> >>>377 Simarano Drive, Suite 300
> >>>Marlboro, MA 01752
> >>>
> >>>Tel: 508-263-8072
> >>>Fax: 508-263-8123
> >>>email: Surrendra.Dudani@synopsys.com
> >>>**********************************************
> >>
> >>
> >>
> >
> >
>
Received on Mon Nov 8 15:49:31 2004