Also on 2217, I find "member select construct" awkward. I think "member select" is enough. Shalom > -----Original Message----- > From: owner-sv-bc@server.eda.org > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom > Sent: Monday, December 03, 2007 4:52 PM > To: sv-bc > Subject: FW: [sv-bc] e-mail ballot: respond by Dec 3, 8am PST > > 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. > --------------------------------------------------------------------- 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 07:01:56 2007
This archive was generated by hypermail 2.1.8 : Mon Dec 03 2007 - 07:02:05 PST