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