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

To answer Dave's question regarding user preference, I asked one of my
training customers about their usage of queues and forwarded Dave's examples
to them.  I am not at liberty to say who this user is, but I can share their
response:

> Stu,
> 
> I am indeed using queues extensively in our verification
> environment.  I use them carefully, understanding their
> dynamic nature (at least in my environment), serialize
> access to them using semaphores.  It's probably
> over-conservative, but I distinctly *don't* want the kinds
> of problems demonstrated by the examples below.  In my
> environment, queues are accessed asynchronously by many
> processes, so care is taken to make every operation atomic
> using semaphores.  In addition, I wouldn't use a ref to a
> queue element outside of the protected access operation
> simply because the queue *is* dynamic.
> 
> All that preaching aside, if I *did* decide to start
> passing around refs to dynamic queues (shudder), I would
> prefer the behavior sited in example "a".
> 
> Regarding the concatenation question, I guess I prefer
> example "a", but again, I think passing around refs to
> dynamic queues is bad form.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898
 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Rich, Dave
> Sent: Tuesday, December 04, 2007 12:35 AM
> To: sv-bc@server.eda.org; sv-ec@server.eda.org
> Subject: [sv-ec] Mantis 1702 unpacked concatenation of arrays 
> - RESEND missing text
> 
> 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? 
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 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, and is
believed to be clean.