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

Do any other programming languages have a queue construct that defines rules
for these circumstances?  I'm not saying that we necessarily need to mimic
other language behavior, but I would like to take it into consideration
before stating my user opinion on this.

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


 


  _____  

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  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 


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