RE: ITC Meeting Minutes for May 26th

John,

Comments regarding a few of your responses to my/Shabtay's emails.
Most of my comments refer back to my original post from 6/17/05,
with the subject line: "Clarification Questions, RE:Mentor-Proposed
SCE-MI 2.0".  In that email, I enumerated 16 issues that we'd like
clarified.  Looking forward to responses to that email.

I expect your responses to that email will address most of the issues
noted below.  Pardon the reiteration of some of those questions in
my comments below.  (New comments from me are delimited below with
'[Matt2]'.)

Matt 

-----Original Message-----
From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of John
Stickley
Sent: Monday, June 20, 2005 11:07 PM
To: 'itc@eda.org'
Subject: 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 ...

<<< Lot's of stuff deleted >>>

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.

[Matt2] The blocking semantics on the HDL side of the pipes require
that the software side be a threaded environment, in order for the C
side to be 'automatically yield to'.  This issue is noted in question
5 on the previous email.

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.

[Matt2] Multiple messages can be transferred in 0-time in SCE-MI 1.1
and the Cadence proposal for SCE-MI 2.0 (See issue 9 in the previous
email.)

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

[Matt2] The macro-based approach can also work with such extensions to
the modeling subset.  In previous ITC discussions it was agreed that,
in order to ensure compatibility with 1.1 SCE-MI constructs, DPI-based
SCE-MI 2.0 calls should be made 'on controlled clock edges', or 'as a
result of' controlled clock edges.  Given this fact, both the DPI-based
proposal and the macro-based proposal transfer message data as a result
of controlled clock edges.  Data-dependent 0-time loops can operate on
data transferred via either mechanism.  (Also see issue 15 in the
previous email, which is related to this topic.)

[Matt2] I would agree that the function-call mechanism may be a bit
easier to use in this case, but the use of extended modeling
capabilities
is not precluded by the macro-based approach.

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
________________________________________________________________