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
> 
>