RE: [sv-ec] Mantis 1702 - queue concatenation

For background, see http://www.eda-stds.org/sv-ec/hm/3482.html .

Regards,
Shalom 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Jonathan Bromley
> Sent: Tuesday, November 13, 2007 12:47 AM
> To: sv-ec@server.eda.org
> Subject: [sv-ec] Mantis 1702 - queue concatenation
> 
> hi EC
> 
> Before I put in the work of preparing a real proposal, I'd 
> value your feedback on whether the following makes sense for 
> dealing with the disputed Q={Q,element,...} syntax.  Perhaps 
> I'm being very naive here, but it seems to me that by 
> restricting the queue-concat syntax to the RHS of an 
> assignment-like context you can come up with a simple 
> definition that retains backward compatibility with the de 
> facto behaviour and with the LRM examples.  I suspect that 
> this restriction is harmless in practice.
> 
> I didn't want to press-gang the '{} syntax into service for 
> this.  There would be so many differences between '{} for 
> queue targets vs. any other kind of target that I think it's 
> better to stay with {}.
> And because queues are unpacked, there's no risk of confusion 
> between this and the traditional concatenation meaning of {} 
> (a normal concatenation represents a packed object, and can 
> never be assigned to any unpacked array).
> 
> Note that I've tightened up the definition of a "queue"
> to be an array whose slowest-varying dimension is a queue 
> dimension.  It might be necessary to tweak the wording of 
> 7.11 to match.  I hope this means that the definition is 
> robust against complicated types like
>   typedef int silly_queue [$][10][$][][5]; because that's 
> still just a queue of these:
>   typedef int silly_item [10][$][][5];
> and the rule about what's an assignment-like context in 10.8 
> would prohibit the appearance of a queue-concat as an item in 
> an outer queue-concat.
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 1) Define "Queue concatenation" syntax
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Add a new subclause 10.9.3 to 10.9 Assignment Patterns, 
> saying roughly:
> 
> Queue concatenations provide a flexible way to write 
> expressions of queue type.  Queue concatenations may appear 
> as the source expression in an assignment-like context, and 
> shall not appear in any other context. 
> The target of such assignment-like context shall be a queue, 
> defined for the purpose of this clause as an array whose 
> slowest-varying dimension is a queue dimension.
> 
> A queue concatenation shall be written as a comma-separated 
> list of zero or more items enclosed in braces.  If the list 
> has zero items, the concatenation shall represent a queue 
> with no elements.  Otherwise, each item shall represent one 
> or more elements of the resulting queue, interpreted as follows:
> - an item whose self-determined type is assignment-
>   compatible with the element type of the target
>   queue shall represent one element;
> - an item whose self-determined type is a queue whose
>   element type is assignment-compatible with the element
>   type of the target queue shall represent as many
>   elements as exist in that item;
> - an item of any other type shall be illegal.
> The elements thus specified shall be arranged in left- 
> to-right order to form the resulting queue.
> 
> [QUESTION: Do we want other unpacked arrays of appropriate 
> type to be considered as candidate items? I would say not.
> Only queues or elements may appear in the concatenation.]
> 
> 2) Rewrite 7.11.1
> ~~~~~~~~~~~~~~~~~
> Delete the excessively vague sentence "Queues and dynamic 
> arrays have the same assignment and argument passing 
> semantics."  Add new words to capture any part of that 
> sentence that needs preserving.  Cross-reference to new
> 10.9.3 (queue concatenations).  I believe that my proposed 
> text for 10.9.3 legitimises all the examples in 7.11.1.
> Examples of more elaborate types could be added if you wish.
> 
> 3) BNF
> ~~~~~~
> Add BNF for queue concatenation.  The syntax would be 
> identical to the existing production "concatenation" (A.8.1), 
> but a note would need to be added referencing 10.9.3.
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> If the consensus is that this is not crazy, I'll write it up properly.
> 
> thanks
> --
> 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.
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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