Subject: Re: Discussion about Coverage Donation
From: Alain Raynaud (alain@tensilica.com)
Date: Fri Oct 18 2002 - 15:27:23 PDT
Overall, I think this donation is a good starting point and should be
approved.
I'd like to clarify the point I made during the conference call,
regarding making this coverage API even more generalized and flexible.
I stated that, as is, the API implicitly forces a certain model of FSMs,
which is not extensible. I believe that certain changes to the API would
not make it more complicated to use, but would make it more powerful.
For instance, instead of having enums to describe coverage types
(`CM_TOGGLE, `CM_FSM, etc...), use strings. Call
$cm_coverage("cm_toggle") instead of $cm_coverage(`CM_TOGGLE). Why is
that more practical? Because it allows for easy extensions. I propose we
add a call that returns all the currently available coverage types. Now
you see why using strings insteads of enums is important: if a number is
returned, the customer (writing the API calls) can't make sense of it.
Say a new coverage tool added a new coverage type: knowing that the
coverage type "multicycle fsm" is available tells me more than knowing
that 0x6 is available.
The same principle can then be applied to detailed extraction of data,
by using hash tables on strings. Instead of the function
$cm_fsm_get_statevar, you should be able to query the "fsm" coverage
type with a list of possible attributes, one of them being "statevar".
Such a scheme would allow for future expansion. For instance, new tools
could report more detailed coverage on multi-cycle FSMs. Or the statevar
construct may not be enough to describe the state variable in every
case. With the proposed scheme, extensions could easily be added, and
would also still be backward-compatible. You could have both the
attributes "statevar" and "extended statevar" attached to the same FSM
coverage object.
One could argue that even the limit and current values of coverage
should be accessed this way.
My whole point is that instead of hardcoding function names for a small
subset of coverage objects we can think of today, we should build a
flexible API that will let you query coverage properties independently
of the underlying coverage metrics.
The main objection to this structure is performance: it is faster for an
API implementation to switch and jump to the correct data structure
based on a number rather than a string. But I think we can find workable
solutions to that problem. I won't discuss those yet to keep the
discussion focused.
Alain Raynaud
Tensilica, Inc.
This archive was generated by hypermail 2b28 : Fri Oct 18 2002 - 15:31:51 PDT