Re: [sv-bc] RE: [sv-ec] Mantis 1702 unpacked concatenation of arrays

Arturo Salz wrote:
> I agree that for the first issue (a) is the only sensible 
> implementation, and possibly matches most user’s expectation. If someone 
> wants (ref + index) they can certainly code that explicitly.
> 
>  
> 
> I also agree with Dave on the second issue, that (b) is undesirable. 
> And, we could go with either (a) or (c). I don’t think (d) is an option: 
> It is too underspecified.
> 
> I guess that BC prefers (c)?


Well, I certainly would and I think that would likely be the
general BC consensus.  (a) opens many questions about exactly
what conditions constitute the special behavior.

Gord


> 
>  
> 
>             Arturo
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of 
> *Rich, Dave
> *Sent:* Monday, December 03, 2007 11:44 PM
> *To:* sv-bc@eda.org; sv-ec@eda.org
> *Subject:* [sv-ec] Mantis 1702 unpacked concatenation of arrays
> 
>  
> 
> During today’s sv-ec discussion on this mantis issue, I was asked to 
> poll users on their opinions about a few subtle but crucial issues 
> surrounding the implementation of a queue. The implementation may expose 
> user visible behaviors and will have a direct impact on the direction we 
> take resolving 1702.
> 
>  
> 
> The first issue is independent of the concatenation and is general to 
> queues. This shows up when an element of a queue is passed by reference 
> to a task and that task later modifies that element after the original 
> queue has modified the number of elements in the queue. Understanding 
> the semantics of this example will help explain the dilemma we face.
> 
>  
> 
> module top;
> 
>    task automatic incr(ref int arg);
> 
>       #10 arg++;
> 
>    endtask
> 
>  
> 
>    int q[$];
> 
>    initial begin
> 
>       q = '{1,3,5,7};
> 
>       fork
> 
>              incr(q[0]); // front of queue q[0] = 1
> 
>              incr(q[$]); // back of queue q[3] = 4
> 
>       join_none
> 
>       #5 q.push_back(9);
> 
>       #10
> 
>             $display("q=%p",q);
> 
>    end
> 
> endmodule : top
> 
>  
> 
> What should the final contents of the queue be? Section 13.5.2 of draft 
> indicates that since no elements of the q have been deleted, the 
> references are still current (not /outdated/) and q = ‘{2,3,5,8,9};. I 
> think there is consensus on this answer.
> 
>  
> 
> But what if I replace the q.push_back(9) with. Again, using the same 
> rule, no elements have been deleted and the references are still 
> current. The LRM is not clear which elements the current references 
> point to. So is the result
> 
>  
> 
> a) q = ‘{9,2,3,5,8}  - the reference is a handle to the element, or
> 
> b) q = ‘{10,1,3,6,7} – the reference is a handle to the queue + an offset?
> 
>  
> 
> I believe the intent is answer a), and most implementers prefer a) 
> because the task that has the reference argument does not need to know 
> anything about what kind of /int/ reference it has. However I have heard 
> user expectations either way. Do others agree or disagree?
> 
>  
> 
> Now to the second issue that is more specific to unpacked concatenation. 
> What if the queue methods are replaced with concatenation:
> 
>  
> 
> q = {9,q}; // is this equivalent to a q.push_front(9)?
> 
>  
> 
> Some possible answers that depend on the implementation details of the 
> queue are:
> 
>  
> 
> a) q = ‘{9,2,3,5,8} – the same as the result of q.push_front(9)
> 
> b) q = ‘{10,1,3,6,7} – unlikely queue is implemented as an array
> 
> c) q = ‘{9,1,3,5,7} – all references become outdated because the queue 
> is copied in whole
> 
> d) Implementation dependent result between a) and c) (already 
> discounting b))
> 
>  
> 
> Choice a) is problematic because we are not going to get consensus on 
> the forms of concatenation that can be recognized as equivalent methods 
> within the current schedule. Even if we were to get agreement on the 
> forms that can be recognized, we would still have to agree on the 
> behavior of the forms that couldn’t be recognized.
> 
>  
> 
> Choice b) I hope can be eliminated from the discussion. (Same as first 
> issue)
> 
>  
> 
> Choice c) is problematic because we will never be able to back to a) in 
> a later revision of the LRM and it prevents optimizations when dealing 
> with large queues by forcing a copy of the queue. For example, assume q1 
> has a large number of elements:
> 
> q1 = {q1,q2, q3}; // concatenate multiple queues
> 
> q1 = q1[0:$-5]; // delete multiple elements
> 
> q1 = q1[n:m]; // take a slice if a queue
> 
> We could create more queue methods to address the optimization concerns.
> 
>  
> 
> Choice d) is problematic because users don’t like non-portable results.
> 
>  
> 
> Do users have any opinions on the choices given?
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> David Rich
> Verification Technologist
> Design Verification & Test Division
> Mentor Graphics Corporation
> dave_rich@mentor.com
> Office:   408 487-7206
> Cell:     510 589-2625
> 
>  
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>*, and is
> believed to be clean.
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. *

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.