Greg, I do understand your proposal except the default:value case. I see that if we apply the default:value rule, more than one union member could be candidate of the assignment of the value. It seems that you imply that all candidates are assigned and the last matchable member assignment wins? Why would this be different from the positional association of an integral value - your choice there is the largest member of the union. Francoise ' -----Original Message----- From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg Jaxon Sent: Monday, February 27, 2006 5:48 PM To: francoise martinolle Cc: sv-bc@eda.org Subject: Re: [sv-bc] Union assignment patterns Francoise Martinolle wrote: > > Unions are problematic, I would prefer not to allow them. But of course they turn up deeply nested sometimes. > By the way, I do not see anything in the LRM specified for an > assignment pattern to a struct containing an union type member. So > what is the behaviour? You're right, the LRM wording has side-stepped plain unions. I believe that was an oversight, because most of the required behavior is an obvious extension of the rules for structs. First, it should be obvious that the union type is imposed by the assignment context upon the '{...} assignment pattern. In the following discussion, I use the term "value" to mean both "data object" and "variable lvalue". Each of these has a definite data type at the elaboration stage where assignment patterns become resolvable. Within a union assignment pattern, name:value clauses are not a problem. Type:value clauses are also not a problem, unless we must quibble about WHICH of the overlaid fields of that type is being assigned. Default:value clauses that descend into a union are certainly special;-) Recall that the matching rule for default assignment is that it should fill fields whose types match the value's. I think that works for unions too, analogous to the way type:value patterns work. The burden of filling "every" field of a struct converts to filling "at least one" field of a union. I think the "last assignment wins" rule used elsewhere is the right resolution for multiple union fields being assigned. The extra verbiage needed to cover these cases? Try adding "and/or union" wherever "structure" is mentioned in 8.13. The tough issue with assignment patterns for unions is the treatment of positional aggregations, such as '{0} or '{1{0}}. Obviously, we only need ONE value (or lvalue) to fill a union. We must decide which field to use in making the assignment, because its declared type will influence the final bit pattern produced. A) Since this issue is notational, and not something that arises at runtime, it could be a syntax error. However, there are two reasonable definitions that might work: B) Perhaps a positional list that comes into correspondence with a union object should be required to contain EMPTY list positions, one for each field NOT assigned, and exactly one position with a value corresponding to the union field that will be assigned. It's odd; but also satisfyingly punitive to those who try to cut corners using unions. This preserves the ability to use nested assignment patterns to pick up the declared type of the union field at each list position. Recall that positional assignment patterns for structs correspond to the struct's fields in declared order. This order gives us nested assignment-like contexts where even more assignment patterns can be written. C) Only one value can be listed positionally; it will either be strongly typed or it will be integral. It CANNOT be an assignment pattern, since there either are or potentially could be several incompatible types with equal claim to this context. If it is strongly typed, use its type to find the top-level field of the union which matches (but unlike default:value, DO NOT RECURSE into any substructure of the union elements looking for a match). If it is integral, then we should be prepared to match top-level fields of any packed type. There might be several. They may differ in signedness and width. Their signedness does not matter, since it will not affect extensions done to assign the field. Their width is relevant, though. The candidates for breaking this ambiguity are: 1) Use the first integral type field in the union. 2) Use the last. 3) Use the largest. 4) Use the smallest. 5) Use a (possibly synthetic) integral type whose width is the total size of the union. 6) Use the smallest which covers the width of the supplied (positional) value. Of the choices for option C, I'd say (3) "the largest" is the wise choice. I don't care for (5), because it seems to give us a definition even if there is /no/ integral type field in the union. (6) might be annoying. Notice that if the union is laid out with the LSB of all integral type fields aligned, then (3) sets all the bits so that accesses to the smaller fields effectively truncate as the original assignment would have truncated. This gives maximal preservation of semantics and syntax when an integral type field gets converted to a union of integral types and not all the assignment patterns that use it get rewritten. So the choice of A, B or C, and within C of which way to resolve the ambiguity, can be subject to a vote. Greg Jaxon > I see that we have allowed struct pattern assignments to tagged unions > see section 8.14. > > Francoise > ' > > -----Original Message----- > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of > Greg Jaxon > Sent: Monday, February 27, 2006 1:46 PM > To: francoise martinolle > Cc: sv-bc@eda.org > Subject: Re: [sv-bc] Aggregate / struct - 2 questions > > That's a compelling idea, Francoise. For structs, I think > member:value notation would be even better (or a format option). > Perhaps you could also imagine a way to handle union types? > I suggest displaying each union in ALL its possible interpretations. > Since this can exponentially explode the amount printed, it may > discourage use of (non-tagged) unions. > > Your plan amounts to a default definition for the to_string() > class method that Jonathon suggests. Perhaps it should be provided > as both a format notation and a built-in method for any user-defined type. > > I don't recall seeing a $display format that explicitly made Verilog > numbers before. That seems like an adjunct to providing this capability. > > Greg > > > Francoise Martinolle wrote: > >> How about creating a new format which would return the aggregate >>constant value for the struct by displaying the struct aggregate value >>using the positional aggregate form and default formats for each >>member type. >>Ex: >> >> typedef struct { >> bit [3:0] dst_addr; >> bit [3:0] src_addr; >> bit [31:0] data; >> bit [7:0] crc; >> } pkt_s; >> >>$display("pkt1 = %a", pkt1) >> >>pkt1 = '{4'b0, 4'b0, 32'b0, 8'b0} >> >>We could be defining a default format for datatype, unless there is >>already an existing mapping. >> >>Francoise >> ' >>-----Original Message----- >>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of >>Clifford E. Cummings >>Sent: Monday, February 27, 2006 12:55 PM >>To: sv-bc@eda.org >>Cc: nikhil@bluespec.com; Brad Pierce; matthew.r.maidment@intel.com >>Subject: RE: [sv-bc] Aggregate / struct - 2 questions >> >>Brad, Matt & Nikhil - >> >>Question for the three of you below. >> >>Other comments included. >> >>At 08:44 AM 2/27/2006, Jonathan Bromley wrote: >> >> >>>>Is there some way to unpack the struct (almost like aggregate >>>>de-assignment) so that the display command could be written >>>>something >>>>like: >>>> >>>>$display("dst=%h src=%h data=%h crc=%h", pkt1); >>> >>>I personally don't think this is a very good idea. >>> >>>If the struct were packed, as is likely for synthesis, then you >>>couldn't reasonably do this (because the packed struct also has a >>>perfectly good integer value when taken as a whole). >>>This could lead to all sorts of hideous ambiguity; how about this... >>>(p2 is of the same type as pkt1): >>> >>>$display( >>> "pkt1=%h, p2.dst=%h p2.src=%h p2.data=%h p2.crc=%h", >>> pkt1, p2); >>> >>>How could $display work out which %h is associated with what? >> >> >>I was hoping there was some undiscovered piece of magic, perhaps using >>one of the streaming operators, that would take each field of the >>struct and parse them out in struct-order to the respective %h format >>specifiers. I did not really think it existed but sometimes I ask >>these questions and people share very clever and concise solutions. Oh > > well, no big deal! > >> >>>For simulation only, you could use a class instead, and then the >>>class could provide its own to-string method - psdisplay() in VMM-speak. >>>And indeed, since we now have a full-fledged string data type, it's >>>easy to provide a to-string function for any data type. >>> >>>I sometimes wonder whether there is any utility at all in unpacked >>>structs. They make little sense for synthesis, and for simulation >>>it's surely better to use a class; the class can then have a pack >>>method that converts the appropriate parts of its content into a >>>packed struct suitable for injection into an RTL model. >> >> >>Interesting questions. Perhaps we could get the following three >>committee members to respond: >> >>Matt Maidment from Intel, who has been using SV for synthesis for 3-4 >>years now. >>Brad Pierce (and Karen if she has time) on Synopsys' take on unpacked >>structs for synthesis. >>Nikhil Rishiyur from the Bluespec synthesis perspective. >> >>Regards - Cliff >> >> >> >>>-- >>>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 >> >> >>>This e-mail and any attachments are confidential and Doulos Ltd. >>>reserves all rights of privilege in respect thereof. It is intended >>>for the use of the addressee only. If you are not the intended >>>recipient please delete it from your system, any use, disclosure, >>>or copying of this document is unauthorised. The contents of this >>>message may contain personal views which are not the views of Doulos >>>Ltd., >> >>unless specifically stated. >> >>---------------------------------------------------- >>Cliff Cummings - Sunburst Design, Inc. >>14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005 >>Phone: 503-641-8446 / FAX: 503-641-8486 cliffc@sunburst-design.com / >>www.sunburst-design.com Expert Verilog, SystemVerilog, Synthesis and >>Verification Training >> >> > > >Received on Mon Feb 27 20:03:53 2006
This archive was generated by hypermail 2.1.8 : Mon Feb 27 2006 - 20:04:21 PST