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

From: Michael Burns <michael.burns_at_.....>
Date: Tue Dec 04 2007 - 08:57:44 PST

Jonathan,

Jonathan Bromley wrote:

Dave

Thanks for this excellent exposition.

  

a) the reference is a handle to the element, or
b) the reference is a handle to the queue + an offset?
I believe the intent is answer (a)
    

I definitely agree that this makes the most sense,
partly because it is precisely the behavior that a 
user would likely get if they were to implement a 
double-ended linked list of class objects for 
themselves.  Option (b) simply doesn't do the
things I would want to do with such references -
even the most obvious thing, keeping a reference
to a transaction as it flows through a FIFO, 
requires (a).
  

I was the one who raised the possibility of b), basically to make the semantics simpler for problematic cases. The issue is that I don't think we have any definition now for what precisely a queue element is, how they are assembled into a queue, and how the various operations affect the arrangement of elements in the queue. I will assume that nobody wants a queue element to be a first-class type (e.g., no variables of type "queue element"), but since it affects user-visible behavior it must be defined. By the way, I think I almost gave some folks a heart attack when I compared queues to linked lists in the meeting :)

I don't really want b) nor do I think any users would; however, I think doing a) properly requires more work.

Perhaps it would help to define a queue as an assemblage of variables rather than introducing a new "queue element" concept. That's what we really want - for references to queue elements to work like references to regular variables of the same type.  The point should be made that the contained variables move around in the queue (relative to the queue indices)  under various operations, and that references to elements follow the variables, not the indices.

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? 
    

I guess I've already made my own position clear on this
by writing-up the 1702 proposal to say that any write
to an unpacked array variable trashes any existing
elements in the written array.  I guess I should have
been clearer in 1702 about what happens if you write
to *part* of an array:
    q[2:3] = '{1,2};
My expectation here would be that any references to
q[2] or q[3] would go stale, but references to any
elements in q[0:1] or q[4:$] would remain live.

I just can't see any alternative that would make
consistent sense across all the variety of possible
operations on a queue variable.  I agree that it
forces a potentially inefficient copy in some 
situations where that could perhaps be avoided, 
but I'd far sooner have that than confusing or
fragile behavior.  I also think that it's a
behavior that's easy to define and easy to 
educate users about.  And, as you say, a few new
queue methods could claw back the efficiency
in most of the practically useful cases.
  

This was my feeling as well - that assignment to a queue outdates references to the original queue elements, even if the RHS of the assignment is composed of a concatenation of elements of the original queue. I hadn't thought of assignment to part-selects of queues, but I see no problem with the behavior you describe.

Another way of describing this would be to say that assignment cannot be used to rearrange the elements of a queue in a reference-preserving way (regardless of what the RHS is).

Note that this behavior means that the descriptions of queue methods will have to be changed so that they are no longer in terms of queue concat assignments.

--Mike

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

  

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Tue Dec 4 08:58:20 2007