Subject: Re: Coverage API requirements
From: Alain Raynaud (alain@tensilica.com)
Date: Tue Aug 20 2002 - 16:20:40 PDT
[about merging tests before extracting coverage results]
> You're correct that coverage is different from most other APIs in that full
> information
> does not typically come from a single simulation but is instead an
> aggregate of many simulation runs. This is an area that often is not
> part of the simulation API but is specific to a given coverage toolset.
> I am not sure how this fits within the tasks defined for this committee. Yatin ?
>
During the conference call today, some concerns were expressed about
supporting the API on a merged coverage database. First of all, I don't
see why a coverage tool could not implement whatever API we define for
reporting coverage.
In your document, requirements #5, #7, #8 seem to be independent of a
current simulation context. Therefore, a merge tool could implement
these APIs. What we may not want to implement is an API that lets you
manipulate which tests to merge or not merge, on demand, as this may may
be very dependent on the merged database format.
So to summarize, as a customer I don't see much use in a coverage API if
I can't access merged results. What is not clear to me is how an EDA
company can use the proposed coverage API. This brings me to a related
question. Let's say I'm simulating with classicSim, which has some basic
coverage functionality, and supports the coverage API. Let's say somehow
I include a better/newer coverage tool (through PLI :-) called
superCover. What happens when I call the coverage API and query for
available coverage? Will there be some mechanism to let tools register
what's available, so that I will see both the standard coverage objects
that classicSim supports, as well the objects of superCover?
I guess it would be useful for my understanding if some examples of each
API's potential use could be presented.
Alain Raynaud
Tensilica, Inc.
This archive was generated by hypermail 2b28 : Tue Aug 20 2002 - 16:22:51 PDT