Subject: Re: Coverage semantics
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Oct 22 2002 - 07:45:41 PDT
Joao,
thanks for this input. This is good stuff. I will add some comments to your proposals to show why I think this should be defined in a better way.
Regards,
Michael
Joao.Geada@synopsys.com wrote:
> To address Michael's and Bassam's points on the specific details of coverage
> semantics, I describe below specific proposed meanings to the limit & coverage
> numbers for line, toggle and assertion coverages.
>
> Line coverage:
> limit: total number of statements in the appropriate portion of the design.
> Statements in automatic tasks & dynamic processes are counted only once,
> regardless of how many concurrent invocations may exist at any one time.
> coverage: how many of the statements have been executed at least once
> Note that the granularity of this number is by block (set of statements that
> will execute in sequence with no change in control and without suspending for an event)
I take from your description that you talk about basic blocks (sorry, this is a term used by software, especially compiler guys for what you talk about in the granularity). So basically you will have 'basic block coverage' meaning such a block receives a
coverage of 1 when the set of statements contained in the basic block is executed at least once, else 0; is this correct?
In general I think the name and description is very misleading. From your description I see no relationship at all to lines (so why 'line coverage') and even a reference to the 'number of statements' is a misnomer; you are always looking at the set of
statements of one basic block.
> Toggle coverage:
> limit: total number of bits in register & wire signals in the appropriate part of the design
> (excluding arrays, but including vectors)
> coverage: how many of the bits have completely toggled (had both 0->1 transitions *and* 1->0 transitions)
> Granularity is 1 (1 additional bit completely toggled)
So this is a net toggle coverage. As already said, I can envision some more coverage types w.r.t., but fine this is the current state. I don't like two things here: a) Your definition just looks at 0->1 transitions, what about other states to 1 transitions
(e.g. z->1), so what happens in case of a 0->z->1 transition AND b) I would like to know even the lower granularity of <any>->1 as well as <anz>->0.
> Assertion coverage:
> limit: total number of assertions in the appropriate part of the design
> coverage: how many of those assertions have had at least once success
> Granularity is 1 (1 additional assertion had a first success)
What's this. Is this your condition coverage or is this a new one?
> In addition, Synopsys would be willing to add to our donation the FSM description
> pragmas and FSM description config file, which would enable any user, regardless of
> tool vendor to access coverage for those FSMs through the coverage API.
Sounds good.
IN GENERAL:
Besides the above concerns; would it be a major different to just return _how_often_ a statement has been covered? So you would have instead of just having a 0/1 case a 0/n case where n shows how often this basic block/toggle/... has been identified. I
doubt that this would be a big runtime difference, but it could be even more useful information ...
> ==============================================================================
> 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:06 PDT