Subject: Re: Discussion about Coverage Donation
From: Joao.Geada@synopsys.com
Date: Fri Oct 18 2002 - 09:25:46 PDT
michael.rohleder@motorola.com said:
> A1) This is probably a discussion where we should also include sv-bc/ec:
> This donation implicitely defines also some new SV keywords/commands
> ($cm_coverage, $cm_get_coverage, $cm_get_limit).
> Can we and how do we want to handle such additions?
>
Yes, the sv-ec committee should be informed. Strictly, these are not new keywords,
what they are new built-in system tasks.
michael.rohleder@motorola.com said:
> A2) Based upon our experience with PLI functions, I would like to hear some opinion about the abililty to start gathering coverage information from SystemVerilog _and_ from the C/C++ side. Since it is obvious that any instrumentation for gathering coverage
> information will require some effort, there will be for sure a performance drawback -- as a result coverage instrumentation will be for sure not the default.
> IMHO instrumentation from the SystemVerilog side is a must. The drawback is that a different instrumentation will require to recompile it, but this is very likely anyway the case. The corresponding coverage commands must not neccesarily be part of a
> specific source module and thus affect the souce code. On the other side this would permit to include the instrumentation in the compilation process, which might be important for the appropriate optimizations.
> Having the capability to start/stop the instrumentation from the C side might be a problem for this; without the knowledge which part of the design is to be instrumented during the compilation this might require some of the silly needs for user hints like
> learnpli ... This is something I would like to avoid under any circumstance. Has this been considered when defining this API. Any experiences here??? What are EDA vendors thinking here???
>
Actually, the API is not, by itself, capable of collecting coverage data.
It can request that the simulator start/stop collecting it *if that coverage
capability is available*. If the coverage capability requested is not available
the API will return `CM_NOCOV (coverage requested is not available)
The way we expect the flow to work (and the way it works on our tools) is as follows:
1- at design compilation time, the user informs the compiler as to which coverage
capabilities will be required at simulation time.
The compiler is then responsible for modifying and/or instrumenting the generated
code and/or linking in additional libraries as appropriate to permit the requested
coverage data to be collected.
Note that it is entirely implementation dependent how this data collection
will occur.
2- at simulation time, by default, coverage collection is *not enabled* unless
explicitly requested by the user, even if coverage capabilities were requested
at compilation time. This permits the user to always have coverage available
but only pay the collection costs if/when he needs the coverage data
Coverage collection can be enabled by
a) explicit command line option to the simulator
b) by use of the real time coverage control API
Using the API permits much finer grain control (both over the time that coverage
collection occurs and for the portion of the hierarchy for which it is collected)
michael.rohleder@motorola.com said:
> A3) I have the feeling the Coverage API is very, very focused on FSM's. Although this
> might be an important aspect of coverage data, other coverage aspects are also having
> their merits. I am trying to show some examples for this afterwards.
Note that this API is focused primarily on the requirements of reactive testbenches and
semi-formal verification environments. To this purpose it exposes, in a simple way, all
the data that can be readily used by those environments. No more, no less. We believe
that this ability to link behavior of testbenches & semi-formal tools is critical in
the next generation verification environments and this is the reason we have donated the
API.
As previously pointed out by Alain, this API does not provide access to detailed coverage
reporting, coverage DB manipulation and merging etc. These are capabilities usually provided by
a separate tool in a coverage driven environment and beyond the scope of the donated API.
Joao
==============================================================================
Joao Geada, PhD Principal Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
154 Crane Meadow Road, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
This archive was generated by hypermail 2b28 : Fri Oct 18 2002 - 09:29:41 PDT