| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 608
|
| Notify-List |
|
| Category | errata
|
| Synopsis | mintypmax_expression usage
|
| State | open
|
| Class | errata-simple
|
| Arrival-Date | Jul 29 2004
|
| Originator | Eric Mahurin
|
| Release |
|
| Environment |
|
| Description |
Section 4.3 says this: "Values expressed in min:typ:max format can be used in expressions. The min:typ:max format can be used wherever expressions can appear." I think the intent is that these ONLY be used with expressions that are used for generating delays or times. I don't see where it says that. Secondly, the BNF is inconsistent in its use of mintypmax_expression and expression. As it is now, even an epression can have a mintypmax_expression in it with parenthesis. Personally, I think mintypmax_expression should unified expression and then in the text just describe when an expression or portion of it should allow the mintypmax ":" operators. But, if you don't do this, at least make all of the places that can have delay/time values use mintypmax_expression instead. Here are the ones I found: A.2.2.1: variable_type A.4.1: ordered_parameter_assignment (named parameters allow mintypmax, but ordered doesn't) A.6.5: wait statement A.7.5.2: timing_check_limit (found the issue here originally while parsing some example code with a $period statement and colons used direction in these timing_check_limit arguments) Again, I think expression and mintypmax_expression should be merged (along with constant_expression and module_path_expression) instead. |
| Fix |
Unknown |
| Audit-Trail |
From: Shalom.Bresticker@freescale.com To: eric_mahurin@yahoo.com Cc: etf-bugs@boyd.com Subject: Re: errata/608: mintypmax_expression usage Date: Fri, 30 Jul 2004 12:34:17 +0300 (IDT) Eric, > Section 4.3 says this: "Values expressed in min:typ:max format can be used in expressions. The min:typ:max format can be used > wherever expressions can appear." > > I think the intent is that these ONLY be used with expressions that are used for generating delays or times. I don't see where it says that. No, mintypmax expressions really can be used anywhere. > Secondly, the BNF is inconsistent in its use of mintypmax_expression and expression. As it is now, even an epression can have a mintypmax_expression in it with parenthesis. > > Personally, I think mintypmax_expression should unified expression and then in the text just describe when an expression or portion of it should allow the mintypmax ":" operators. mintypmax expressions are discussed somewhat in issues 174 and 226. We know that the BNF is not completely consistent with where implementations actually require the parentheses and where they don't. We found it to be difficult to research the subject thoroughly and to make the BNF conform to that. If we take the approach that the BNF in the next revision can be more lenient as long as it does not forbid anything which currently works, then it might be easier. > But, if you don't do this, at least make all of the places that can have delay/time values use mintypmax_expression instead. Here are the ones I found: > > A.2.2.1: variable_type > > A.4.1: ordered_parameter_assignment (named parameters allow mintypmax, but ordered doesn't) > > A.6.5: wait statement > > A.7.5.2: timing_check_limit (found the issue here originally while parsing some example code with a $period statement and colons used direction in these timing_check_limit arguments) I haven't looked at these. > Again, I think expression and mintypmax_expression should be merged (along with constant_expression and module_path_expression) instead. I looked at merging constant_expression and module_path_expression with expression, as you suggested. I found then different enough at the basic element, the primary, that I was reluctant to do that merger. The idea of mintypmax_expression as I remember was to require parentheses everywhere except where specifically allowed without parentheses. Bring on the additional issues. Shalom -- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Reuse Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 From: Eric Mahurin <eric_mahurin@yahoo.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/608: mintypmax_expression usage Date: Fri, 30 Jul 2004 09:47:19 -0700 (PDT) --- Shalom.Bresticker@freescale.com wrote: > Eric, > > > Section 4.3 says this: "Values expressed in > min:typ:max format can be used in expressions. The > min:typ:max format can be used > > wherever expressions can appear." > > > > I think the intent is that these ONLY be used with > expressions that are used for generating delays or > times. I don't see where it says that. > > No, mintypmax expressions really can be used > anywhere. Interesting. I've never seen examples of it anywhere else than under the context of delays. Do the simulators actually allow it anywhere? I don't have verilog-xl at my disposal (only gpl-cver). > > Secondly, the BNF is inconsistent in its use of > mintypmax_expression and expression. As it is now, > even an epression can have a mintypmax_expression in > it with parenthesis. > > > > Personally, I think mintypmax_expression should > unified expression and then in the text just > describe when an expression or portion of it should > allow the mintypmax ":" operators. > > mintypmax expressions are discussed somewhat in > issues 174 and 226. > > We know that the BNF is not completely consistent > with where implementations > actually require the parentheses and where they > don't. We found it to be > difficult to research the subject thoroughly and to > make the BNF conform to > that. If we take the approach that the BNF in the > next revision can be more > lenient as long as it does not forbid anything which > currently works, then it > might be easier. Actually, I take back the idea to completely merge mintypmax_expression in expression. There are several places where this would cause unnecessary ambiguities because of the colons: - ranges/dimensions - case items (including the generate variety) statements You could do the merger everywhere except these places. Or, at a minimum, timing_check_limit (and threshold?) from A.7.5.2 should be changed to mintypmax_expression, since there is code that has it for those system timing check commands. > > But, if you don't do this, at least make all of > the places that can have delay/time values use > mintypmax_expression instead. Here are the ones I > found: > > > > A.2.2.1: variable_type > > > > A.4.1: ordered_parameter_assignment (named > parameters allow mintypmax, but ordered doesn't) > > > > A.6.5: wait statement nevermind this one. I forgot what the expression was in the wait statement was - a condition. > > A.7.5.2: timing_check_limit (found the issue here > originally while parsing some example code with a > $period statement and colons used direction in these > timing_check_limit arguments) > > I haven't looked at these. > > > > Again, I think expression and mintypmax_expression > should be merged (along with constant_expression and > module_path_expression) instead. > > I looked at merging constant_expression and > module_path_expression with > expression, as you suggested. I found then different > enough at the basic > element, the primary, that I was reluctant to do > that merger. > > The idea of mintypmax_expression as I remember was > to require parentheses > everywhere except where specifically allowed without > parentheses. > > Bring on the additional issues. > > Shalom > > -- > Shalom Bresticker > Shalom.Bresticker @freescale.com > Design & Reuse Methodology > Tel: +972 9 9522268 > Freescale Semiconductor Israel, Ltd. > Fax: +972 9 9522890 > POB 2208, Herzlia 46120, ISRAEL > Cell: +972 50 5441478 > > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: Re: errata/608: mintypmax_expression usage Date: Fri, 30 Jul 2004 10:45:43 -0700 There's usually a simulator switch to control whether to pick up min, typ or max, with typ as the default. A common use is explore the potential impact of the library cell delay factors. (Mintypmax expressions have no meaning in synthesis.) -- Brad -----Original Message----- From: owner-etf@boyd.com [mailto:owner-etf@boyd.com]On Behalf Of Eric Mahurin Sent: Friday, July 30, 2004 9:50 AM To: etf-bugs@boyd.com Subject: Re: errata/608: mintypmax_expression usage The following reply was made to PR errata/608; it has been noted by GNATS. From: Eric Mahurin <eric_mahurin@yahoo.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/608: mintypmax_expression usage Date: Fri, 30 Jul 2004 09:47:19 -0700 (PDT) --- Shalom.Bresticker@freescale.com wrote: > Eric, > > > Section 4.3 says this: "Values expressed in > min:typ:max format can be used in expressions. The > min:typ:max format can be used > > wherever expressions can appear." > > > > I think the intent is that these ONLY be used with > expressions that are used for generating delays or > times. I don't see where it says that. > > No, mintypmax expressions really can be used > anywhere. Interesting. I've never seen examples of it anywhere else than under the context of delays. Do the simulators actually allow it anywhere? I don't have verilog-xl at my disposal (only gpl-cver). > > Secondly, the BNF is inconsistent in its use of > mintypmax_expression and expression. As it is now, > even an epression can have a mintypmax_expression in > it with parenthesis. > > > > Personally, I think mintypmax_expression should > unified expression and then in the text just > describe when an expression or portion of it should > allow the mintypmax ":" operators. > > mintypmax expressions are discussed somewhat in > issues 174 and 226. > > We know that the BNF is not completely consistent > with where implementations > actually require the parentheses and where they > don't. We found it to be > difficult to research the subject thoroughly and to > make the BNF conform to > that. If we take the approach that the BNF in the > next revision can be more > lenient as long as it does not forbid anything which > currently works, then it > might be easier. Actually, I take back the idea to completely merge mintypmax_expression in expression. There are several places where this would cause unnecessary ambiguities because of the colons: - ranges/dimensions - case items (including the generate variety) statements You could do the merger everywhere except these places. Or, at a minimum, timing_check_limit (and threshold?) from A.7.5.2 should be changed to mintypmax_expression, since there is code that has it for those system timing check commands. > > But, if you don't do this, at least make all of > the places that can have delay/time values use > mintypmax_expression instead. Here are the ones I > found: > > > > A.2.2.1: variable_type > > > > A.4.1: ordered_parameter_assignment (named > parameters allow mintypmax, but ordered doesn't) > > > > A.6.5: wait statement nevermind this one. I forgot what the expression was in the wait statement was - a condition. > > A.7.5.2: timing_check_limit (found the issue here > originally while parsing some example code with a > $period statement and colons used direction in these > timing_check_limit arguments) > > I haven't looked at these. > > > > Again, I think expression and mintypmax_expression > should be merged (along with constant_expression and > module_path_expression) instead. > > I looked at merging constant_expression and > module_path_expression with > expression, as you suggested. I found then different > enough at the basic > element, the primary, that I was reluctant to do > that merger. > > The idea of mintypmax_expression as I remember was > to require parentheses > everywhere except where specifically allowed without > parentheses. > > Bring on the additional issues. > > Shalom > > -- > Shalom Bresticker > Shalom.Bresticker @freescale.com > Design & Reuse Methodology > Tel: +972 9 9522268 > Freescale Semiconductor Israel, Ltd. > Fax: +972 9 9522890 > POB 2208, Herzlia 46120, ISRAEL > Cell: +972 50 5441478 > > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From: Shalom.Bresticker@freescale.com To: Brad Pierce <Brad.Pierce@synopsys.com> Cc: etf-bugs@boyd.com Subject: Re: errata/608: mintypmax_expression usage Date: Sat, 31 Jul 2004 23:01:27 +0300 (IDT) Synthesis tools may not implement such a switch, but there is nothing inherent in the mintypmax feature which makes it unusable in synthesis. The name "mintypmax" indicates its typical use, the reason the feature was created in Verilog, but once existing, it can be used for other purposes as well. > There's usually a simulator switch to control whether to pick up > min, typ or max, with typ as the default. A common use is explore > the potential impact of the library cell delay factors. (Mintypmax > expressions have no meaning in synthesis.) Shalom From: Eric Mahurin <eric_mahurin@yahoo.com> To: Shalom.Bresticker@freescale.com, etf-bugs@boyd.com Cc: Subject: Re: errata/608: mintypmax_expression usage Date: Sat, 31 Jul 2004 14:00:18 -0700 (PDT) One problem I see is if you wanted to make a simulator that didn't default to min, typ, or max for delays, but instead effectively simulated a range of delays. For example: a = 1'b0; #1:2:3; a = 1'b1; You might want to treat this equivalent to: a = 1'b0; #1; a = 1'bX; #2; // time=3 a = 1'b1; This way you would be simulating the entire delay range at once. I don't think min:typ:max would make any sense anywhere except delays if you wanted to do such a thing. Eric --- Shalom.Bresticker@freescale.com wrote: > Synthesis tools may not implement such a switch, > but there is nothing > inherent in the mintypmax feature which makes it > unusable in synthesis. > > The name "mintypmax" indicates its typical use, > the reason the feature was created in Verilog, > but once existing, it can be used for other > purposes as well. > > > There's usually a simulator switch to control > whether to pick up > > min, typ or max, with typ as the default. A > common use is explore > > the potential impact of the library cell delay > factors. (Mintypmax > > expressions have no meaning in synthesis.) > > Shalom __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo |
| Unformatted |
|
Hosted by Boyd Technology