Date: Tue Aug 09 2011 - 09:58:54 PDT
It's jarring to see the use of pragmas (not used much in language and DPI avoided it) and it's extra typing vs the attributes. Moreover, that some parts are declared as regular syntax and some as pragmas is also jarring. Is this what you envision with your layering technique?
1. In come compilation unit(s) packet will be used as SystemVerilog only (`include "packet.svh")
2. Some unit(s) will have use of exporting to DPI (`include "packet_dpi.svh")
3. Some unit(s) will export all but f2 (`include "packet_configuration.svh")
Matt
-- Matt Maidment mmaidmen@ichips.intel.com From: Vitaly Yankelevich [mailto:vitaly@cadence.com] Sent: Tuesday, August 09, 2011 9:06 AM To: Maidment, Matthew R; Jim Vellenga; brad_pierce@acm.org; Rich, Dave Cc: SystemVerilog CC DWG (sv-cc@eda.org); sv-bc@eda.org Subject: RE: [sv-cc] Re: [sv-bc] Mantis 3087 Uses of comment pragmas instead of attributes The common opinion is to replace the comment-based pragmas with `pragmas or attributes. The advantage of using `pragma syntax rather than an attribute is that the pragma can be added separately of the declaration, while the attribute must be provided together with a declaration. Using configuration pragmas separate from the declarations provides for higher flexibility. For example, one can use different include files with different DPI-OO configuration options without changing the core source code. So my preference is to support the following syntax (with an example how it can be layered with help of include files): packet.svh: class packet; extern function int f1(); extern function void f2(); endclass packet_dpi.svh: `include "packet.svh" export "DPI-OO" "ref" class packet; packet_configuration.svh: `include "packet_dpi.svh" `pragma DPI-OO class="packet" exclude="f2" language="SystemC" foreign="P::Packet" Vitaly From: Maidment, Matthew R [mailto:matthew.r.maidment@intel.com] Sent: Monday, August 08, 2011 9:52 AM To: Vitaly Yankelevich; Jim Vellenga; brad_pierce@acm.org; Rich, Dave Cc: SystemVerilog CC DWG (sv-cc@eda.org); sv-bc@eda.org Subject: RE: [sv-cc] Re: [sv-bc] Mantis 3087 Uses of comment pragmas instead of attributes I was demonstrating how attributes can be used in lieu of comment-based pragmas for clause 36 of the proposal. -- Matt Maidment mmaidmen@ichips.intel.com<mailto:mmaidmen@ichips.intel.com> From: Vitaly Yankelevich [mailto:vitaly@cadence.com] Sent: Sunday, August 07, 2011 2:09 AM To: Maidment, Matthew R; Jim Vellenga; brad_pierce@acm.org; Rich, Dave Cc: SystemVerilog CC DWG (sv-cc@eda.org); sv-bc@eda.org Subject: RE: [sv-cc] Re: [sv-bc] Mantis 3087 Uses of comment pragmas instead of attributes Just in case if the proposal below is to replace the export/import DPI-OO declarations with attributes completely: I think that the basic declarations' syntax should be stronger than attributes because the class properties of being export/import class directly influence compilation of the classes and objects. In particular: - an allocation of an import class object should be implemented differently than a native class - garbage collection of an export/import classes should be implemented differently - arguments of DPI-OO subroutines need to be checked by the compiler to be export/import DPI-OO classes - DPI-OO copy classes are required to support deep copying. Given the above, I think that the attributes can replace the comment-based pragmas but they cannot substitute the explicit export/import class declarations completely. Vitaly From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Maidment, Matthew R Sent: Thursday, August 04, 2011 8:02 PM To: Jim Vellenga; brad_pierce@acm.org; Rich, Dave Cc: SystemVerilog CC DWG (sv-cc@eda.org); sv-bc@eda.org Subject: RE: [sv-cc] Re: [sv-bc] Mantis 3087 Uses of comment pragmas instead of attributes Here's some idea of what attributes might look like (*DPIOO, export, exclude="f2", language="SystemC" foreign="P::Packet"*) class packet; extern function int f1(); extern function void f2(); endclass class packet; (*DPIOO, export, foreign="GetByte" *) function byte get_byte(int j); ... endfunction // pragma DPI-OO export function get_byte foreign=GetByte endclass The benefits of attributes include clearer semantics as to which syntax elements they apply as to where they apply and that they can be interrogated by VPI. I'd like to see attributes given more consideration given that strings can store most everything and there is no ambiguity regarding placement. Matt -- Matt Maidment mmaidmen@ichips.intel.com<mailto:mmaidmen@ichips.intel.com> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Jim Vellenga Sent: Wednesday, August 03, 2011 8:55 AM To: brad_pierce@acm.org; Rich, Dave Cc: SystemVerilog CC DWG (sv-cc@eda.org); sv-bc@eda.org Subject: RE: [sv-cc] Re: [sv-bc] Mantis 3087 Uses of comment pragmas instead of attributes Syntax 22-8 comes a lot closer to what's in the proposal. Using Syntax 22-8, the complex values supported by the proposal could be represented as strings. So that would work out OK. From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Brad Pierce Sent: Tuesday, 2 Aug 2011 3:22 PM To: Rich, Dave Cc: SystemVerilog CC DWG (sv-cc@eda.org); sv-bc@eda.org Subject: [sv-cc] Re: [sv-bc] Mantis 3087 Uses of comment pragmas instead of attributes Can the impoverished attribute syntax of Syntax 5-3 really carry the weight? Why not use/extend the `pragma directive of Syntax 22-8? On Tue, Aug 2, 2011 at 8:02 AM, Rich, Dave <Dave_Rich@mentor.com<mailto:Dave_Rich@mentor.com>> wrote: Why does this proposal continue to promote the use comment pragmas instead of attributes? I thought the use of attributes is to be encouraged because you can't construct macros to deal with comments. Or are we giving up on attributes? Dave Rich Verification Technologist Mentor Graphics Corporation [cid:image001.png@01CC5674.629B6D10]<http://www.twitter.com/dave_59>[cid:image002.png@01CC5674.629B6D10]<http://go.mentor.com/drich> -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
