[sv-bc] Re: [sv-ec] Mantis 1702 unpacked concatenation of arrays - RESEND missing text

For the first case:

    a) is best - the reference is a handle to the element
       I am having a hard time understanding how anyone would
       expect b).

For the second case:

    a) would be desirable, but I recognize the complications with it
       and am willing to forego this option and go along with c)
    c) is what seems to make most sense.
       I am hoping that implementors will be clever enough to come up
       with ways to optimize this type of operation.


Neil





Rich, Dave wrote:
> 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 #5 q.push_back(9) with #5 q.push_front(9). 
> Again, using the same rules, 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 in the example above are replaced with 
> concatenation?
> 
>  
> 
> # 5 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?
> 


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