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

Dave: The most definitive statement on this subject in 1364 occurs in 9.2.1
right after the syntax box for blocking assignment. Here it is clear that the
RHS was evaluated as the statement begins execution, and any evaluation of the
LHS (which gives you your first clue about a data dependence) is explicitly
said to happen AFTER the scheduled delay.

Things deteriorate from here, though. Procedural continuous assignments
cannot have part-selects of the LHS (according to the text), but the BNF seems to
allow it. There probably ARE some errors here.

But you're right that we all consider our 1364 implementations to be sound
on the treatment of part-select assignment.

If Section 4.7 (Array assignment) needs anything at all, it may be some words
about how many change events are generated by an assignment which more than one bit,
and if multiple events are specified something about their order. It just seems
inconceivable that array modifications would interleave with RHS array references.

Mark Hartoog wrote:
> I believe this erratum is really about assignment of unpacked arrays when
> source and target overlap.

Right, which was why I wrote into 7.16 - this seemed like the natural home
for aggregate data transfers. I thought it should just echo what we think we
believe about Verilog vector assignments.

> 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});

Thanks for bringing the terminology of function arguments into the picture.
I think aggregate copying resembles the copyin/copyout calling method of
input and output arguments.

You're correct that the evaluation of Y=X where both are ref arguments of
the same type becomes more complicated, and it requires the compiler to
invent a temporary storage for the unpacked array elements.

By using ref arguments here, the user is reserving the right to write an
explicit "for" loop that may intentionally implement an aliased data dependence.
However, bu saying just Y=x, I don't think the user is asking for random
outcomes when X and Y are aliased to each other. I note that if the arguments
either argument has a non-ref direction, the naive implementation works fine!

In C, pointers to X and Y can be compared, so a savvy user can choose to
resolve the data dependence in his favorite way. But "ref" args more closely
resemble C++ reference arguments (suffix-&).

In considering Y=X above, I'll note that, if X and Y were class references,
C++ would call a copy construction of the expression's class
followed by an operator=() to implement the assignment itself.

The default header for a C++ class assignment operator is:
     C& C::operator=( const C& );
... the "const" modifier assures us that the RHS is not modified during the
execution of the assignment. So too with SV aggregate assignments.

>
> It is not clear to me from reading sections 4.2 and 4.7 on array assignments
> that this is what was intended.
>
> 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.

I don't think that's necessary, but redundancy probably helps more than it hurts.

>
>
>>-----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 16:57:45 2004