ISSUE 562

Edit Proposal  Edit Class, Environment, or Release
Number 562
Notify-List
Category errata
Synopsis Need to have a vpiTimeConst in the vpi_user.h file
State proposal
Class errata-ptf
Arrival-DateMar 15 2004
Originator Charles Dawson
Release
Environment
Description
With the addition of size/typed parameters, it is now possible to have a time constant. Therefore, we need to add a return value to vpiConstType.
Fix
Add the following to vpi_user.h:

#define vpiTimeConst 8

immediately after the definition for vpiIntConst.
Audit-Trail

Fix replaced by chas@cadence.com on Mon May 3 07:49:20 2004
Add the following to vpi_user.h:

#define vpiTimeConst 8

immediately after the definition for vpiIntConst.

From: Shalom Bresticker <Shalom.Bresticker@freescale.com>
To: chas@cadence.com
Cc: ptf-bugs@boyd.com
Subject: Re: errata/562: PROPOSAL - Need to have a vpiTimeConst in the vpi_user.h
file
Date: Mon, 03 May 2004 18:31:40 +0300

Excuse me for the ignorance, but what is vpiIntConst?

I look at the various types of vpiConstType (p. 820 of 1364-2001 Version C),
and I understand all the other types, but I don't understand what vpiIntConst
is.

I understand that parameters may have a type, size, sign, and value,
but looking at vpiConstType in Annex G, it seems to be mixing apples and
oranges.

vpiDecConst, vpiBinaryConst, vpiOctConst, vpiHexConst and vpiStringConst all
relate to how an integer constant value is written, but that has nothing to do
with the type of a parameter.

And if I look at 'constant' in 26.6.26, does it make any sense to talk about
whether it has an integer or time type?

At best, this is not documented well (or at all).

Thanks,
Shalom


chas@cadence.com wrote:
>
> Add the following to vpi_user.h:
>
> #define vpiTimeConst 8
>
> immediately after the definition for vpiIntConst.
> http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&database=default&pr=562

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

[ ]Freescale Internal Use Only
[ ]Freescale Confidential Proprietary

From: Shalom.Bresticker@freescale.com
To: ptf-bugs@boyd.com
Cc:
Subject: Re: errata/562: Need to have a vpiTimeConst in the vpi_user.h file
Date: Tue, 15 Jun 2004 14:25:56 +0300 (IDT)

On Mon, 15 Mar 2004 chas@cadence.com wrote:

> With the addition of size/typed parameters, it is now possible to have a time constant.
> Therefore, we need to add a return value to vpiConstType.

The following is from the minutes of 2004-06-14 PTF meeting:

> The left hand side and the right hand side might be different,
> so that is why we need to be able to get the type of the
> parameter. This is probably the answer to Shalom's question,
> but it isn't very clear. Should we be trying to solve this
> now or will whatever we do be obsoleted by systemVerilog?

Let me try to explain my question again.

The syntax of a parameter declaration is:

parameter_declaration ::=
parameter [ signed ] [ range ] list_of_param_assignments
| parameter parameter_type list_of_param_assignments

parameter_type ::= integer | real | realtime | time

A parameter can be typed.
Its type is then integer or real or time. (realtime is the same as real).
An integer is signed. Time is unsigned. Real is signed.

A parameter can be ranged.
In that case, its type does not have a name.
Let's call it a "integer vector".
This can be signed or unsigned.

A parameter can be untyped and unranged, in which case it gets the
type and/or range of the value assigned to it.

In 26.6.12, we see that a parameter has a "constant type" vpiConstType.

The definition of vpiConstType is:

#define vpiConstType 40 /* constant subtypes: */

#define vpiDecConst 1 /* decimal integer */
#define vpiRealConst 2 /* real */
#define vpiBinaryConst 3 /* binary integer */
#define vpiOctConst 4 /* octal integer */
#define vpiHexConst 5 /* hexadecimal integer */
#define vpiStringConst 6 /* string literal */
#define vpiIntConst 7 /* HDL integer constant (1364-2001) */

and you want to add vpiTimeConst also. OK.

So I understand:
vpiIntConst for integer type
vpiRealConst for real and realtime type
vpiTimeConst for time type

That leaves me with parameters of the "integer vector" type.
They have integral values and some number of bits.

But I don't see the relevance of describing the type of a parameter
as Decimal, Binary, Octal, or Hex.

Alternately, if vpiIntConst is intended to be used for "integer vector"
type parameters as well, then again, what is the relevance of Decimal,
Real, Octal, and Hex types?

Note that there is also an ambiguity here as to the value of vpiConstType
for an "integer vector" type parameter. Or look at it as an ambiguity in
the use of vpiIntConst, is it only for "integer" type parameters or also
for "integer vector" type parameters?

Thanks,
Shalom

From: "Jim Vellenga" <vellenga@cadence.com>
To: <Shalom.Bresticker@freescale.com>, <ptf-bugs@boyd.com>
Cc:
Subject: RE: errata/562: Need to have a vpiTimeConst in the vpi_user.h file
Date: Wed, 30 Jun 2004 16:43:13 -0400

Shalom,

If I understood it correctly, at our meeting on 2004-06-14, we came to
the conclusion that the vpiConstType can have a different meaning when
applied to a parameter (as in diagram 26.6.12) than when applied to a
constant (as in 26.6.26). It can also have a different meaning when
applied to a typed parameter than when applied to an untyped parameter.

