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

I've been noticing with many of these resolutions that when a motion
passes, none of the reasons for the yea votes get recorded, yet all the
nay votes get their opinions forwarded around.

As a sv-bc member, I voted for depreciation because I believe at this
level, each committee has a right to deprecate any feature as long as it
does not impact the workings of the other committees, which in this case
holds true. Backward compatibility issues must be mitigated by the
affected committees and the Working Group.

The motion was not worded they way I would have liked, but in the
interest of time, I was willing to vote in favor as long as the outcome
was the same. 

Just because I voted for deprecation does not mean I am against having a
Read API. On the contrary, I'm all for having a Read API that everyone
is willing to support so that it can replace the need for a portable
file format based on VCD.

I don't think most people understand the difficulties involved in
extending the VCD to support all of SystemVerilog. It's not so much the
actual dumping of value data during the simulation, but the description
of what you are dumping that is the real challenge for an ASCII dump
file, and any tool that would need to read it.

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Bassam Tabbara
> Sent: Tuesday, October 02, 2007 6:33 PM
> To: Maidment, Matthew R; sv-cc@server.eda.org
> Cc: sv-bc@server.eda.org
> Subject: [sv-bc] RE: [sv-cc] Read API
> 
> 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.
> 


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