Re: [sv-cc] Polls on Coverage VPI and String datatype

Subject: Re: [sv-cc] Polls on Coverage VPI and String datatype
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Fri Feb 07 2003 - 07:37:31 PST

Hi,

here are my comments.

Best regards,
Michael

Swapnajit Mittra wrote:

> For both of these, send your comments as Y/N/A by Friday (02/07).
>
> I. Poll on Coverage VPI:
> The latest version is at:
> http://www.eda.org/sv-cc/hm/0747.html

YES.

> II. Poll on accepting String datatype

> proposed by SV-EC:
> See Joao's reply to my question on this:
> http://www.eda.org/sv-cc/hm/0754.html

YES. with some comments (not related to sv-cc, but it might be useful for sv-ec):
 - the draft does not specify how the truncation is being done when assigned to an array of smaller size (from left or from right -
I assume from the left, but this is not said).
 - the draft talks a lot about assigning string literals to packed arrays, and string variables, but it omits the case where a
string variable is assigned to a packed array. On the other side there is an example doing exactly this. I assume this is correct,
but the text does not reflect this possibility ... at least I am not able to find this.
 - the operators in the table 3-2 should be introduced before the example. The replication operator would be otherwise used before
its definition.
 - It should describe the assumed character set for strings (only ASCII is not enough it has been too often used ambigously, but it
doesn't even say this in the section 3.7). Otherwise some methods would have some ambiguity. Simple example: let's assume IBM's
8-bit version of ASCII, which includes ä, ö, ü. The toupper method of this would have to provide Ä, Ö, Ü when there is no definition
of the permitted character set. I don't say I want this to be supported, I just think you should say what is permitted and could be
expected (e.g. restrict it to 7-bit ISO ASCII).
 - atohex should say whether lowercase and uppercase characters are permitted. I assume yes ...
 - none of the atohex, atooct, atol define how to handle illegal characters ...
   So what is the result of str.atol("123einszweidrei"), or str.atohex("AcXEF") ???

plus a question to sv-cc:
 - Do we need to distinguish between string variables and string literals on the boundary between SV and C side ???

> III. Also, if I do not hear any objection, Issue 1.4 ("pure")
> will be considered as approved unanimously as per discussion
> on 02/04.

YES

> Members eligible to send their comments:
>
> Francoise Martinole
> Stuart Swan
> John Amouroux
> John Stickley
> Doug Warmke
> Michael Rohleder
> Kevin Cameron
> Bassam Tabbara
> Joao Gaeda
> Andrzej Litwiniuk
>
> Regards,
> - Swapnajit.
>
> --
> Swapnajit Mittra
> Project VeriPage ::: http://www.angelfire.com/ca/verilog
>
> ________________________________________________________________
> Sign Up for Juno Platinum Internet Access Today
> Only $9.95 per month!
> Visit www.juno.com 

--

NOTE: The content of this message may contain personal views
      which are not neccessarily the views of Motorola, unless specifically stated.

         ___________________________________________________
        |                                                   |
      _ | Michael Rohleder            Tel: +49-89-92103-259 | _
     / )| Software Technologist       Fax: +49-89-92103-680 |( \
    / / | Motorola, Semiconductor Products, System Design   | \ \
  _( (_ |  _   Schatzbogen 7, D-81829 Munich, Germany    _  | _) )_
 (((\ \>|_/ >                                           < \_|</ /)))
 (\\\\ \_/ /    mailto:Michael.Rohleder@motorola.com     \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \

The information contained in this email has been classified as:
Motorola General Business Information (x)
Motorola Internal Use Only            ( )
Motorola Confidential Proprietary     ( )

*** This note may contain Motorola Confidential Proprietary or
    Motorola Internal Use Only Information and is intended to be
    reviewed by only the individual or organization named above.
    If you are not the intended recipient or an authorized representative
    of the intended recipient, you are hereby notified that any review,
    dissemination or copying of this email and its attachments, if any,
    or the information contained herein is prohibited. If you have received
    this email in error, please immediately notify the sender by
    return email and delete this email from your system.
    Thank you! ***

This archive was generated by hypermail 2b28 : Fri Feb 07 2003 - 07:38:13 PST