Re: ITC Meeting Minutes for May 26th

Shabtay and Matt,

I've paraphrased your responses to Joseph's e-mail thread
and commented on them briefly below ...

Shabtay Matalon wrote:
> [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.

johnS:
I was talking specifically about bridging from OSCI TLM-API to HDL through 
DPI.  This takes advantage of standards work that has already been done and 
provides threading through System C. DPI works well in other threaded 
environments as well.

Shabtay Matalon wrote:
> 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?

johnS:
The beauty of the TLM-API approach is that it essentially allows
removal of the proxy altogether and replacement of it with a TLM
channel directly from the TB to the HDL transactor, through its
sophisticated use of parametrized transaction types. This was
somewhat illustrated in one of the slides accompanying our proposal
(see "possible implementation layers-emulator platform" slide).
In this case the "proxy" is more or less reusable C++ template code
that implements a channel, not companion model the user must create a
distinct version of to accompany each HDL transactor type.

Shabtay Matalon wrote:
> 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.

johnS:
My earlier e-mail suggested that both blocking and non-blocking interfaces
can be supported on the S/W side of the API - basically fulfillment of
interfaces such as the OSCI TLM-API standard interface method calls,
tlm_put_if::put(), tlm_put_if::nb_put(), tlm_get_if::get(), and
tlm_get_if::nb_get().

My comment was that with pre-implemented DPI pipes, implementation of
these methods tends to be easier than dealing directly with callbacks
and surrounding application code that must deal explicitly with the
threading layer.

Bear in mind that DPI pipes as proposed can, as one possibility,
be implemented as a simple C code library over a base compliant DPI
facility.

This C-code library is where thread interfacing code tailored to a
specific threading environment can be encapsulated. But this can be
a one-time reusable implementation that can be provided by the implementor
rather than something that has to be done separately for each application
proxy model that is implemented using callbacks.

Matt Kopser wrote:
> [Matt] John, you state that, with the Mentor-proposed pipe mechanism,
> 'you have to be very careful...'.  And you state that SCE-MI 1.1 is
> 'very prone to...'  Are you saying that, in both cases, deterministic
> behavior is up to the user and/or IP modeler to ensure?

johnS:
What I was saying is that for any streaming interface you
have to be very careful when allowing polling on the H/W side - which
the SceMiVarMessageInPort macros appear to do. Specifically the
Mentor pipe proposal, does not allow polling on the H/W side,
so as to ensure H/W side determinism.

As for, SCE-MI 1.1, by giving the user explicit control of the clock,
makes it very easy to write transactors that do not guarantee
determinism.

Both proposals get around this SCE-MI 1.1 limitation by hiding clock control.

Matt Kopser wrote:
> [Matt] This scenario (hardware-side-polling on a SceMiVarMessageInPort,
> in streaming mode) is analogous to (as you stated above), hardware-side
> polling over the proposed transaction pipes.  In both cases, the IP
> provider and/or user must ultimately ensure determinism.

johnS:
There is a key difference here.

If I understand you correctly you're agreeing that SceMiVarMessageInPorts
require the IP provider and/or user to ultimately ensure determinism
(which makes sense as it is a polling interface).

By contrast, transaction pipe reads from HDL occur in zero time and
block the calling process. This ensures determinism.

What this means is that when a transaction pipe is read, it blocks the 
calling process until data arrives. If the pipe is starved, the C side will 
automatically be yielded to, to replenish it (similar to blocking read
in the Unix socket model). The net effect is that a pipe read (or write) 
obtains (or sends) data within the cycle during which the operation is 
applied.

Therefore such ops will always occur on the same clock from
sim to sim, therefore determinism is guaranteed. There is no
handshake that says data may or may not be there in a given clock
as with the SceMiVarMessageInPort.

Such handshakes open the possibility for non-deterministic streaming.

By contrast the blocking pipe semantics that we propose for the HDL
side make non-determinism impossible, all while still supporting streaming.

Matt Kopser wrote:
> [Matt] If the Cadence-proposed macros are used in reactive mode, then
> deterministic behavior is achieved.  With the Mentor-proposed pipe
> mechanism (it appears) that it is up to the IP provider and/or end
> user to explicitly flush pipes on the software side to ensure reactive/
> deterministic behavior.  (Cadence has asked for clarification on how
> the flush mechanism and threading considerations are expected to work
> in the Mentor proposal -- clarification of these questions would help
> in this area.)

johnS:
The workhorse reactive interface that we propose is nothing more than
DPI imported/exported function call interface as per the existing
standard. By definition this interface is guaranteed reactive.

Because DPI pipes can be easily built on top of the existing standard
DPI interface (say as a C-code library described above), the implementor
can choose to implement reactively as well.

Or, they can choose to provide an optimized builtin implementation
of pipes that leverages concurrency.

Either implementation need not change the functionality of the pipe.

And, as I explained in detail above, whether they are pipes concurrent
execution underneath or whether fully reactive, the H/W side remains
deterministic in either case.

Matt Kopser wrote:
> [Matt] You mean to say, using a macro-based approach, and a restricted
> finite-state-machine-restricted modeling style makes is near impossible
> to do 0-time message post-processing in the same clock cycle..., right?
> Cadence has touched on this with regard to the contents of Appendix A
> of the Mentor proposal -- there is an assumption that the DPI-based
> approach allows use of an extended modeling style whereas the macro-
> based SCE-MI 1.1 (and Cadence-proposed 2.0) do not.  This is a mis-
> characterization of the facts, IMO.

johnS:
Actually I'm not trying to mis-characterize facts. I recognize
that both proposals can support the example in Appendix A. This
is because the example in appendix A only attempts to read/write
1 message per clock and attempts no 0-time post processing ops -
which both proposals handle with no issues.

What I was saying will not fundamentally work with the controlled clock
driven macro based approach, are multiple messages in 0-time
(see section 3.4 of our proposal) or 0-time transaction post-processing
operations (of the type pointed out by Joseph) that might occur in
data dependent 0-time loops within the same clock period as
the message is received.

By contrast, there is nothing in DPI that precludes such
extensions to the modeling subset.

But neither of these cases are shown in appendix A so I'm not
disputing that both proposals can handle this example.

-- johnS
<eom>

______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________