Clifford E. Cummings wrote: > Brad, Matt & Nikhil - > > Question for the three of you below. > ... Cliff, Below is a description of what we do in Bluespec. I don't think it'll help the current discussion, since it will fall in the category of possible future extensions, but I'll describe it briefly anyway, fyi. In Bluespec we don't use the 'packed' keyword on types at all, i.e., all structs exist only in their unpacked forms. As an orthogonal feature to all types, we have a pair of overloaded functions 'pack' and 'unpack' (in Bluespec you can overload functions in addition to operators). For each type T on which these overloaded functions are defined, pack converts from T to bits and unpack converts from bits to T. Register assignment implicitly uses 'pack' and register reads implicitly use 'unpack'. In order to avoid the tedium of having to define pack and unpack on each type, there is a default mechanism. For structs, it's the obvious concatenation of 'pack' applied to each of the members. Thus, you get an obvious default 'pack/unpack', but you can override it with your own custom 'pack/unpack' if you want. So, the user typically just thinks and works in terms of the unpacked struct, no matter what its bit representation. The original discusssion was, I think, about printing structs conveniently. We do not currently have any built-in way to do this directly, but the same overloading idea works here as well, analogous to the 'to-string' idea that someone else mentioned. I.e., you can define an overloaded function 'to_string()' that will convert a struct to a string. We expect, in the future, to have a default 'to_string' kind of function for structs. Nikhil Clifford E. Cummings wrote: > 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 Tue Feb 28 10:39:04 2006
This archive was generated by hypermail 2.1.8 : Tue Feb 28 2006 - 10:40:03 PST