All, I noticed a couple of typographical errors in my proposal for Mantis 329. The two module output port declarations ended with semicolons, where the first one should have ended with a comma and the second end with neither a semicolon nor a comma. I have corrected the proposal. Regarding the syntax for adding package imports to module declarations, frankly, I don't care what syntax is used, as long as we pass this very simple user-driven enhancement request. I do think, however, that what we pass needs to be kept simple. I would hope that everyone who is discussing this proposal knows that a comma-separated list of package imports is already allowed. Thus, only one semicolon, not several, is needed. For the example in the proposal, I used two separate import statements just to show that multiple statements are allowed. It could have been modeled as: module M import A::instruction_t, B::*; #(WIDTH = 32) (input [WIDTH-1:0] data, input instruction_t a, output [WIDTH-1:0] result, output boolean_t OK ); Yes, the following code with a module that has no ports seems to have a semicolon in the middle of the module declaration... module M import B::*; (); But, if the module has no ports there is no need to have a package import statement before the port list, so this code is not likely to be a common modeling style. Secondly, even if a user did place the import statement before the empty port list, at least the syntax for the import statement is exactly the same as if it were placed after the port list. The current proposal has that advantage of no need for users to learn and remember yet another syntax that uses the import keyword. The syntax for importing from a package is the same whether before the port list or after the port list, or in $unit, or in another package. Introducing a special syntax for package imports that can only be used in one place is making the language more complex than it needs to be. Am I the only one who has ever (and often) made a coding error in port declarations due to the difference in using commas versus semicolons depending on where a port declaration appears? How many have inadvertently added a comma after the last port declaration in an ANSI style port list because in some places a comma is needed, but in this place it is not? These coding errors with port declarations would not exist if we, on the standards group, had just used the same syntax for port declarations both inside the ANSI style port lists and outside of the port list. Introducing a special package import syntax for one place is making the same mistake again, IMHO. Finally, if someone wants to propose a new package import syntax that can be used in all places a package can be imported, I would not object. That enhancement, however, does not prevent passing the current proposal for 329, unless the intent is to only allow module headers to use one style of package import and not other styles. Stu ~~~~~~~~~~~~~~~~~~~~~~~~~ Stuart Sutherland Sutherland HDL, Inc. stuart@sutherland-hdl.com 503-692-0898 > -----Original Message----- > From: owner-sv-bc@server.eda.org > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Heath Chambers > Sent: Wednesday, November 28, 2007 10:57 AM > To: 'Brad Pierce'; sv-bc@server.eda.org > Subject: RE: [sv-bc] e-mail ballot: respond by Dec 3, 8am PST > > Brad and Gord, > > The semi-colon issue for me is minor and I will change my > vote to yes if > there isn't enough pull to change to some other form. > > My preference of the solutions thought of so far: > 1. Gord's solution with a single import keyword and a comma > separated > list of package_import_item: > module M import p1::*, p2::* (); > > 2. Brad's parenthetical imports, but with this it might be > a good idea > to allow that style of import separated from the header as well > (i.e. separate from headers, allow either style of > import; but in > headers, allow only the parenthetical style): > module M import(p1::*, p2::*) (); > > 3. The current proposal with semi-colons. > > 4. Multiple import keywords and packages with whitespace > separation. > > > > Thanks, > -- Heath > > #################################### > | | > | HMC Design Verification, Inc. | > | | > | Heath Chambers | > | President/Verification Designer | > | 1203 San Juan Drive | > | Roswell, NM 88201 | > | | > | hmcdvi@msn.com | > | Phone: (575)627-2069 | > | Fax: (575)627-2069 | > | http://hmcdv.iwarp.com | > | | > #################################### > > > > > > -----Original Message----- > > From: owner-sv-bc@server.eda.org > > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce > > Sent: Wednesday, November 28, 2007 10:20 AM > > To: sv-bc@server.eda.org > > Subject: RE: [sv-bc] e-mail ballot: respond by Dec 3, 8am PST > > > > If no pound (#) sign > > > > module M import p1::*, p2::* (); > > > > then it would be clearer to write > > > > module M import(p1::*, p2::*) (); > > > > and within the import(), to allow p1 to be shorthand for p1::*. > > > > module M import(p1, p2) (); > > > > -- Brad > > > > -----Original Message----- > > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of > > Gordon Vreugdenhil > > Sent: Wednesday, November 28, 2007 9:13 AM > > To: Heath Chambers > > Cc: 'Maidment, Matthew R'; sv-bc@eda.org > > Subject: Re: [sv-bc] e-mail ballot: respond by Dec 3, 8am PST > > > > > > > > Heath Chambers wrote: > > > > >SVDB 329 ___Yes _X_No > > > > >http://www.eda.org/svdb/view.php?id=329 > > > > > > Same as Gord's reason AND > > > I don't like the semicolons in the middle of a > > > module/interface/program declaration. > > > My second issue is a weak objection as I feel the feature > > needs to be > > > added, so I will change my vote to yes if the BNF fixed and there > > > isn't enough consensus to change to either comma or no separator > > > (other than requiring a parameter and/or port list after > > the imports). > > > > > > Heath, the issue of the ";" separator in the middle came up > > here in some > > local discussions too. > > > > Since the package_import_declaration allows a comma > separated list of > > package items: > > package_import_item { , package_import_item } if we > > want to go to > > a single import form we could restructure the grammar a bit: > > > > import_and_items ::= > > import package_import_item { , package_import_item } > > > > package_import_declaration ::= import_and_items ; > > > > header_import_declaration ::= import_and_items > > > > We could then allow just a single > "header_import_declaration" rather > > than a list and restructure the example to just use the > single import. > > I would be Ok with that change. I wouldn't like to end up > > with multiple > > "import" keywords in a comma separated list. > > > > So I am Ok with: > > module M import p1::*, p2::* (); > > but don't really like: > > module M import p1::* import p2::* (); > > > > > > If there is a stronger consensus on the above suggestion, > I'd be fine > > with that. > > > > Gord. > > -- > > > -------------------------------------------------------------------- > > Gordon Vreugdenhil 503-685-0808 > > Model Technology (Mentor Graphics) gordonv@model.com > > > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, 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.Received on Wed Nov 28 19:36:57 2007
This archive was generated by hypermail 2.1.8 : Wed Nov 28 2007 - 19:37:32 PST