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.Received on Wed Nov 14 06:40:32 2007
This archive was generated by hypermail 2.1.8 : Wed Nov 14 2007 - 06:42:21 PST