ISSUE 608

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-DateJul 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