RE: ITC Meeting Minutes for May 26th

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
benefical impact of a modeling simplification must not kill the previous
modeling effort.

* 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.

- Others:
* Positive impact on performance: The concept (whatever the final
implementation) of data shaping appears as interesting for streaming (and
variable lengh messaging) performance optimization (depending on actual fifo
sizes and synchronization mechanism).

* Very negative impact on performance: There is a need to have also
non-blocking mechanism, eg. when the HW has to run but also to react to a
message received from the SW. In this case, an  implementation using a
polling via a blocking mechanism, will completely suppress the expected
performance from a transactional interface. If in order to preserve the
performance, we have to perform complex transformations on the transactors,
then we will loose in term of simplification of the modeling.

* Loss in term of modeling capabilities or facility: currently the use of
control clock mechanism allow us to process data within the transactor
before or after the message passing whatever the number of clock cycles
which are required by the implementation. This is simply due to the fact
that in the transactor control we can decide to stop the cclock if necessary
for processing the data. If the zero-delay operations are now only attached
to data transfers and no more to a transactor control, then this restrains
all the architectures which can be used when data processing is to be
performed within a transactor. This will not simplify at all the modeling
and can also prevent some data processing modeling. This is another reason
why the compatibility with scemi 1.x is also an essential requirement.
Allowing both a control + data synchronization should be the best in term of
modeling capabilities for the new SCEMI interface. Note that the control
clock + PCI like interface was doing that in SCEMI 1.x.

Best regards,

Joseph BULONE
HW Emulation manager

PS: if I cannot join you during the meetings, please do no hesitate to send
me any questions.

-----Original Message-----
From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Deneault,
Damian
Sent: Wednesday, June 01, 2005 4:47 PM
To: 'itc@eda.org'
Subject: ITC Meeting Minutes for May 26th



ITC Meeting Minutes for May 26th

Attendees

Duaine Pryor - Mentor
John Stickley - Mentor
Jeff Evans - Mentor
Matt Kopser - Cadence
Richard Newell - Aptix
Damian Deneault - Zaiq
Per Bojsen - Zaiq
Tom Peng - Zaiq
Jason Rothfuss - Cadence
Russ Vreeland - Broadcom
Sanjay Sawant - Tharas
Donald Cramb - Tharas
Bryan Sniderman - ATI
Edmund Fong - ATI

Activity

The Mentor proposal was discussed further, both addressing individual
questions raised and exploring it in general. Topics included:
- the mixing of old (SCEMI 1.x) models with DPI based models, how to
understand any interaction between them, what interaction is or 
isn't allowed, and whether reducing allowed interaction would be a good
simplification. John S promised written document or example clarifying
interaction and the retained elements of SCEMI 1.x
- existence of uncontrolled time with uncontrolled time, how to handle it in
the Mentor proposal, and whether the correlating questions exist with the
Cadence proposal
- the current precision of the combination DPI spec plus Mentor proposal for
non System Verilog language/RTL combinations
- a previous request was repeated for a complete example

Cadence plans to deliver a written document to explain or rebut some
comments on their proposal. This should be posted or emailed and then
followed up with discussion.

The idea of a compromise or merged proposal was raised by Richard N, 
and anyone is invited to come in with ideas for that at the next meeting.

In order to plan the evaluation and decision process, Damian requested that
all participants come to the next meeting with their input on 
what specifically they feel should be discussed, explored or clarified
before we can come to a decision or vote. We will try to lay out the
remaining decision process and timeline at the next meeting.

The next meeting is Thursday 6/2 at the usual 12pm/9am time.

Action Items

1. Cadence (Matt K) will post a written response document, before 
the 6/2 meeting.

2. Mentor (John S) will provide a document clarifying the portions of SCEMI
1.x that are retained as part of the DPI based proposal, prior to the 6/2
meeting.

3. Mentor (John S) will provide a complete example.

4. All participants come prepared to identify remaing discussion or
evaluation tasks at the 6/2 meeting.