[sv-bc] 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, and is
believed to be clean.