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] *On Behalf Of > *Datta, Kausik > *Sent:* Wednesday, March 19, 2014 3:02 PM > *To:* Vreugdenhil, Gordon; Bresticker, Shalom; 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 > *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 Sat Mar 22 02:30:18 2014
This archive was generated by hypermail 2.1.8 : Sat Mar 22 2014 - 02:31:16 PDT