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:10:31 2004
This archive was generated by hypermail 2.1.8 : Mon Nov 08 2004 - 15:10:36 PST