RE: [sv-bc] Aggregate / struct - 2 questions

 
Unions are problematic, I would prefer not to allow them.
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?
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
> 
>