[sv-cc] Minutes of the special SV-CC conference call on 23-Apr-2004

Attendees:
   Ralph Duncan
   Joao Geada
   Andrzej Litwiniuk
   Francoise Martinole
   Swapnajit Mittra
   Michael Rohleder
   Bassam Tabbara
   Doug Warmke

Acceptance of meeting minutes from last conference call:
 - Ralph proposed, Joao seconded

Swapnajit informed used on how to proceed with errata finding and processing:
 - asking Joao to maintain a spreadsheet of all errata and other findings
 - updates to the teams on a weekly or bi-weekly basis
 - Joao agreed to take over the ownership for this task

a) aval/bval vs. c/d
Swapnajit asked Vassilios and other people about this issue:
 - Vassilios suggested to remove the line saying 'compatible with IEEE 1364'
   [this does not mean that it will not be changed later, nor that it will not be rediscussed for the next revision]
 - for SV3.1a Swapnajit suggests that we will strike out this line, to make SV3.1a consistent
   [there was no disagreement to this proposal]
 - Note the inconsistency with IEEE1364 aval/bval to be an issue that should go along with the release to IEEE
   (Doug further suggested that we discuss this further via email)

b) about Bassams errata http://www.eda.org/sv-cc/hm/1925
   accepted by everybody

c) about the errata found by Michael http://www.eda.org/sv-cc/hm/1927
   - we need to fix the inconsitency within the LRM between earlier sections and the appendix (agreed)
   - Bassam mentioned that there is one entry missing: vpiAssertion (see above point)
   - Joao mentioned that certain types are permitted to overlap, since they cover different object entities
   - Joao and Francoise explained that they had to reorder the entries in last minute for draft5, since there were some
     incompatibilities of existing tools with the planned numbering scheme, namely the range 500-600. Squeezing all
     the needed numbers into this range was not an easy task and intruded into the other ranges. As a result, Joao
     just renumbered everything from the scratch, starting at 600 ...
   - Michael countered that it would be still possible to just move the Coverage and Assertion API ranges to have
     clear range description (e.g. to start with 750 & 780 ...). A clear range distinction would be useful when working
     with debuggers, where the #defines are not usable.
     Joao mentioned that this could be solved by using enums, but this would break VPI. And there are no different API's,
     as a matter of fact, there is only one VPI related to different topics.
   - Michael still would like to see this organized in a more structured way as it was before (with some holes inbetween),
     so it is easier to stitch in corrections (as already found) or further enhancements.
     Otherwise we can just append new item definitions, which could then break logical relationsships between the numbers.
   - Joao does no longer want to do such changes or limit them to a last one, for financial reasons; every (re-)compile
     using new numbers cost them money.
   - The agreement was that Joao and Michael further discuss on how reorganize the message numbering within the file
     into a more logical form for a last time.

   - Bassam stated that we need to enhance the Assertion API later for local variable usage; there is no way to access these
variables from within the API ... Joao said this would be nice, but it is not easy to do. As a matter of fact there might be
     multiple instance of these variables for different attempts. Any solution here might end up to be dependent on the
     actual implementation. This issue will be noted for future enhancements

Best regards,
-Michael

--
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! ***