Subject: Re: [sv-bc] Response to questions on Packages and Separate Compilation proposal
From: David W. Smith (David.Smith@synopsys.com)
Date: Fri Nov 07 2003 - 17:52:01 PST
MessageHi Doug,
Please see my comments below. It seems to me that this a misunderstanding of what a compilation-unit scope is (it is not a package) and how $unit is used. It does not replace packages, it can use import of packages to the scope, it is private to the compilation unit. Let's talk on Monday at the meeting.
Regards
David
----- Original Message -----
From: Warmke, Doug
To: 'David W. Smith' ; sv-bc@eda.org
Sent: Friday, November 07, 2003 5:15 PM
Subject: RE: [sv-bc] Response to questions on Packages and Separate Compilation proposal
David, Stu,
A lengthy but very interesting read.
Thanks for forwarding all this information to us.
I would like to second (or third?) Stu and Francoise's
desire to eliminate the concept of $unit. There are several
problems posed by that concept.
One problem is that code cannot make named references to different $unit's.
This is inconsistent with all other packages.
DWS: This is why $unit is using the scope resolution operator to access the compilation-unit scope and not a package).
What if procedural code in one unit wants to make use of types in a
a different $unit? There is no direct way (arguably that may be a
designer's intention). But perhaps syntax like this (or something
similar) could be used as a backdoor:
DWS: This is by design. The compilation-unit scope is private to a compilation unit and cannot be accessed by another compilation unit. If you want to share like you suggest then use a package (which is globally known).
// This block defined in a separate compilation unit than $root.a.b
initial begin
myreg = $root.a.b.$unit::funcName(1, 2, 3);
end
Another problem might occur when DPI import functions would like to
make a call to exported tasks or functions defined in different $unit's.
There is no direct way to achieve that. All import function declarations
must be compiled in the compilation unit which they will reference.
Perhaps similar backdoors could be found.
DWS: If the compilation-unit scope is private to a compilation unit the having the DPI functions access them seems very strange. If you want public access outside of the compilation unit then use a package.
These are not major issues, but they are bothersome.
The inconsistency of $unit with all other package particularly grates.
And not having $unit is not a very bothersome restriction.
In theory, users would only have to add three extra lines of code:
DWS: The compilation-unit scope Is not a package therefore I do not find it bothersome. It is a scope private to the compilation unit. Something that a package is not. It has different search rules than a package. $unit is just one mechanism to access the items in the compilation-unit scope (the other is using upwards resolution).
WITH $unit:
wire net1;
wire net2;
wire net3;
wire net4;
module m;
assign net1 = 1'b0;
assign net2 = 1'b1;
assign net3 = 1'b0;
assign net4 = 1'b1;
endmodule
USING a package instead of $unit:
package mywires;
wire net1;
wire net2;
wire net3;
wire net4;
endpackage
module m;
import mywires::*;
assign net1 = 1'b0;
assign net2 = 1'b1;
assign net3 = 1'b0;
assign net4 = 1'b1;
endmodule
Another syntactic nicety that may be enabled if $unit was removed is that
we could allow the import statement to precede module declarations, rather
than using them as module_declarative_items. This would allow graceful
use of types in a package in module port and parameter declarations.
Currently the only way to use package-defined types in ports and parameters
is to make fully qualified references to the types, using packagename::typename
syntax. That isn't consistent with use of package-defined types elsewhere
in a module's scope.
DWS: You can allow import statements to preced module declarations. The compilation-unit scope does allow the import of packages. This does allow the graceful use of types from a package in module port and parameter declarations. Your comment on only being able to use packagename::typename is not true with this proposal. I believe there is a misunderstanding somewhere that we need to resolve at the meeting on Monday.
Thanks and Regards,
Doug
-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of David W. Smith
Sent: Thursday, November 06, 2003 4:35 PM
To: sv-bc@eda.org
Subject: [sv-bc] Response to questions on Packages and Separate Compilation proposal
Greetings,
Stu sent a list of questions and issues on V8 of the Packages and Separate Compilation proposal.
His questions with responses can be found at: http://www.eda.org/sv-bc/sep_comp/Packages_Sep_V10.pdf
A new version of the proposal that incorporates changes due to his questions can be found at: http://www.eda.org/sv-bc/sep_comp/Stu_Response.pdf
The semantics of this proposal should be consistent with V5 and V8. The changes should only be clarification and editorial changes.
David W. Smith
Synopsys Scientist
Synopsys, Inc.
Synopsys Technology Park
2025 NW Cornelius Pass Road
Hillsboro, OR 97124
Voice: 503.547.6467
Main: 503.547.6000
FAX: 503.547.6906
Email: david.smith@synopsys.com
http://www.synopsys.com
This archive was generated by hypermail 2b28 : Fri Nov 07 2003 - 18:56:39 PST