RE: ITC Meeting Minutes for May 26th

Russ,

I'm up to '[Matt3]' now...

-----Original Message-----
From: Russell Vreeland [mailto:vreeland@broadcom.com] 
Sent: Wednesday, June 22, 2005 2:08 PM
To: Matt Kopser; 'John Stickley'; itc@eda.org
Cc: 'Donald J. Cramb'; Jason Rothfuss
Subject: RE: ITC Meeting Minutes for May 26th

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

[Russ] Whoa! I remember nothing in ITC discussions where it was agreed
that DPI-based calls should be made 'on controlled clock edges'.

[Matt3] The assertion was (and I believe it was Duaine who originally
stated it) that, in order for SCE-MI 1.1-based models to assert clock
control, and have SCE-MI 2.0 (DPI-based) models yield to this control,
the conditions under which the DPI-based models run should/would be
derived from controlled clocks.

This doesn't imply that DPI-based models would have to look something
like:

always @(posedge controlled_clk)
   <<make a DPI call>>

Rather, it is a statement that the conditions under which (SCE-MI 2.0)
DPI calls are made cannot be entirely independent of controlled clocks,
else attempts to utilize SCE-MI 2.0 and SCE-MI 1.0 models in a hetero-
geneous environment would not be possible.

If, on the other hand, DPI-based models do not need to be aware of
SCE-MI 1.0 controlled clocks at all, then the requirement of backward
compatibility and coexistence of SCE-MI 2.0 and SCE-MI 1.0 has no
meaning.  In other words, SCE-MI 2.0 becomes a separate standard that
does not support the stated backward compatibility requirements.

[Russ] In fact I'm very technically interested how processor-based
technologies (Xtreme,
Hammer)
might forego any clock based infrastructure creation entirely.

[Matt3] I am not sure we are talking at the same level here.  Can you
clarify this comment?  (See my next comment below.)

[Russ] In a mixed SCEMI 1.1 / SCEMI 2.0 environment, proper results
are what's important, not a low-level specification of how to implement
based on clock edges.

[Matt3] I am confused by your use of the word 'implement'.  If you are
referring to how a given vendor will implement the standard, I agree.
But if there is a need to model (either SCE-MI 1.1 or SCE-MI 2.0) BFMs
with specific requirements, so as to ensure compatibility, then the
specification should include such requirements on the user/model writer.
The existence of clocks that can be controlled explicitly by any SCE-MI
1.1 BFM means that the notion of these clocks must be recognized in the
context of compatibility.

Now, if a company, say Broadcom, is not interested in doing verification
in a mixed 1.1/2.0 environment, they might choose to disregard this
requirement in developing SCE-MI 2.0 models, knowing that they will not
inter-mix these models with SCE-MI 1.1 models that will perform clock
control.



---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------