Sorry, you are correct. I remembered the partially typed rules as worse than this, and was wrong. Apparently the only partial case is when you specify "signed" and no range, in which case it gets the range from the size of the value. This is in addition to the completely implicit case, in which both the signedness and range are gotten from the value. I thought that there was the opposite partial case in which you got the signedness from the value but the range from the parameter declaration. I am glad that I was wrong, and thanks for the correction. At the time that these rules were originally added, "type" only meant "signed", or in some places "real" (though not all the text accounts for that possibility). There were no other possibilities in Verilog at the time. Unfortunately, when other types were added in SystemVerilog, this text was not modified sufficiently to take them into account. If you try to read these rules assuming that "type" refers to all the data types in SystemVerilog, you could get nonsense interpretations. For example, consider the declaration "parameter int p = 4'b1". Technically, this is a value parameter with a type specification, but with no range specification (though int has an implicit range, there is no explicit range in the declaration). The LRM says that the parameter shall be of the type specified (int). But then it says that a signed parameter shall default to the range of the final override value assigned to the parameter. An int parameter is signed, so this rule would seem to apply. That indicates that the range should be [3:0], which contradicts the statement that the parameter is an int (which has an implicit range of [31:0]). To resolve this apparent contradiction, you have to recognize that the rule about a signed parameter is only talking about the case where the type is "signed" and there is no range. From: Daniel Mlynek [mailto:danielm@aldec.com.pl] Sent: Saturday, March 22, 2014 5:29 AM To: Steven Sharp Cc: Datta, Kausik; Vreugdenhil, Gordon; Bresticker, Shalom; sv-bc@eda.org Subject: Re: [sv-bc] RE: Value propagation in Parameter with Type Steve> "In your scenario, p2 is one of these parameters with a partially specified type. It will get its width from the declaration (8 bits) but its signedness from the value assigned (which is signed). So it will be 8 bits signed" but LRM says A value parameter with a range specification, but with no type specification, shall have the range of the parameter declaration and shall be unsigned. An override value shall be converted to the type and range of the parameter. So imho p2 would be unsigned. Rules for this partally typed parameters can drive man mad. I suppose that type means here bit vs logic. DANiel W dniu 3/19/2014 11:06 PM, Steven Sharp pisze: The statement about conversion is a shortened and inexact description of what actually happens, which follows the full rules for assignments that have been quoted. I suspect the reason for including this abbreviated mention here is to clarify that the behavior when the parameter has an explicit type is different from when it doesn't. But if you want the fully spelled out rules, you will have to look at the assignment rules. When the parameter is not declared with an explicit type, then the assignment rules cannot be applied, since the LHS doesn't have a type or range. In that case the RHS is evaluated as self-determined and the parameter gets the resulting type and range (which can only be a vector or real). And then there are the cases where the type is "partially" specified, i.e. there is only a signedness or a range, but not both. I never approved of the rules for that. They use the part that was explicitly specified, and take the other part from the value. Note that a type parameter or typedef will always provide a full type, and will never fall into this "partial" category, no matter how the type parameter or typedef was declared. In your scenario, p2 is one of these parameters with a partially specified type. It will get its width from the declaration (8 bits) but its signedness from the value assigned (which is signed). So it will be 8 bits signed. On the other hand, p3 is type UTR. This happens to be unsigned when treated as a vector. The signedness of p2 or p3 won't affect the bit pattern that is used for their value, however. The evaluation of the RHS of an assignment is unaffected by the signedness of the LHS. However, that value will be treated as signed when p2 is used in an expression, and unsigned when p3 is used in an expression. The "conversion" of the signed value to unsigned for p3 has no effect on the bit pattern, only on its interpretation when p3 is used in a context where signedness matters. From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Datta, Kausik Sent: Wednesday, March 19, 2014 3:02 PM To: Vreugdenhil, Gordon; Bresticker, Shalom; sv-bc@eda.org<mailto:sv-bc@eda.org> Subject: RE: [sv-bc] RE: Value propagation in Parameter with Type Gord, Thank you for referring the LRM section. Actually I am confused about the point of "An override value shall be converted to the type and range of the parameter" in section 23.10 Does this mean the overridden value will first take the size based on it's own signed/unsigned type and then will be converted to the parameter's type? Another question I have is why section 10.8 refers only explicitly typed parameter? For the following scenario does p2 and p3 will be treated differently? module bot #(parameter type p1 = logic, parameter [7:0] p2 = 7, parameter p1 p3 = 7) (input in1, output integer out1, output integer out2); bot #(UTR, 2'sb11, 2'sb11) inst(in1, out1, out2); Thanks Kausik From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Wednesday, March 19, 2014 11:47 PM To: Datta, Kausik; Bresticker, Shalom; sv-bc@eda.org<mailto:sv-bc@eda.org> Subject: Re: [sv-bc] RE: Value propagation in Parameter with Type Please see 1800-2012 10.8 Assignment-like contexts. Explicitly typed parameters are assignment like contexts and follow the rules that Shalom noted. In the example you had, p2 is explicitly typed. If you have a different example in mind in your follow-up, please note that. Gord On 3/19/2014 11:07 AM, Datta, Kausik wrote: Shalom, Does parameter override happens following assignment evaluation rule? As section 23.10 says if a parameter has range specification then it should be unsigned and an override value shall be converted to the type and range of parameter. For any typed parameter I think size is implicitly defined. Thanks Kausik 23.10 Overriding module parameters A value parameter (see 6.20.2) can have a type specification and a range specification. The effect of parameter overrides on a value parameter's type and range shall be in accordance with the following rules: - A value parameter declaration with no type or range specification shall default to the type and range of the final override value assigned to the parameter. - A value parameter with a range specification, but with no type specification, shall have the range of the parameter declaration and shall be unsigned. An override value shall be converted to the type and range of the parameter. - A value parameter with a type specification, but with no range specification, shall be of the type specified. An override value shall be converted to the type of the parameter. A signed parameter shall default to the range of the final override value assigned to the parameter. - A value parameter with a signed type specification and with a range specification shall be signed and shall have the range of its declaration. An override value shall be converted to the type and range of the parameter. From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: Wednesday, March 19, 2014 8:23 PM To: Datta, Kausik; sv-bc@eda.org<mailto:sv-bc@eda.org> Subject: RE: Value propagation in Parameter with Type 11.8.3 says, 11.8.3 Steps for evaluating an assignment The following are the steps for evaluating an assignment: - Determine the size of the right-hand side by the standard assignment size determination rules (see 11.6). - If needed, extend the size of the right-hand side, performing sign extension if, and only if, the type of the right-hand side is signed. So you get parameter UTR p2 = 2'sb11 ; In this case, the RHS is signed. According to 11.8.3, when size-extending the RHS, it does not matter whether or not the LHS is signed or unsigned. If the RHS is signed, as in this case, sign-extension is performed. So you should get 8'b11111111. Regards, Shalom From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Datta, Kausik Sent: Wednesday, March 19, 2014 16:46 To: sv-bc@eda.org<mailto:sv-bc@eda.org> Subject: [sv-bc] Value propagation in Parameter with Type Hi, For the following testcase what should be the value of p2? Will it be 8'b00000011 or 8'b11111111? Thanks Kausik module bot #(parameter type p1 = logic, parameter p1 p2 = 7) (input in1, output integer out1); assign out1 = p2; endmodule module top(input in1, output integer out1); typedef union packed { byte a; bit [7:0] b; }UTR; bot #(UTR, 2'sb11) inst(in1, out1); endmodule -- 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<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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Mar 24 11:41:28 2014
This archive was generated by hypermail 2.1.8 : Mon Mar 24 2014 - 11:41:42 PDT