A queue is still an unpacked array and the current assignment pattern rules are not effected. We are just trying to resolve the rules for the concatenation operator when not int the context of an integral type; specifically in the context of an assignment to a queue. Assignment patterns '{} no longer have anything to do with the concatenation operator. int q[$]; q = '{1,2,3}; // still a legal assignment pattern q = '{0:1,1:2,2:3}; // still legal, couldn't do this with a concat In an assignment pattern, each element must be assignment compatible with the array q's element type q = {1,2,3}; // concatenation of 3 elements q = {q,4}; // concatenation of an array plus one element In a queue concatenation, each operand is either assignment compatible with q as an array or assignment compatible with the array q's element type. The two problems with this has been 1) the dual assignment context creates an ambiguity when nesting {}, and 2) separate compilation has a problems when {} are used in module ports and function arguments. Dave -----Original Message----- From: owner-sv-bc@server.eda.org on behalf of Moumita Sent: Wed 11/14/2007 6:30 AM To: Bresticker, Shalom Cc: Jonathan Bromley; sv-ec@server.eda.org; sv-bc Subject: [sv-bc] Re: [sv-ec] Mantis 1702 - queue concatenation Hello, According to SV LRM 3.1a - only {} is used for both concatenation and assignmentpattern. For packed array {} is considered as concatenation and for unpacked array it is considered as assignment pattern. But 1800-2005 SV LRM introduce '{} for supporting assignment pattern. an '{} is used as assignment pattern for both packed array and unpacked array. This mail includes following statements- " 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)." So my question is- 1. whether queue is considered as aggregate expression or not in 2008 SV LRM? If yes then some inconsistencies may arise as by definition only '{} is part of aggregate expression, not a simple concat. 2. If we have an array like a[$][2:0][] then to assign the array user needs to use {}(for queue) and '{} both in nested way, which may make more confusion. How to address those issues? We have seen lots of confusion when '{} is first introduced in SV 1800-2005 LRM, both from design and tool side. Still some tools not yet updated to '{} support. I think there should be an uniform guideline for all types of arrays in the LRM to avoid any confusion in future. Thanks and regards, Moumita Bresticker, Shalom wrote: >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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Nov 14 09:43:52 2007
This archive was generated by hypermail 2.1.8 : Wed Nov 14 2007 - 09:45:27 PST