[sv-bc] RE: [sv-cc] Read API

From: Bassam Tabbara <Bassam.Tabbara_at_.....>
Date: Tue Oct 02 2007 - 18:33:06 PDT
Hi Matt,

The summary below seems lacking/inconsistent to me -- please elaborate. 

The read API is NOT meant to provide a portable file format rather the
opposite (see LRM) so the reasoning of motion, as stated below, and the
outcome is not clear. VCD and the API have same ultimate goal yes (i.e.
data query) but they are distinct -- meaning we can have either, both,
or none (!). Current LRM strategy offers the API and discusses the
advantages of an API (e.g. efficiency) over file exchange.

Thx.
-Bassam.

-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
Maidment, Matthew R
Sent: Tuesday, October 02, 2007 4:55 PM
To: sv-cc@eda.org
Cc: sv-bc@eda.org
Subject: [sv-cc] Read API

Hello SV-CC	

As the future of the Read API could impact the future of the VCD
specification as well as impact the ability of users to debug, the SV-BC
discussed the proposal to deprecate the Read API.

During the October 1 meeting, a majority (_not_ unanimous) vote was
passed to communicate to the SV-CC that the SV-BC has no objection to
deprecating the Read API.

Per the unapproved minutes:

  Stu moves that the SV-BC notify the SV-CC that the SV-BC has no
  objection to deprecating the Read API.  Reasons: the API does
  not solve the problem of a portable file format for debug information.
  Cliff seconds.

  For: Cliff, Mark, Dave, Steven, Gord, Stu, Alex, Don
  Opposed: Brad (approved during the SV process and should not be
removed)
           Shalom (Need a commitment to provide a new method for
providing 
                   information or extension of vcd)
           Tom (Agrees with Shalom's comments)
  Abstain: Francoise (Some potential names to maintain the read api)
           Karen (may be escalated- will withhold opinion)

We hope this helps in your process to decide the fate of the Read API.

Matt
--
Matt Maidment
mmaidmen@ichips.intel.com
 

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



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Oct 2 18:33:29 2007

This archive was generated by hypermail 2.1.8 : Tue Oct 02 2007 - 18:34:38 PDT