I can add another possible misunderstanding: assign w[3:0] = { scalar1, '0, scalar2 } ; The user might think that '0 size-extends to the size needed to make the concatenation the same size as the LHS, which is not correct. But my original question was: according to the LRM today, is the code legal or not? If it is legal, its interpretation is unambiguous. I'd like to know if there is a consensus on the answer to that question, because the LRM is not clear, in my opinion. Thanks, Shalom From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Steven Sharp Sent: Tuesday, October 08, 2013 02:37 To: Brad Pierce; SV_BC List Subject: [sv-bc] RE: uniszed unbased literal in a concatenation The error for unsized literals in concatenations is intended to protect users from mistakes. Whether the error should apply to these newer unsized unbased literals should depend on whether there is a similar need to protect users. I see two different possible mistakes that could occur with unsized literals in concatenations. The first was that in Verilog, the size of those unsized literals could be different on different machines. They could be whatever size was convenient for integers on the machine (later required to be at least 32 bits by the IEEE standard). In most cases, as long as the value was small enough to fit into the size used on any machine, the exact size wouldn't matter. But when used in a concatenation, the size would affect the resulting position of any operand to its left. This would make the code very non-portable. In SV, the size is now effectively fixed at 32 bits (because integers are now fixed at 32 bits and the LRM indicates that unsized literals are the same size as integers, though you can try to make convoluted arguments that it doesn't actually say that). So that problem doesn't actually occur any more. And that problem doesn't come up for the unsized unbased literals, because they are always 1 bit and will occupy 1 bit in the concatenation result, regardless of the machine. The other possible mistake is the user wrongly believing that something like 'b0 will occupy 1 bit in the concatenation, when in fact it will occupy 32 bits (or possibly more in the older Verilog standard). This isn't a problem with the unsized unbased literals, because they do occupy 1 bit in the concatenation. However, there are still some possible misunderstandings the user could have, as Brad mentions. They may think its special properties in filling out the width will apply even as an operand in a concatenation. If used as the leftmost operand, a '0 will work fine because of the normal zero-extension of the value. But a '1, 'x or 'z won't get extended. And they might think that it will also suppress warnings about width mismatches, which it shouldn't in this situation (which might alert them that it isn't doing the extension they expect). So the question is whether this misunderstanding is dangerous enough to justify making this an error. Note that if they understand what they are doing, changing it to the equivalent 1'b0 is only 2 characters extra. From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Brad Pierce Sent: Monday, October 07, 2013 1:59 PM To: SV_BC List Subject: [sv-bc] RE: uniszed unbased literal in a concatenation Hi Shalom, I think it's legal, and 1-bit wide, but the designer probably thinks it means to fill out with 0's to the width of the LHS, that is, the same as assign w = w1; except suppressing any warnings about the widths not matching. -- Brad From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom Sent: Monday, October 07, 2013 8:42 AM To: SV_BC List Subject: [sv-bc] uniszed unbased literal in a concatenation Hi, Consider this code: module test1; wire [2:0] w1; wire [3:0] w ; assign w = {'0, w1}; endmodule Is this concatenation legal because '0 is 1 bit wide in a self-determined context, or is it illegal because it is an unsized constant in a concatenation? I tend toward the first interpretation, but I see that some tools accept it and some do not. Thanks, Shalom Shalom Bresticker Intel, Networking Division DA, Jerusalem, Israel +972 2 589 6582 (office) +972 54 721 1033 (cell) http://www.linkedin.com/in/shalombresticker --------------------------------------------------------------------- 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<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. --------------------------------------------------------------------- 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 Tue Oct 8 05:12:40 2013
This archive was generated by hypermail 2.1.8 : Tue Oct 08 2013 - 05:12:59 PDT