RE: Real Type documents

For reference purposes I've attached the earlier e-mail trail.

real_data_types_2010_D1.pdf at http://www.eda-twiki.org/twiki/pub/P1647/DownLoads/real_data_types_2010_D1.pdf currently has IEEE_1647_ as the prefix. Although Mac expressed a preference for MAX_INT over IEEE_1647_MAX_INT, no-one else came back on this. I see no need to update the current set of constants, but am open to suggestions here. One problem with dropping off all prefixes is that you will end up with constants named M_E, P_Q, P_C, P_K and P_H, which I suggest would not be easily recognisable as inbuilt constants when embedded in a mass of code - the longer names make it more obvious. Please will people make their views known via the reflector, and we can then perhaps hold a vote on which solution to take.

Cheers,

Darren

-----Original Message-----
From: Matan Vax [mailto:matan@cadence.com]
Sent: Monday, February 08, 2010 1:45 PM
To: Matan Vax; Galpin Darren (IFGB ATV MCD CV); Bartley Mike (IFGB ATV MCD CV External)
Cc: Andrew Piziali; Michael (Mac) McNamara
Subject: RE: Real Type documents

BTW, Mike, Darren, did we reach a decision on the issue of real constants naming? Andy and Mac suggested that we use a prefix more appropriate than 'SN_', and proposed 'IEEE_1647_'. But I noted that this is long, superfluous, and is inconsistent with other constants in the LRM, which have no prefix at all (and why should they?). I think Andy and Mac agreed to this resolution. What is the status of this issue?
Thanks,
Matan.
 
