ISSUE 387

Number 387
Category enhancement
Synopsis calling system tasks at elaboration
State lrmdraft
Class enhancement
Arrival-DateJul 09 2003
Originator sharp@cadence.com
Release 2001c: 4, 10.3.5, A.8.4
Environment
Description
This is a request from my Verilog-AMS contact.

I am not sure exactly what it is a request for. I don't
see any way of calling a system _task_ during elaboration.
It would be possible to allow using a system _function_ in
a constant expression, which would be evaluated during
elaboration. However, there are only a few system functions
that would be appropriate for this. We will need some
clarification on this.
Fix
Revised as passed by BTF 2004-11-29:

This proposal is for allowing 'pure' system functions to be
used in constant expressions which are evaluated at
elaboration time, such as parameter values.

It is assumed that in parallel to this proposal,
there will be another that will add a few math functions
in a new section at the end of Section 17 (BTF #390).

It also assumes final approval of issue #483.

After #483, Clause 4 paragraph 3 says,

"Some statement constructs require an expression to be a constant expression.
The operands of a constant expression consist of constant numbers, strings,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only,
but they can use any of the operators defined in Table 4-1."

CHANGE

"and constant function calls (see 10.3.5) only"

TO

"constant function calls (see 10.3.5) and constant
system function calls only".

ADD new paragraph immediately after paragraph 3:

"Constant system function calls are calls to certain
built-in
system functions where the arguments are constant expressions.
When used in constant expressions, these function calls shall
be evaluated at elaboration time. The system functions which
may be used in constant system function calls are "pure"
functions, i.e. those whose value depends only on their
input arguments and which have no side effects. Specifically,
the system functions allowed in constant expressions are the
conversion system functions listed in 17.8 and the
mathematical system functions listed in 17.11".

--

In 10.3.5, CHANGE

"All system functions within a constant function shall be
illegal."

TO

"It shall be legal to call any system function which is
allowed in a constant_expression (see Clause 4).
Calls to other system functions shall be illegal."

--

In Syntax 4-2 and A.8.4, in constant_primary,

CHANGE

| constant_function_call

TO

| constant_function_call
| constant_system_function_call


In A.8.2, ADD

constant_system_function_call ::=
system_function_identifier
"(" constant_expression { "," constant_expression } ")"


Audit-Trail
From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com
Cc:
Subject: enhancement/387: calling system functions at elaboration
Date: Thu, 29 Apr 2004 17:08:00 -0400 (EDT)

Regardless of what the original Verilog-AMS request was, I am going to
treat this as an enhancement request to allow certain built-in system
functions in constant expressions (which must be evaluatable at elaboration
time).

The only functions suitable for this would be "pure" functions, i.e. those
whose value depends only on their input arguments and which have no side
effects. Looking at the list in section 17, the only existing system
functions that appear to be suitable are the "Conversion functions".

Note that since coercion to signed and unsigned were done with the system
functions $signed and $unsigned, there is currently no way to perform such
a coercion in a constant expression. The same is true of forcing conversion
of a real value to an integer (conversion of an integer to a real can be
done by forcing an implicit conversion, for example by adding 0.0 to it).

In Verilog-1995, there was no way to define a parameter with the integer
value of a real expression, since a parameter defined with a real expression
would automatically be of real type. In Verilog-2001, this is now possible
by explicitly declaring the parameter to be an integer type, so that a real
value assigned would get implicitly converted. So with Verilog-2001 typed
parameters, there is less need for being able to use system functions that
perform explicit conversions. You can declare an intermediate parameter of
the type being converted to, and assign it the sub-expression to be converted,
and get an implicit conversion. For example:

parameter area = $rtoi(3.1416 * radius ** 2);

could be done (ignoring the truncation vs. rounding difference) by

parameter integer area = 3.1416 * radius ** 2;

Or suppose we needed signed division of unsigned operands in a constant
expression:

reg [($signed(param_a[7:0]) / $signed(param_b[3:0])) : 0] r;

This could be done by

parameter signed s_a = a[7:0];
parameter signed s_b = b[3:0];
reg [(s_a / s_b) : 0] r;

So it is possible to get these conversions in elaboration-time constant
expressions in Verilog-2001, though it would be clumsy. That reduces the
importance of this enhancement if it applies only to these conversion
functions.

It might become more valuable if the math functions proposed in issue 390
were added. Those math functions would also qualify as "pure" functions,
which would be suitable for use in constant expressions.

There might also be integer math functions that would be more useful to
digital designers, which would also qualify. These might not be common
enough to justify adding new operators, but might be desirable in constant
expressions. Adding them as system functions that are allowed in constant
expressions would resolve that. An obvious example would be an integer
ceiling-of-log-base-2 function. Yes, this can be done with a Verilog
constant function already. But the errors in early versions of the clogb2
example of a Verilog constant function shows that it is easy to make a
mistake in writing such a function. Since this seems to be by far the
most desired constant function, it makes sense to just build it into the
language.

If the user replaced the built-in system function with a user-defined PLI
function of the same name, then that function would not be legal in a
constant expression (since it is not the same function that was legal).
Allowing user-defined PLI system function in a constant expression would
create many potential problems, since I see no way to ensure that such a
function was pure. This would be a different request, which may be what
issue 386 is about.

Steven Sharp
sharp@cadence.com


Fix replaced by Shalom.Bresticker@freescale.com on Wed Nov 24 08:50:11 2004


This proposal is for allowing 'pure' system functions to be
used in constant expressions which are evaluated at
elaboration time, such as parameter values.

It is assumed that in parallel to this proposal,
there will be another that will add a few math functions
in a new section at the end of Section 17.

It also assumes final approval of issue #483.

After #483, Clause 4 paragraph 3 says,

"Some statement constructs require an expression to be a constant expression.
The operands of a constant expression consist of constant numbers, strings,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only,
but they can use any of the operators defined in Table 4-1."

CHANGE

"and constant function calls (see 10.3.5) only"

TO

"constant function calls (see 10.3.5) and constant
system function calls only".

ADD new paragraph immediately after paragraph 3:

"Constant system function calls are calls to certain
system functions where the arguments are constant expressions.
When used in constant expressions, these function calls shall
be evaluated at elaboration time. The system functions which
may be used in constant system function calls are "pure"
functions, i.e. those whose value depends only on their
input arguments and which have no side effects. Specifically,
the system functions allowed in constant expressions are the
conversion system functions listed in 17.8 and the
mathematical system functions listed in 17.11".

--

In 10.3.5, CHANGE

"All system functions within a constant function shall be
illegal."

TO

"Constant system function calls (see 4) shall be legal.
Calls to other system functions shall be illegal."

--

In Syntax 4-2 and A.8.4, in constant_primary,

CHANGE

| constant_function_call

TO

| constant_function_call
| constant_system_function_call


In A.8.2, ADD

constant_system_function_call ::=
system_function_identifier
"(" constant_expression { "," constant_expression } ")"




From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@freescale.com
Cc:
Subject: Re: enhancement/387: PROPOSAL - calling system tasks at elaboration
Date: Sun, 28 Nov 2004 16:23:05 -0500 (EST)

>In 10.3.5, CHANGE
>
>"All system functions within a constant function shall be
>illegal."
>
>TO
>
>"Constant system function calls (see 4) shall be legal.
>Calls to other system functions shall be illegal."

It doesn't need to be a "constant system function call", just a call to
a "constant system function". Except that the second term hasn't been
defined. The distinction is that a "constant system function call"
requires all arguments to be constant expressions. But within a constant
function, it should be OK for the arguments to be variables local to the
constant function (such as arguments of the function), which are not
technically constant expressions. So while it must be a call to one of
the system functions allowed in a "constant system function call", the
call need not be a "constant system function call".


Steven Sharp
sharp@cadence.com

From: Shalom.Bresticker@freescale.com
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: enhancement/387: PROPOSAL - calling system tasks at elaboration
Date: Mon, 29 Nov 2004 05:50:53 +0200 (IST)

OK, I will revise.

On Sun, 28 Nov 2004, Steven Sharp wrote:

>
> >In 10.3.5, CHANGE
> >
> >"All system functions within a constant function shall be
> >illegal."
> >
> >TO
> >
> >"Constant system function calls (see 4) shall be legal.
> >Calls to other system functions shall be illegal."
>
> It doesn't need to be a "constant system function call", just a call to
> a "constant system function". Except that the second term hasn't been
> defined. The distinction is that a "constant system function call"
> requires all arguments to be constant expressions. But within a constant
> function, it should be OK for the arguments to be variables local to the
> constant function (such as arguments of the function), which are not
> technically constant expressions. So while it must be a call to one of
> the system functions allowed in a "constant system function call", the
> call need not be a "constant system function call".

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Verification Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary


Fix replaced by Shalom.Bresticker@freescale.com on Mon Nov 29 01:23:58 2004
Revised 2004-11-29:

This proposal is for allowing 'pure' system functions to be
used in constant expressions which are evaluated at
elaboration time, such as parameter values.

It is assumed that in parallel to this proposal,
there will be another that will add a few math functions
in a new section at the end of Section 17 (BTF #390).

It also assumes final approval of issue #483.

After #483, Clause 4 paragraph 3 says,

"Some statement constructs require an expression to be a constant expression.
The operands of a constant expression consist of constant numbers, strings,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only,
but they can use any of the operators defined in Table 4-1."

CHANGE

"and constant function calls (see 10.3.5) only"

TO

"constant function calls (see 10.3.5) and constant
system function calls only".

ADD new paragraph immediately after paragraph 3:

"Constant system function calls are calls to certain
system functions where the arguments are constant expressions.
When used in constant expressions, these function calls shall
be evaluated at elaboration time. The system functions which
may be used in constant system function calls are "pure"
functions, i.e. those whose value depends only on their
input arguments and which have no side effects. Specifically,
the system functions allowed in constant expressions are the
conversion system functions listed in 17.8 and the
mathematical system functions listed in 17.11".

--

In 10.3.5, CHANGE

"All system functions within a constant function shall be
illegal."

TO

"It shall be legal to call any system function which is
allowed in a constant_expression (see Clause 4).
Calls to other system functions shall be illegal."

--

In Syntax 4-2 and A.8.4, in constant_primary,

CHANGE

| constant_function_call

TO

| constant_function_call
| constant_system_function_call


In A.8.2, ADD

constant_system_function_call ::=
system_function_identifier
"(" constant_expression { "," constant_expression } ")"





Fix replaced by Shalom.Bresticker@freescale.com on Tue Nov 30 01:09:36 2004
Revised as passed by BTF 2004-11-29:

This proposal is for allowing 'pure' system functions to be
used in constant expressions which are evaluated at
elaboration time, such as parameter values.

It is assumed that in parallel to this proposal,
there will be another that will add a few math functions
in a new section at the end of Section 17 (BTF #390).

It also assumes final approval of issue #483.

After #483, Clause 4 paragraph 3 says,

"Some statement constructs require an expression to be a constant expression.
The operands of a constant expression consist of constant numbers, strings,
parameters, constant bit-selects and part-selects of parameters,
and constant function calls (see 10.3.5) only,
but they can use any of the operators defined in Table 4-1."

CHANGE

"and constant function calls (see 10.3.5) only"

TO

"constant function calls (see 10.3.5) and constant
system function calls only".

ADD new paragraph immediately after paragraph 3:

"Constant system function calls are calls to certain
built-in
system functions where the arguments are constant expressions.
When used in constant expressions, these function calls shall
be evaluated at elaboration time. The system functions which
may be used in constant system function calls are "pure"
functions, i.e. those whose value depends only on their
input arguments and which have no side effects. Specifically,
the system functions allowed in constant expressions are the
conversion system functions listed in 17.8 and the
mathematical system functions listed in 17.11".

--

In 10.3.5, CHANGE

"All system functions within a constant function shall be
illegal."

TO

"It shall be legal to call any system function which is
allowed in a constant_expression (see Clause 4).
Calls to other system functions shall be illegal."

--

In Syntax 4-2 and A.8.4, in constant_primary,

CHANGE

| constant_function_call

TO

| constant_function_call
| constant_system_function_call


In A.8.2, ADD

constant_system_function_call ::=
system_function_identifier
"(" constant_expression { "," constant_expression } ")"




From: Steven Sharp <sharp@cadence.com>
To: btf@boyd.com, etf-bugs@boyd.com
Cc:
Subject: enhancement/387: editing error in implementing proposal
Date: Thu, 28 Apr 2005 15:39:04 -0400 (EDT)

In 10.3.5 in draft 5, there appears to be an editing error in implementing
the proposal. The proposal says to replace the bullet that says all system
functions are illegal with the new one allowing certain system functions.
However, the old bullet is still there. Meanwhile, the bullet saying that
system tasks are ignored is missing. I assume that the wrong bullet got
replaced by mistake.

Steven Sharp
sharp@cadence.com

From: Shalom.Bresticker@freescale.com
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: enhancement/387: editing error in implementing proposal
Date: Mon, 2 May 2005 10:10:39 +0300 (IDT)

I agree.

Shalom


On Thu, 28 Apr 2005, Steven Sharp wrote:

> In 10.3.5 in draft 5, there appears to be an editing error in implementing
> the proposal. The proposal says to replace the bullet that says all system
> functions are illegal with the new one allowing certain system functions.
> However, the old bullet is still there. Meanwhile, the bullet saying that
> system tasks are ignored is missing. I assume that the wrong bullet got
> replaced by mistake.

From: Shalom.Bresticker@freescale.com
To: etf-bugs@boyd.com
Cc: tom_fitzpatrick@mentor.com
Subject: Re: enhancement/387: editing error in implementing proposal
Date: Mon, 2 May 2005 19:30:29 +0300 (IDT)

The previous task of P1364-2005 had the following dashed items in 10.4.5 (Use of constant functions):

"-- All system tasks within a constant function shall be ignored.
-- All system functions within a constant function shall be illegal."

The second item, about system functions, should have been deleted.
Instead, by mistake, the first one, about system tasks, was deleted.
So it now looks like,

"-- It shall be legal to call any system function which is allowed in a constant_expression (see Clause 5). Calls to other system functions shall be illegal.
-- All system functions within a constant function shall be illegal."

The correction is to delete the line,
"-- All system functions within a constant function shall be illegal."

and add back the line
"-- All system tasks within a constant function shall be ignored."

Shalom

Unformatted


Hosted by Boyd Technology