I vote No on 1619, 2102, 2106, 2217. Yes with friendly amendments on 1339, 1571, 2184. Comment on 329. Yes on the others. Shalom SVDB 329 _x_Yes ___No http://www.eda.org/svdb/view.php?id=329 Version V5, 2007-11-30 The wording in 25.4, "Package items can be referenced in module, interface or program parameter and port declarations by importing the package as part of the header to the module, interface or program declaration," is a trifle imprecise in that the header can contain an import not just of an entire package, but also of specific package items, but not enough for me to vote No. SVDB 1338 _x_Yes ___No http://www.eda.org/svdb/view.php?id=1338 Version V6, 2007-11-30 SVDB 1339 _x_Yes ___No http://www.eda.org/svdb/view.php?id=1339 Version V4, 2007-11-29 Friendly amendment: Change last sentence to, "Any white space characters at the beginning or end of the macro text shall be removed." (No hyphen in 'white space'.) SVDB 1548 _x_Yes ___No http://www.eda.org/svdb/view.php?id=1548 SVDB 1571 _x_Yes ___No http://www.eda.org/svdb/view.php?id=1571 Version V6, 2007-12-02 Friendly amendment: CHANGE "When a macro usage is passed as an actual argument to another macro, the argument expansion shall not introduce new uses of the formal arguments to the top-level macro." TO "When a macro usage is passed as an actual argument to another macro, the argument expansion does not introduce new uses of the formal arguments to the top-level macro." SVDB 1619 ___Yes _x_No http://www.eda.org/svdb/view.php?id=1619 Version V5, 2007-11-30 The changes below which are noted with a * are required to change my vote to Yes. The others are friendly amendments. 1A. In the introduction, change "This is an initial proposal" to "This is a proposal". B. Change "a similar wording for module ports could go something like:" to "a similar wording for module ports is the following:". *2A. In 22.2.2.4, in the sentence, "These default values shall be constant expressions evaluated in the scope of the module where it is defined not in the scope of the instantiating module," add a comma between "defined" and "not", change "it is" to "they are". B. In the lines "The informal syntax to declare a default input port value in a module is as follows: module module_name ( ..., [ input ] [ type ] port_identifier = constant_expression, ... );" change 'module' and 'input' to Bold Courier. C. Change "If an input port is left unconnected" to "If a connection is not specified for an input port". *D. Change "name connections" to "named connections". *E. Change "default ports semantics and parameter scoping resolution" to "default port semantics and parameter scope resolution". *F. In the example, all the keywords and only the keywords should be Bold. *G. Change the module bus_conn from module bus_conn ( output logic [7:0] dataout, input [7:0] datain = My_DataIn, dataout = datain; endmodule TO module bus_conn ( output logic [7:0] dataout, input [7:0] datain = My_DataIn ); assign dataout = datain; endmodule *H. Change module bus_connect1 ( output logic [31:0] dataout, input [7:0] datain TO module bus_connect1 ( output logic [31:0] dataout, input [7:0] datain ); 3A. In 22.3.2.1, start the sentence, "If a port connection is omitted (indicated by a missing argument in the comma separated list) to an input port with a default value, the default value shall be used," with "However, ". *B. In the example, with the line, "accum accum (dataout[7:0], , clk, rst_n); // datain gets default value 8'hFF," by connecting datain to a fixed default value, the example no longer makes sense. *4A. In 22.3.2.2, in "If an input port with a specified default value has an explicit empty named port connection (i.e., .port_identifier())," change "port_identifier" to "port_name" to be consistent with the rest of the subclause. *B. In the example lines, "accum accum (.dataout(dataout[7:0]),, .clk(clk), .rst_n(rst_n)); // datain is not in the port list, gets default value 8'hFF xtend xtend (.dout(dataout[15:8]), .din(alu_out[7]), .clk(clk), .rst()); // rst has a default value, but has an empty port connection, therefore left unconnected has a default value, but has an empty port connection, therefore left unconnected," same comment as 3B above. Also, the deletion of rst_n connecting expression must be explicit, in red strikeout. 5A. In 22.3.2.3, Change "implicit wire declaration" to "implicit net declaration". *B. In "To leave a port with a default value unconnected, open brackets must be used after .name, i.e. name().", change "open brackets" to "empty parentheses". *C. In the line, " alu alu (.alu_out, .zero(), .ain, .bin, .opcode);" the parentheses after .zero are in red strikeout. I don't think that is correct. *D. In "The clk is connected using implicit .name port connections while the rst_n port is left unconnected because it uses empty brackets even though it has a default value," 'implicit .name port connections' should be 'an implicit .name connection'. 'empty brackets' should be 'empty parentheses'. E. Port names in the text should be in Courier font. *F. Change "The clk is connected using implicit .name port connection, but the rst signal does not exist in the instantiation module and hence shall generate an error even though a default port value exists." TO "The clk port is connected using an implicit .name port connection, but the rst signal does not exist in the instantiating module and hence will generate an error even though a default port value exists." (Among the other changes in the sentence, 'will' is more appropriate than 'shall' in this particular place.) *6A. In 23.3.2.4, remove all the red strikeout text at the beginning. It is not text from the LRM, but rather from previous versions of the proposal and should not appear here at all. It is confusing. *B. In, "An implicit .* port connection is semantically equivalent to a default .name port connection for every port declared in the instantiated module with two exceptions," change "default" to "implicit", as in the Draft 4 LRM. *C. In "2. Using .* does not create a sufficient reference for a wildcard import of a name from a package. A named port connection can be mixed with a .* connection to override a port connection to a different expression or to leave a port unconnected. A named or implicit .name connection can be mixed with a .* connection to create a sufficient reference for a wildcard import of a name from a package," the second sentence, "A named port connection can be mixed with a .* connection to override a port connection to a different expression or to leave a port unconnected," is not relevant to the paragraph. Move it instead to the first paragraph of the subclause, after the sentence, "This implicit port connection style is used to indicate that all port names and types match the connections where emphasis is placed only on the exception ports." *7A. In the syntax changes, the = token (for Brad) and the word 'input' should be in bold red. SVDB 1957 _x_Yes ___No http://www.eda.org/svdb/view.php?id=1957 SVDB 2102 ___Yes _x_No http://www.eda.org/svdb/view.php?id=2102 Version V2, 2007-11-30 I am still unhappy with this. I still think it could be interpreted to say that if there is an unpacked aggregate whose elements are themselves packed aggregates (such as an array whose elements are n-bit packed vectors), then only different words can be written in different ways (one procedurally, one continuously), but not different bits in the same word. I understood from the discussion that this is not so. In particular, the text still contains this example: struct { bit [7:0] A; bit [7:0] B; byte C; } abc; not (abc.A[0],abc.B[0]), (abc.A[1],abc.B[1]), (abc.A[2],abc.B[2]), (abc.A[3],abc.B[3]); The following additional statements are illegal assignments to struct abc: // Mixing continuous and procedural assignments to abc.A always @(posedge clk) abc.A[7:4] <= !abc.B[7:4]; I don't think the paragraph should be deleted. Instead, I think the two paragraphs should be combined, but in a paragraph devoted only to this subject. So if we look at the first paragraph, "Variables can be written by one or more procedural statements, including procedural continuous assignments. The last write determines the value. Variables can be written by one continuous assignment or one port. It shall be an error to have multiple continuous assignments or a mixture of procedural and continuous assignments writing to any term in the expansion of a written longest static prefix of a variable (see 11.5.3 for the definition of the expansion of a longest static prefix). The force statement overrides the procedural assign statement, which in turn overrides the normal assignments," then the first two sentences should be separated into a separate paragraph. The last sentence should be moved to the paragraph following the example, which mentions force. Then the remaining two sentences should be combined with the second paragraph. SVDB 2106 ___Yes _x_No http://www.eda.org/svdb/view.php?id=2106 The sentence, "It shall be an error if the type_identifier does not resolve to data type, or basic data type if specified, " is unclear to me. And what is the difference between "data type" and "basic data type"? The paragraph, "A variable declaration shall precede any statements within a procedural block. A variable declaration shall precede any simple reference (non-hierarchal) to that variable," seems stuck in the middle of a bunch of paragraphs describing scope and lifetime in various cases. The paragraph, "Variables declared in an automatic task, function, or block may have the lifetime of the call or activation and a local scope. This is roughly equivalent to a C automatic variable," should go together with the sentence, "Tasks and functions may be declared as automatic, making all variables within the task or function automatic." And they both should go together with the last paragraph saying, "Variables declared to be static in an automatic task, function, or block have a static lifetime and a scope local to the block." Also, the "may" in "Variables declared in an automatic task, function, or block may have the lifetime of the call or activation and a local scope, " makes the sentence effectively meaningless. The parallel statement for static blocks is, "Variables declared in a static task, function, or block default to a static lifetime and a local scope," which is better wording. The first reference to type parameters should have an xref to 6.20.3. "This is roughly equivalent to C static variables declared outside a function, which is local to a file." - I think should be "are local". SVDB 2152 _x_Yes ___No http://www.eda.org/svdb/view.php?id=2152 SVDB 2163 _x_Yes ___No http://www.eda.org/svdb/view.php?id=2163 SVDB 2169 _x_Yes ___No http://www.eda.org/svdb/view.php?id=2169 Version V2, 2007-12-03 SVDB 2170 _x_Yes ___No http://www.eda.org/svdb/view.php?id=2170 SVDB 2178 _x_Yes ___No http://www.eda.org/svdb/view.php?id=2178 SVDB 2184 _x_Yes ___No http://www.eda.org/svdb/view.php?id=2184 Version V2, 2007-12-02 Friendly amendment: Change "The system functions allowed in constant expressions when their arguments are constant expression" to "The system functions allowed in constant expressions when their arguments are constant expressions" SVDB 2217 ___Yes _x_No http://www.eda.org/svdb/view.php?id=2217 The placement of this text is not clear to me. The introductory note says, "the following text refers to "22.7.2". That reference should be correct assuming that Mantis 1809 is applied first since 1809 adds 22.7.1." But the text does not have any reference to 22.7.2. Also, the text is this proposal places it in 22.6. I don't think that is the place for it. 22.6 deals with only simple downward hierarchical names and full hierarchical names. This text belongs in either 22.7 or 22.8. Also, regarding "dotted name 1: The first name component is s1. Since s1 is a directly visible scope name, rule 2 applies and the name s1.x is considered to be a hierarchical name," it is not clear to me whether and why s1 is directly visible. It would probably be not clear to other users as well. Shalom --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Dec 3 06:55:06 2007
This archive was generated by hypermail 2.1.8 : Mon Dec 03 2007 - 06:55:56 PST