>-----Original Message-----
>From: Matan Vax
>Sent: Monday, February 08, 2010 12:42 PM
>To: 'darren.galpin@infineon.com'; Mike.Bartley@infineon.com
>Cc: Joseph Hupcey III; Serrie.Chapman@infineon.com
>Subject: RE: Real Type documents
>
>Hi Darren,
>
>Indeed this document was taken from the Specman "Usage and Concepts
>Guide", so it is not in the form of a formal language reference. I
>think the formal aspects can easily be extracted from it, and the rest
>should be left as implementation dependent (probably most of the
>content of this doc). I agree with Mike that this should be done with
>respect to general requirements.
>
>It is obvious that one needs a random routine such as 'rdist_uniform()'
>and this should be captured in the standard. It's also natural to
>expect constraints like "x == y", "x in {y;z;w}" and perhaps also "x !=
>y" to work with real type variables and values (this is currently
>supported in Specman's IntelliGen). It seems that some constraints are
>inherently problematic with real numbers (such as "x > Y"). But I am
>not even sure the standard needs to enumerate the constraints that are
>applicable to reals and those that are not. What do you guys think?
>
>Matan.
>
>>-----Original Message-----
>>From: darren.galpin@infineon.com [mailto:darren.galpin@infineon.com]
>>Sent: Monday, February 08, 2010 10:14 AM
>>To: Matan Vax
>>Cc: Joseph Hupcey III; Mike.Bartley@infineon.com;
>>Serrie.Chapman@infineon.com
>>Subject: FW: Real Type documents
>>
>>Hi Matan,
>>
>>Are there any further documents which describe coverage and
>>constraints
>for
>>real numbers at all? From Mike's e-mail below, it would seem that the
>>documentation sent relates to the Specman implementation rather than
>>specifying the language/
>>
>>Cheers,
>>
>>Darren
>>
>>-----Original Message-----
>>From: Mike Bartley TVS [mailto:mike@tandvsolns.co.uk]
>>Sent: Sunday, February 07, 2010 9:46 PM
>>To: Galpin Darren (IFGB ATV MCD CV); Chapman Serrie (IFGB ATV MCD CV)
>>Cc: 'Mike TVS'
>>Subject: RE: Real Type documents
>>
>>Hi Darren
>>
>>My main comment here is that these documents relate more to the
>>capabilities/limitations of Pgen and Intelligen rather than what we
>>would require of the language
>>
>>Maybe we should start from a requirements perspective rather than a
>current
>>tool perspective
>>
>>Regards
>>
>>Mike
>>
>>
>>_____________________________________________
>>
>>Mike Bartley
>>
>>Test and Verification Solutions Ltd (TVS)
>>
>>Mobile: +44 (0) 7796 307958
>>
>>http://www.tandvsolns.co.uk
>>
>>
>>-----Original Message-----
>>From: darren.galpin@infineon.com [mailto:darren.galpin@infineon.com]
>>Sent: 20 January 2010 08:04
>>To: mike@tandvsolns.co.uk; Serrie.Chapman@infineon.com
>>Subject: FW: Real Type documents
>>
>>Hi,
>>
>>Additional real type documentation..... Please review, see what is
>>needed (the real_generation.pdf document seems to contain lots of
>>other stuff as well which is probably already covered), and raise issues as necessary.
>>
>>Cheers,
>>
>>Darren
>>
>>-----Original Message-----
>>From: Matan Vax [mailto:matan@cadence.com]
>>Sent: Wednesday, January 20, 2010 7:44 AM
>>To: Galpin Darren (IFGB ATV MCD CV)
>>Cc: Joseph Hupcey III; Amy Witherow
>>Subject: RE: Real Type documents
>>
>>Hey Darren,
>>
>>I'm sorry that this task was delayed for so long. I attach the two
>>framemaker sources I got from our technical publication team per my
>>request.
>>I hope they are the right ones (if not let me know).
>>
>>Matan.
>>
>>>-----Original Message-----
>>>From: darren.galpin@infineon.com [mailto:darren.galpin@infineon.com]
>>>Sent: Thursday, January 14, 2010 11:13 AM
>>>To: Joseph Hupcey III; Matan Vax
>>>Cc: Amy Witherow
>>>Subject: Real Type documents
>>>
>>>Hi,
>>>
>>>Just a reminder that I'm still after the additional source material
>>>for the real data type issue (the additional sub-chapters missing
>>>from the original donation concerning coverage etc). Please could you
>>>get hold of the original framemaker sources and forward them on to me
>>>and Amy as soon as possible.
>>>
>>>Cheers,
>>>
>>>Darren
>>>
>>>---------------------------------------------------------------------
>>>--
>>>----
>>>---------
>>>Darren Galpin Tel: +44 117 9528741
>>>Infineon Technologies Fax: +44 117 9528777
>>>Infineon House
>>>Darren.Galpin@infineon.com<mailto:Darren.Galpin@infineon.com>
>>>Great Western Court
>>>Hunts Ground Road
>>>Stoke Gifford
>>>Bristol, BS34 8HP, England.
>>>---------------------------------------------------------------------
>>>--
>>>----
>>>---------
>>>
>>>
>>
>>
>>
>>
>>__________ Information from ESET Smart Security, version of virus
>signature
>>database 4788 (20100120) __________
>>
>>The message was checked by ESET Smart Security.
>>
>>http://www.eset.com
>>
>>
>>
>>__________ Information from ESET Smart Security, version of virus
>signature
>>database 4845 (20100207) __________
>>
>>The message was checked by ESET Smart Security.
>>
>>http://www.eset.com
>>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

attached mail follows:

I am ok with MAX_INT instead of IEEE_1648_MAX_INT. My problem was with the P1647 prefix, as the 'P' is only appropriate with the proposed nature of a standard.

After all, I am a three fingered typist (and I knew - the Blackberry is EXACTLY why I did not waste time learning to be a touch typist back in 1972) so fewer characters to type is a good thing!

Mac

----- Original Message -----
From: Matan Vax
To: Andrew Piziali <andy@piziali.dv.org>; Michael (Mac) McNamara
Cc: darren.galpin@infineon.com <darren.galpin@infineon.com>; Mike.Bartley@infineon.com <Mike.Bartley@infineon.com>; Serrie.Chapman@infineon.com <Serrie.Chapman@infineon.com>; ieee1647@eda.org <ieee1647@eda.org>
Sent: Wed Dec 16 00:01:54 2009
Subject: RE: SN constants

Guys,

I tend to agree that SN_ prefix is connoted with Specman, and we should probably get rid of it. But this IEEE_1647_ prefix is seems awkward and redundant to me. Why not prefix every name in the standard this way? In particular, do you think MAX_INT should be renamed IEEE_1647_MAX_INT? Would anyone need to define his own SQRT2? And if someone did, isn't it reasonable to expect that he would prefix his own constant, rather than make everyone use such an unreadable name? I'd rather leave all these constants outside the standard than have such strange names to them.

