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

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

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

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.

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

johnS:
We've been able to demonstrate that streaming and reactive operation
can be intermixed at virtually no impact to performance.

It is possible to use the reactive DPI interface to monitor
activity from S/W even when reading on a pipe. For example, an
exported function call can announce arrival of an input
message from S/W to an always block in the transactor. In this
sense the type of polling you're talking about can be supported
deterministically.

In order to insure determinism, the Mentor DPI proposal restricts
the use of polling on the pipe interfaces on the H/W side.
However it supports polling using the reactive (function
import/export) interface to guarantee determinism.

However, for the pipe interface, you have to be very careful when
you speak of polling in controlled time on the hardware side over
transaction pipe as it can easily lead to non-deterministic behavior.
SCE-MI 1.1 is very prone to this vulnerability.

This said, polling semantics on the SystemC side of say a TLM-DPI
conduit appears to be quite feasible (i.e. tlm_put_if::nb_put(),
tlm_put_if::nb_can_put(), tlm_get_if::nb_get(), tlm_get_if::nb_can_get()).

Incidently, one of the things that is not yet clear to us in
the Cadence proposal is how polling on their SceMiVarMessageInPort's
can be done determinstically especially if streaming is enabled.
If reactivity controls are enforced, then it would be deterministic
but if streaming and overlapped execution between S/W and H/W
are enabled, it would seem to us that determinism is lost.

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

johnS:

I think you are talking about basic support for 0-time operations
on messages between clocks.

I have 2 comments about this.

1. As you say, for specialized cases that require this using an
    uncontrolled time based approach, you can always write a
    SCE-MI 1.1 transactor.

2. Beyond this, if you're writing the transactors only in controlled
    time as is the basic use model and intent of the SCE-MI 2 requirements,
    to really have this discussion we believe you have to consider modeling
    subset. Consider the problem you're trying to solve. As a user, you want
    to deal only with controlled time, yet, you're trying to perform some
    iterative sequential operation in 0-time - say between clocks.

    This is fundamentally difficult to do in synchronous RTL that only
    uses controlled clocks with either proposal.

    However, if the modeling subset supports something like data dependent
    loops in 0-time - which goes beyond RTL, there is nothing in the
    DPI interface itself that prevents this type of use of the interface.

    By contrast, using a macro based approach where the macros are
    clocked by controlled clocks, it is fundamentally impossible
    to do 0-time message post-processing in the same clock cycle
    in which the message is received. Post processing would have to
    be deferred until the next clock at the earliest.

A related topic to this is multiple messages in 0-time. This has
some of the same characteristics as 0-time message post-processing.
Again it really an issue more of what modeling subset the implementor
wishes to support. There is nothing in the current Mentor DPI interface
proposal that precludes multiple message transfers in 0-time so long
as the modeling subset supports it. This is in stark contrast to a
macro based approach that drives macros with a controlled clock. It
is fundamentally impossible to perform multiple message transfers
in 0-time with this approach.

Please see section 3.4 of my latest proposal revision update for a
more detailed discussion of this.

Another way to think of this is to ask yourself the question,
"how would I do this in a S/W simulation interface ?". Is there
a reason we need "uncontrolled time" in S/W simulators ? No, there never
has been. There is a notion of "delta cycles", but no uncontrolled
time. And even delta cycles are largely hidden from user
consciousness. So, similarly we should provide an interface where,
assuming the modeling subset supports it, it is possible to do
multiple operations in 0-time without the user having to think about
"stopping the clock".

Realistically speaking, in the shorter term you may not see implementations
supporting modeling subsets that support 0-time ops on emulation platforms.
However, that is not to say that it cannot happen in the future.

And if it does, the SCE-MI 2 interface definition should scale
to allow for the possibility of that type of operation.

In conclusion, I think this issue really has more to do with
supported modeling subsets than with the API itself. But,
I reiterate, let us not design the API in such a way that will
fundmentally prevent scaling to more sophisticated modeling subsets
in the future.

-- johnS
<eom>

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

-- 

This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies tion Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________