| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 489
|
| Category | errata
|
| Synopsis | parameters with signed but no range (3.11.1 and 12.2)
|
| State | open
|
| Class | errata-simple
|
| Arrival-Date | Oct 03 2003
|
| Originator | sharp@cadence.com
|
| Release | 2001b
|
| Environment |
|
| Description |
The two listed sections contain slightly different but apparently compatible rules for parameters with and without types in their declarations. One of the rules involves parameters with "a type specification, but no range specification". Here "type" apparently refers to "signed" (though this is confusing, since a parameter can also be declared as integer, real, realtime or time, which is a type but certainly doesn't need a range and shouldn't get one from elsewhere). The rules specify that in this case the parameter shall be of the type specified (i.e. a signed vector) but will get the range of the final value assigned. There are some problems with this "hybrid" declaration. In one place, it goes on to say effectively that if the final value is unsized, it gets an implementation-defined width of at least 32. This is badly specified, since it allows the implementation-defined width for such a parameter to be different from the implementation-defined width of an unsized constant. This is silly. It would have been better to leave this statement out, since an unsized constant already has an implementation-defined width of at least 32. This is just a special case of the parameter getting the width of the value assigned, which should be the width of an unsized constant, which is already defined. There is a worse problem. What happens if the value assigned is a real constant? The parameter is supposed to be the type specified, which is not real. So the parameter should not be real. However, since a real value is not a vector, it does not provide a width for the signed vector parameter. Frankly, I think that this "hybrid" of getting part of the type from the declaration and part of it from the value should have been left out. It is potentially confusing to users. I don't see any situation where it is particularly useful. It adds an extra rule to the already messy description of typed and untyped parameters. It is not consistent with the behavior of other declarations that include "signed" but no range (which apparently is considered a completely specified, if rather useless, type: a signed scalar). And it doesn't work if the value assigned turns out to be real. Possible solutions are to remove this special case, or clean up the descriptions and specify what happens if the value assigned is real. |
| Fix |
|
| Audit-Trail |
From: Shalom.Bresticker@motorola.com To: sharp@cadence.com Cc: etf-bugs@boyd.com Subject: Re: errata/489: parameters with signed but no range (3.11.1 and 12.2) Date: Sun, 5 Oct 2003 06:51:22 +0200 (IST) Steven, I interpret the text differently. The text in 3.11.1 is, "A parameter with a type specification, but with no range specification, shall be of the type specified. A signed parameter shall default to the range of the final value assigned to the parameter, after any value overrides have been applied." I agree that it is badly worded, but I think the intent was as follows: "type specification", as used in this context, means one of: signed integer real realtime time If one of these was specified, then "the parameter shall be of the type specified," and the value shall be converted to that type. (If the type is integer, real, realtime, or time, then it will always be true that there is "no range specification".) If we do not say that, then I think we do not have any rule that says that for integer, etc. types, the param value is converted to the specified type. What does it mean for "signed"? Since Steven does not like to say that we have a "reg" data type, let us say that it means that the type is a (non-real) vector, interpreted as signed. The second sentence in that paragraph comes to deal with that special case of the first sentence, and say that in case the specified type is 'signed' and with no range, then the range comes from the value. Then the next rule in 3.11.1 deals with case of 'signed' WITH a range. Then the following two rules also cover the case of signed with no range, and specify how we calculate the final range. There is some duplication, and it also does not specify what to do if the value specified is real. Does that reading make more sense? Shalom On Fri, 3 Oct 2003 sharp@cadence.com wrote: > The two listed sections contain slightly different but > apparently compatible rules for parameters with and without > types in their declarations. One of the rules involves > parameters with "a type specification, but no range > specification". Here "type" apparently refers to "signed" > (though this is confusing, since a parameter can also be > declared as integer, real, realtime or time, which is a > type but certainly doesn't need a range and shouldn't get > one from elsewhere). > > The rules specify that in this case the parameter shall be > of the type specified (i.e. a signed vector) but will get > the range of the final value assigned. There are some > problems with this "hybrid" declaration. > > In one place, it goes on to say effectively that if the > final value is unsized, it gets an implementation-defined > width of at least 32. This is badly specified, since it > allows the implementation-defined width for such a parameter > to be different from the implementation-defined width of an > unsized constant. This is silly. It would have been > better to leave this statement out, since an unsized > constant already has an implementation-defined width of > at least 32. This is just a special case of the parameter > getting the width of the value assigned, which should be > the width of an unsized constant, which is already defined. > > There is a worse problem. What happens if the value > assigned is a real constant? The parameter is supposed > to be the type specified, which is not real. So the > parameter should not be real. However, since a real > value is not a vector, it does not provide a width for > the signed vector parameter. > > Frankly, I think that this "hybrid" of getting part of > the type from the declaration and part of it from the > value should have been left out. It is potentially > confusing to users. I don't see any situation where it > is particularly useful. It adds an extra rule to the > already messy description of typed and untyped parameters. > It is not consistent with the behavior of other declarations > that include "signed" but no range (which apparently is > considered a completely specified, if rather useless, type: > a signed scalar). And it doesn't work if the value > assigned turns out to be real. > > Possible solutions are to remove this special case, or > clean up the descriptions and specify what happens if the > value assigned is real. > -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Shalom.Bresticker@freescale.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/489: parameters with signed but no range (3.11.1 and 12.2) Date: Sun, 12 Dec 2004 10:06:20 +0200 (IST) See 483 for additional relevant information. |
| Unformatted |
|
Hosted by Boyd Technology