Matan.

>-----Original Message-----
>From: Andrew Piziali [mailto:andy@piziali.dv.org]
>Sent: Wednesday, December 16, 2009 1:50 AM
>To: Michael (Mac) McNamara
>Cc: darren.galpin@infineon.com; Matan Vax; Mike.Bartley@infineon.com;
>Serrie.Chapman@infineon.com; ieee1647@eda.org; Andrew Piziali
>Subject: Re: SN constants
>
>Mac,
>
>I agree that "IEEE1647" would be a more appropriate prefix for these
>built in macros. Perhaps "IEEE_1647" would be more readable, at the
>expense of an extra character.
>
>Thanks.
>
>-----------------------------------
>Mac wrote:
>
>> "P1647" is the official name for the work product of an open PAR,
>> which would consist of proposed enhancements, changes et cetera for
>> the standard 1647. As such things qualified with P1647 mean something
>> that is coming, but is not yet here.
>
>> So we should use something other than P1647 as the prefix for these
>> macros. As macros need to start with an alphabetic character, I would
>> suggest something like: IEEE1647_M_E
>
>> -----Original Message-----
>> From: owner-ieee1647@eda.org [mailto:owner-ieee1647@eda.org] On Behalf
>> Of Andrew Piziali
>> Sent: Thursday, October 22, 2009 3:48 PM
>> To: darren.galpin@infineon.com
>> Cc: Matan Vax; Mike.Bartley@infineon.com; Serrie.Chapman@infineon.com;
>> ieee1647@eda.org
>> Subject: Re: SN constants
>
>> Darren, you wrote:
>
>>> In the donation for real types, there exists two tables, 17-2
>>> Mathematical constants, and 17-3 Physical constants. Note that all
>>> of the constants defined are prefixed with SN_.
>
>>> Having looked through the LRM, there are no constants there defined
>>> starting with SN_, and SN_ would indicate that it was Specman
>>> specific. Should such constants actually be deleted from the
>>> standard, and be left to be tool specific? What are your thoughts?
>
>> The standard currently includes a list of predefined constants in
>> table 6 of chapter 4. As expected, none of these use the SN_ prefix.
>> I suggest we consider adding these constants to the standard,
>> substituting a new prefix for the SN_ prefix. The prefix serves the
>> purpose of preventing collisions in the constant name space of the
>> environment. A prefix such as "P1647_" would so nicely:
>
>> Table 17-2
>
>> Donated Standard
>> Constant Constant
>> Value Value
>> ----------- --------------
>> SN_M_E P1647_M_E
>> SN_M_LOG2E P1647_M_LOG2E
>> SN_M_LOG10E P1647_M_LOG10E
>> SN_M_LN2 P1647_M_LN2
>> SN_M_LN10 P1647_M_LN10
>> SN_M_PI P1647_M_PI
>> SN_M_TWO_PI P1647_M_TWO_PI
>> SN_M_PI_2 P1647_M_PI_2
>> SN_M_PI_4 P1647_M_PI_4
>> SN_M_1_PI P1647_M_1_PI
>> SN_M_2_PI P1647_M_2_PI
>> SN_M_2_SQRTPI P1647_M_2_SQRTPI
>> SN_M_SQRT2 P1647_M_SQRT2
>> SN_M_SQRT1_2 P1647_M_SQRT1_2
>
>
>> Table 17-3
>
>> Donated Standard
>> Constant Constant
>> Value Value
>> ----------- --------------
>> SN_P_Q P1647_P_Q
>> SN_P_C P1647_P_C
>> SN_P_K P1647_P_K
>> SN_P_H P1647_P_H
>> SN_P_EPS0 P1647_P_EPS0
>> SN_P_U0 P1647_P_U0
>> SN_P_CELSIUS0 P1647_P_CELSIUS0
>
>
>--
> |
> Andy@Piziali.dv.org ________------+------________
> / \
> PGP Key: *---*
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6F66CA9F
Received on Mon Feb 8 06:01:30 2010