RE: [sv-cc] Errors in LRM draft6 to add

Hi all,

the ranges had to be redone due to conflict between the original ranges and
several commercial tools (specifically NCV)
Note also that overlaps in the ranges are permitted for different categories
of identifiers (object types vs properties
vs callbacks etc)

Joao
============================================================================
==
Joao Geada, PhD Principal Engineer Verif Tech
Group
Synopsys, Inc TEL: (508)
263-8083
377 Simarano Drive, Suite 300, FAX: (508)
263-8069
Marlboro, MA 01752, USA
============================================================================
==

  -----Original Message-----
  From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of Michael
Rohleder
  Sent: Thursday, April 22, 2004 1:29 PM
  To: bassam@novas.com
  Cc: sv-cc@eda.org
  Subject: Re: [sv-cc] Errors in LRM draft6 to add

  Hi Bassam,
  thanks a lot for finding this interesting problem.

  While reviewing it, I think I'll found some more:
   - vpiAssertion is #defined on page 360, but not in the Annex I
   - the defines for vpiSequenceType, vpiAssertType, vpiCoverType,
vpiPropertyType, vpiImmediateAssertType
     on page 360 and in Annex I (pg 556) do NOT match
   - actually the Coverage VPI seemed to intrude into the space of the
Assertion VPI in the Annex, for whatever reason;
      the #defines in chapter 29.4 do not have their numbers assigned, so I
could not cross-check this

  In general it looks to me like the sv_vpi_user.h file in draft 6 is
screwed up a little :-(.
  There are some ranges used multiple times (e.g. 600-, 700-) The assertion
API starts by 731 and then the related
  callbacks start from 606, ... [this is in contrast to the text in chapter
28] Coverage starts with 711, ... [?!?!]
  Operators start with 50 [do we have this space assigned ?]. Generic object
properties are also starting at 600-625
  Main object start again with 600 and go up to 711. For me this looks like
we have completely messed up the number
  space assigned to the vpi #defines in draft 6.

  This must have happened after our review on draft 4, here the .h file is a
much older version. The draft 6 says these
  changes are related to LRM-284, which just notes 'formatting of
sv_vpi_user.h'. But it looks like these changes have
  actually been introduced in draft5: LRM209, 258, 281.
  But the assigned ranges are not in line with the ones defined in
http://www.eda.org/sv-cc/hm/1842.html
  Joao, what is going on here ?

  Bassam, I'll think we all owe you some <choose whatever is appropriate>
for finding this...
  I think it is time for all of to review this. Best before tomorrow.

  Regards,
  -Michael

  Bassam Tabbara wrote:

     Guys, please someone look this over and check again ... and double
check please before we add to official errata.1) p. 361 we say:
    "4) To obtain an assertion of a specific type, e.g. cover assertions,
the following approach should be used:

    vpiHandle assertion;

    itr = vpi_iterate(vpiAssertionType, NULL);

    while (assertion = vpi_scan(itr)) {

    if (vpi_get(vpiAssertionType, assertion) == vpiCoverType) {

    /* process cover type assertion */

    }

    }"

    should be:

    "4) To obtain an assertion of a specific type, e.g. cover assertions,
the following approach should be used:

    vpiHandle assertion;

    itr = vpi_iterate(vpiAssertion, NULL);

    while (assertion = vpi_scan(itr)) {

    if (vpi_get(vpiAssertionType, assertion) == vpiCoverType) {

    /* process cover type assertion */

    }

    }"
    2) vpiAssertionType property does not exist in the list on p. 359 28.2.2
Object properties

    This section lists the object property VPI calls. The VPI reserved range
for these calls is 700 - 729.

    #define vpiAssertionType 706 /* AssertionType property */

    /* Assertion types */

    #define vpiSequenceType 701

    #define vpiAssertType 702

    #define vpiCoverType 703

    #define vpiPropertyType 704

    #define vpiImmediateAssertType705
     --
    Dr. Bassam Tabbara
    Technical Manager, R&D
    Novas Software, Inc.

    http://www.novas.com
    (408) 467-7893

  --

  NOTE: The content of this message may contain personal views
        which are not neccessarily the views of Motorola or Freescale,
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:
  General Business Information ( )
  Motorola and Freescale Internal Use Only ( )
  Motorola and Freescale Confidential Proprietary ( )

  *** This note may contain Motorola and Freescale Confidential Proprietary
or Motorola and Freescale 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! ***
Received on Thu Apr 22 13:58:03 2004