RE: 1647 real type issues

Hi Matan,

The two issues referred to were 2881 and 2874, and were e-mailed by Mike Bartley on the 2nd November. In addition to this were the missing sections for real number generation and coverage, and yes please could you get hold of these sections and forward them on.

As regards to the constants, I would refer you to Mac and Andy's e-mails from last night. We can't really have constants which are Specman specific, so having IEEE1647 specific ones makes sense, and Specman can support both. To be realistic, it is Specman which should be following the standard, rather than ensuring that the standard always follows Specman. After all, there could be other implementations out there.... ;)

Cheers,

Darren

________________________________
From: Matan Vax [mailto:matan@cadence.com]
Sent: Tuesday, December 15, 2009 7:13 PM
To: Galpin Darren (IFGB ATV MCD CV); ieee1647@eda.org
Subject: 1647 real type issues

Hello Darren,

I've looked through my mailbox but haven't run into those e-mails about real type that you mentioned yesterday. I guess you were referring to issue 2884 about the missing sections on real number generation and coverage. So I just need to get a hold of these sections, right? Looking at them in the Cadence e manual it seems that they require some work (they have a lot of tool references, and include a lot of examples).

I have two comments on resolutions to previous issues:

I think the C interface part should be left outside the standard. There is no mention of C interface for any other part of the language, and it makes no sense to have it just for reals. If we choose to standardize the existing C interface supported by Specman we would need to do it across the board.

I am uncomfortable with the new names for constants that were chosen. The P1647_ prefix is a naming convention we don't have anywhere else in the standard, and in particular not for existing numeric constants. Also this definition would immediately make all Specman versions non-complaint in this respect. Perhaps we should leave these constants outside the standard. Otherwise I think we should discuss again the right names for these constants.

Thanks,
Matan.

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