RE: Updated slideset

Duaine, Brian,

 

Time has not permitted me to provide some feedback on two slides in
Duaine's presentation (14 & 16). I'd like to make two comments.

 

Slide 14 - I'll call it the buckets slide

 

*       Based on these goals, at least 4 activity areas have been
suggested.  

*       Interface

*       Modeling

*       Compliance

*       Debug

*       Other?

 

I would like to make few suggestions

 

a)       Remove the compliance requirements from this list and place it
as a separate operational objective.  Any industry standard requires
means for users and implementor to check compliance against the standard
and we all seem to have agreed with this objective today, but not about
the time frame to meeting it.

 

b)       When going through the exercise of "bucketizing" the issues I
raised a week ago, I found out that the "Other Bucket" actually doesn't
exist. All my issues (effecting verification IP portability, ease of
modeling and usability) can be resolved within the context of Interface,
Modeling and Debug buckets. However some tend to be dependent on a
combination of the 2 or sometimes 3 buckets.  As an example, transaction
recording has a small interface attribute (obtaining correct cycle stamp
at transaction start/end time), modeling attributes (how to model
logging/recording) and debug attribute.  A second example is "Provide
HVL native API support" that has interface and modeling attributes. 

 

To summarize, I see only three areas (Interface, Modeling and Debug)
that are required to address all the verification IP portability, ease
of modeling and usability issues.

 

A possible rephrasing of this slide would be

 

*       Based on these goals, the main areas have been suggested (to be
addressed in coordination) are:

*       Interface

*       Modeling

*       Debug

 

Slide 16 - The modeling slide

 

I think that this slide limits the modeling issues to the hardware side
dealing with "acceleration subset", but doesn't deal with modeling
implications on the software (HVL) side which is highly language
fragmented. If we agree that a transactor is a composition of sw side
and hw side partitions, we should address the software side issues as
well while not impeding on the language neutrality of the SCE-MI
interface.  I thus think that the modeling activity should encompass
both sides as a language neutral interface alone is not sufficient for
the creation of portable transactors across simulation and emulation on
all implementations. 

 

Last to be clear, I don't think that creating a common standard for
transaction recording/logging is urgent. The only urgency is for the
SCE-MI interface to provide standard means for transactors to obtain
transaction 'start time' and' end time' in order to convey it to the end
use. This requirement is totally independent from transaction level
viewing. Once the above is accomplished in the SCE-MI 2.0 time frame,
debug discussion could follow SCE-MI 2.0 release or maybe start once
SCE-MI 2.0 spec has solidified.

 

Thanks,

 

Shabtay  

 

 

 

 

 

________________________________

From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Pryor,
Duaine
Sent: Wednesday, March 30, 2005 3:58 PM
To: itc@eda.org
Cc: Evans, Jeff; Stickley, John
Subject: Updated slideset

 

ITC Team,

There have been a number of good comments related to itc goals,
strategies and tactics.

    I've tried to capture the comments and suggestions as much as
possible in the slideset.  There seems to be good consensus through
slide 14.  There seems to be good consensus on slide 15 as well, around
interface work.  My opinion was that the Zaiq suggestion around
clarifying the extent of backwards compatibility had broad consensus
support, so I added it to the slideset.  We can discuss it further if
necessary.  That change is on slide 13.

 

    The remainder of  the slides, starting with slide 16 seems to
require some further discussion.  I've outlined what I see as the
discussion items below.

    There seems to be a good deal of discussion around slide 16, on
activities around modeling constructs.

    In particular, 

        Aptix has indicated that they do not want ITC do that kind of
work.

        Axis/Verisity/(Cadence?) has indicated that they don't want that
work done in ITC or another forum.

        Axis/Verisity/(Cadence?) proposed compliance assurance
activities, so I've added that as a discussion item on slide 17.

        Mentor also believes that the providing a means of assuring
compliance is important and would like to be sure that we go about it in
the most expedient, effective and collaborative way.

 

For discussion, I've also added the debug activities suggested by
Cadence on slide 18 and left open an Other slide at the end.

 

Duaine