For a typed parameter, it does mean what you said -- it reports the
parameter_type. Hence, it does not have a value of vpiDecConst,
vpiBinaryConst, vpiOctConst, vpiHexConst, or vpiStringConst. But it
can be a vpiIntConst, vpiRealConst, or (with the current proposal) a
vpiTimeConst.

But when applied to an untyped parameter, it has the same meaning as
when applied to the corresponding constant. That is, vpiConstType can
then have any of the values vpiDecConst, vpiBinaryConst, ....

By experimenting, I found that when the right hand side of the untyped
parameter assignment is an expression rather than a single value, the
vpiConstType is either vpiDecConst or vpiRealConst -- in Cadence's
implementation. For whatever that's worth -- I notice the LRM doesn't
specify what vpiConstType is for constant expressions.

vpiRealConst can appear in either context, of course.

You seem to have observed correctly that the vpiConstType field does
not distinguish between vectors and scalars. However, one does seem to
be able to extract vpiSize, vpiLeftRange, and vpiRightRange. I
presume, but have not verified, that the ranges are NULL for a scalar
parameter.

So, Shalom, we recognized that there was an inconsistency in the
meaning of vpiConstType for the two different kinds of parameters. But
we thought it best not to change that because

-- it could break an existing customer application, and

-- if and when the LRM moves to SystemVerilog types, we'll have to
change the whole mechanism for accessing types anyhow.

If it weren't for the second reason, the task force might have been
more in favor of breaking an existing customer application if
necessary.

It does appear that we need to add some notes to the two diagrams to
make the distinction clear.

Regards,
Jim V.

---------------------------------------------------------
James H. Vellenga 978-262-6381
Engineering Director (FAX) 978-262-6636
Cadence Design Systems, Inc. vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
----------------------------------------------------------

From: Shalom.Bresticker@freescale.com
To: ptf-bugs@boyd.com
Cc:
Subject: RE: errata/562: Need to have a vpiTimeConst in the vpi_user.h file
Date: Thu, 1 Jul 2004 11:49:47 +0300 (IDT)

While I'm digesting this, I have a related question.

27.14 says,

"If a constant object's vpiConstType is vpiStringVal, the value shall be
retrieved using either a format of vpiStringVal or vpiVectorVal."

However, vpiConstType can not be vpiStringVal.
The string form of vpiConstType is vpiStringConst?

--
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: Shalom.Bresticker@freescale.com
To: Jim Vellenga <vellenga@cadence.com>
Cc: ptf-bugs@boyd.com
Subject: RE: errata/562: Need to have a vpiTimeConst in the vpi_user.h file
Date: Thu, 1 Jul 2004 13:10:25 +0300 (IDT)

OK, but what is the reason for distinguishing between the format of a
constant (decimal, hex, binary, octal) ? What difference does it make?

And even if you have a reason in the case of a constant number,
what reason is there for carrying over that distinction to the
vpiConstType of an untyped parameter it is assigned to?

That is, even if you say I need to distinguish between 2'b10 and 2'h2,
I don't see any reason to distinguish between the type of P in

parameter P = 2'b10 ; vs.
parameter P = 2'h2 ;


Yet another case is

parameter integer P = 2;
parameter Q = P ;

P is of type integer.
What is the type of Q?

Thanks,
Shalom


From: "Jim Vellenga" <vellenga@cadence.com>
To: <Shalom.Bresticker@freescale.com>, <ptf-bugs@boyd.com>
Cc:
Subject: RE: errata/562: Need to have a vpiTimeConst in the vpi_user.h file
Date: Thu, 1 Jul 2004 09:17:16 -0400

I can't comment on the _need_ to distinguish the types
of untyped parameters. But I do observe that
vpiConstType was applied to parameters already
in the 1364-1995 standard, before the new types were
available. So if you accept the antecedent of
maintaining backward compatibility when possible,
then it looks to me that the only choice
available back then was reporting the style of lexical
representation of the constant on the right-hand
side, and we ought to continue to do the same.

As to what the vpiConstType is for Q, my tests with
our own tool suggested that the type of an untyped
parameter with an expr on the right-hand side that
is not a constant is either vpiDecConst or
vpiRealConst. So by that logic, the vpiConstType
of Q would be a vpiDecConst.

The alternative, of course, is to do yet another
exception when the right-hand side is just a typed
parameter. In that case, we could specifically say
that Q should have the same vpiConstType as P.

I would tend to go with the former because

a) it probably doesn't matter to our users (see
Shalom's first point), and

b) it (at least conceptually) requires one less
branch in the VPI code.

Regards,
Jim V.

---------------------------------------------------------
James H. Vellenga 978-262-6381
Engineering Director (FAX) 978-262-6636
Cadence Design Systems, Inc. vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
----------------------------------------------------------


From: Shalom.Bresticker@freescale.com
To: Jim Vellenga <vellenga@cadence.com>
Cc: ptf-bugs@boyd.com
Subject: RE: errata/562: Need to have a vpiTimeConst in the vpi_user.h file
Date: Thu, 1 Jul 2004 16:27:44 +0300 (IDT)

> I would tend to go with the former because
>
> a) it probably doesn't matter to our users (see
> Shalom's first point), and

Actually, my point was that the current distinction seems pointless.

Anyway, I think you should consider what would be the Right Thing to do,
and then consider whether it would be a problem to change.

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

[ ]Freescale Internal Use Only
[ ]Freescale Confidential Proprietary

Unformatted




Hosted by Boyd Technology