Expanded SCE-MI 2.0 Issues

Per, thanks for submitting your list to get things going.  I have
added to your list (additions are marked with change bars in the
left margin), primarily with open issues from Cadence's inquiry
from 6/17.  Most of our questions from that list are still working
points going forward.

Matt

-----Original Message-----
From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per
Bojsen
Sent: Thursday, July 14, 2005 9:59 AM
To: itc@eda.org
Subject: SCE-MI 2.0 Issues

Hi,

at the last meeting we agreed that we would start to collect issues that
need to be discussed as a part of the process of fleshing out the Mentor
proposal and turning it into a standard.  I have not seen anyone else
sending anything out, but here is my list:

  1) Firming up what we are going to do for Verilog and VHDL both
     relative to the Mentor proposal and Cadence's proposal for
     new macros.
|    a) How will context be handled in VHDL and 'vanilla' Verilog?
|       The user should not have to call SystemVerilog APIs to
|       access context information in non-SystemVerilog use models.

| 2) Data Types
     a) The list of data types supported in DPI calls.
|    b) How do software-side data types map to VHDL and 'vanilla'
|       Verilog on the hardware side?

| 3) DPI call restrictions
     a) Whether there should be any restrictions on DPI functions
        calling each other.
|    b) Whether imported/exported tasks are supported

| 4) Time
|    a) How is advancement of time tracked on the hardware side for DPI-
        only applications?
     b) SceMiClockPort in DPI-only applications.

  5) SceMi::Init(), SceMi::Version(), SceMi::Shutdown() in DPI-only
     applications.

  6) SceMiParameters: is this required in DPI-only applications?
     Do we need new attributes for DPI?

| 7) Mixed SCE-MI 1.1/2.0 usage
     a) Firming up the seams between the new DPI-based features and
        the SCE-MI 1.1 features: restrictions on mixing etc.
|    b) Initialization and Creset in 1.1 -- how can 2.0 models be made
        compatible with 1.1 models utilizing these mechanisms?

| 8) Compliance
     a) Deciding whether simulator support is required for a compliant
        implementation.
|    b) Must compliant simulator (and accelerator/emulator)
implementations
|       of SCE-MI 2.0 enforce and/or check for adherence to DPI type and
|       function call restrictions?

| 9) Streaming/Reactivity
|    a) Is it a goal to create a standard that allows the IP provider to
|       create transactors that do not need to know whether the system
or
|       the particular channel serving the transactor is
streaming/reactive?
|    b) How will the user control reactivity/streaming?

| 10) SCE-MI 2.0 Pipes - need to flesh out the recommended (required?)
use-
|     model and test architecture in which pipes work
|     a) Is pipe depth left up to vendors, or is this user-controlled?
|     b) What is a full pipe?
|     c) Threading requirements, flush mechanism, blocking semantics of
|        pipes, control flow in general
|     d) Development of a full example/tutorial


There is much more, I'm sure, but this is a start.

Thanks,
Per

-- 
Per Bojsen                                Email: <bojsen@zaiqtech.com>
Zaiq Technologies, Inc.                   WWW:   http://www.zaiqtech.com
78 Dragon Ct.                             Tel:   781 721 8229
Woburn, MA 01801                          Fax:   781 932 7488