RE: ITC Meeting Minutes for May 26th

From: Russell Vreeland <vreeland_at_.....>
Date: Wed Jun 22 2005 - 11:42:11 PDT
It has been pointed out to me that Matt meant only the actual "call" of a
DPI function
should be made on controlled clock edges. No problem with that.

I misread it to mean that the infrastructure generated should be synchronous
using
controlled clock as well (I think the 'or' threw me off)

Sorry. I'll slow down and read more carefully.

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



> -----Original Message-----
> From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf 
> Of Russell Vreeland
> Sent: Wednesday, June 22, 2005 11:08 AM
> 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.)
> > 
> 
> Whoa! I remember nothing in ITC discussions where it was 
> agreed that DPI-based calls should be made 'on controlled 
> clock edges'. In fact I'm very technically interested how 
> processor-based technologies (Xtreme,
> Hammer)
> might forego any clock based infrastructure creation entirely.
> 
> 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.
> 
> 
> ---------------------------------------
> ---    Russ Vreeland (949)926-6143  ---
> ---    vreeland@broadcom.com        ---
> ---    Senior Principal Engineer    ---
> ---    Broadcom Corporation         ---
> ---------------------------------------
> 
> 
> 
Received on Wed Jun 22 11:42:20 2005

This archive was generated by hypermail 2.1.8 : Wed Jun 22 2005 - 11:42:21 PDT