RE: ITC Meeting Minutes for May 26th

Joseph, John,

 

There are few comments that I wanted to add to Matt's email. See my
comments below.

 

I'd appreciate your response.

 

Thanks,

 

Shabtay

 

>-----Original Message-----

>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of John

>Stickley

>Sent: Wednesday, June 15, 2005 12:47 PM

>To: Joseph BULONE; 'itc@eda.org'

>Subject: Re: ITC Meeting Minutes for May 26th

> 

>Joseph,

> 

>I've taken a stab at answering some of your queries at least from the
point

>of view of the Mentor proposal.

> 

>Joseph BULONE wrote:

>> Thanks a lot for the minutes of the ITC meeting I cannot
unfortunately

>> attend as often I would like. It is very helpful to keep track of all

>> the work and effort performed especially by the EDA vendors.

>> 

>> Here are the points, which appear as essential and critical for ST in

>> order to choose the "best" evolution to SCEMI 1.x :

>> 

>> - We need at least to be able to reuse all the amount of work

>> currently done around SCEMI 1.x, not to loose our investment we made

>> in SCEMI since our involvement in SCEMI (i.e. since the setup of this

>> standard). The following things are thus requested:

>> 

>> * 1.x transactors are to be reusable (same syntax and semantics

>> including the clock control mechanism) in concurrency with 2.x

>> transactors: the beneficial impact of a modeling simplification must

>> not kill the previous modeling effort.

> 

>johnS:

>This has been a primary requirement from the outset. It has clearly
been

>part of our agreed upon goals and is also addressed by both proposals.

 

 [Shabtay] John, I agree that both proposal address existing SCE-MI 1.1
models and even in quite a similar way.

 

Joseph,

 

Is your question only related to using the SCE-MI 1.1 transactors or
also to reusing the existing SCE-MI 1.1 modeling style and code? In this
regards the two proposals are different as the Cadence proposal keeps
the existing SCE-MI 1.1 style and the Mentor one changes it quite a bit.


 

How critical it is for you to maintain a similarity between SCE-MI 1.1
and 2.0 vs. moving to an entirely new API (such as DPI)?   

> 

>> 

>> * Our TLM/SC verification environment link to SCEMI needs to be

>> preserved by simply preserving a C++/C interface: eg. As 'Direct

>> Programming Interface

>> (DPI) enables it to "call" C/C++/SystemC functions, and vice versa',

>> then there should be a mean to define something completely
independent

>> from DPI, and if necessary we should standardize the integration with

>> DPI providing in a way the specification of a kind of DPI linker
tool.

>> In this case the DPI interface could be attached only to new

>> transactors, and for these transactors, the types definitions could
be

>imposed to be coherent with DPI.

> 

>johnS:

>If I understand your meaning here correctly, you would like to see a

>preservation of SystemC models that use TLM-API interfaces is that

>correct ?

> 

>If I further understand you've created some sort of conduits between
TLM

>and SCE-MI 1.1 that these models can use.

> 

>We've done some similar work investigating TLM-DPI conduits. My guess
is

>that this can preserve use of models that use such interfaces with no

>modification - at least that's been the case with some of the models
we've

>worked with.

> 

>These can coexist with TLM-SCEMI conduits and may want to consider

>standardizing both sets of interface extensions.

> 

>Furthermore, you may find that TLM-DPI conduits can be done more simply

>than what is required for SCE-MI 1.1 applications especially with the

>avoidance of the need for callbacks and dealing with uncontrolled time

[Shabtay] John, I assume that a conduit as you proposed is what I have
suggested as "HVL encapsulation layer" in the paper I sent out (pointed
by Matt's proposal - slide 11). This can be a layer that bridges between
the SCE-MI API (language neutral) and a language specific API such as
SystemC. Using blocking calls requires using some sort of a threading
package and I don't yet understand how you propose to support a blocking
call unless you assume in which threading environment you operate. The
idea of an encapsulation layer is that it does contain the HVL specific
threading environment. Please clarify if this is what you meant.

 

Based on my experience, there is also a need for proxy model in between
a TLM and SCE-MI API or between a TLM and the HVL encapsulation layer.
As a minimum, it needs to configure the BFM on the HW side. Are you
stating that a generic layer can be a replacement for a proxy model of
just an add-on?

 

We are not promoting use of controlled clock either in our proposal, but
can you explain what is the difficulty of creating blocking and non
blocking interfaces for the existing SCE-MI SW API? We have easily
implemented such an interface for SystemC based on the existing SCE-MI
callbacks.

> 

>> 

>> - Others:

>> * Positive impact on performance: The concept (whatever the final

>> implementation) of data shaping appears as interesting for streaming

>> (and variable length messaging) performance optimization (depending
on

>> actual fifo sizes and synchronization mechanism).

> 

>johnS:

>Yes, we agree that DPI pipes can have a positive impact on performance
by

>facilitating optimized implementation that allows overlapped execution

>between C/C++/SystemC code running on the workstation and the H/W

>simulation.

[Shabtay] We have proposed that SCE-MI defines a clear use model
assumption between alternating and concurrent modes to avoid portability
issues from simulation to acceleration and from one system to another.
Users who wish to use concurrent use model will have means to explicitly
state it. See issue 4 in the paper I submitted to the group. 

 

John, Joseph, 

 

Do you agree with that?