Subject: Re: Discussion about Coverage Donation
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Oct 22 2002 - 08:17:44 PDT
Some comments interspersed. I think I start to understand how you do coverage, hope you start to understand why I am having concerns here ...
Best regards,
Michael
Joao.Geada@synopsys.com wrote:
> 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.
Yes, but at the end these tasks need to be defined somewhere ...
> 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.
Yeees. My point is that it is/will be a runtime benefit, if the coverage collection is limited to the modules/instances where data is being requested for. As such it is preferable to control this coverage collection from a source that is under control of
the SV
compiler. The corresponding function of the C side of the API has the same/or similar capabilities, which might lead to include _additional_ modules/instances to the collection of coverage information. If this is the case then there is no chance for the
above
optimizations, which I would like to avoid.
So I have no problem with controlling the collection of coverage data from the C side, but this must be limited to the amount of modules/instances enabled at the SV side. That's my point. This does not get clear from your donation document.
I am not sure, but currently it sounds like your implementation is either enabled to gather coverage info or disabled to collect this info. Then the control option starts to steer where it is actually desired to collect this information. My concern just
tries to
not prohibit more intelligent solutions...
> 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)
Again, as said above; in the world of compiled simulation IP it might be desirable to prune the need for collecting coverage data even further ...
> 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.
Understood and never requested, besides the only one thing of having a 0/n instead of 0/1 result giving me much more insight about what's going on.
> ==============================================================================
> 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
> ==============================================================================
----
NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, ASA Methodology | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
*** This note may contain Motorola Confidential Proprietary or Motorola 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! ***
This archive was generated by hypermail 2b28 : Tue Oct 22 2002 - 08:26:01 PDT