SCE-MI Action: Consolidated list of issues for discussion

Greetings ITC Techies,

As per my action, here is the consolidated list.
It was easiest to take Matt's consolidated list (with his and Per's
lists combined) and add my stuff in there.

-- johnS

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

JohnS added:
 >    b) Is current comment based pragma syntax attributing scheme adequte
 >       for Verliog, VHDL ?
 >       - Specifically for VHDL should we explore using attributes
 >         instead ?

   2) Function arg data type subset - that spans the 3 languages
      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?

JohnS added:
 >    c) Additional considerations regarding arg data types:
 >    d) How are integer representations reconciled on different
 >       machine architectures (32 bit vs. 64 bit)
 >       - Take guidance from SystemVerilog standard here
 >    e) Consider support for SV chandle type
 >    f) Clarify use of string types over the 3 languages

| 3) DPI call restrictions
      a) Whether there should be any restrictions on DPI functions
         calling each other.
|    b) Whether imported/exported tasks are supported
|    c) Is 'context' keyword required for imported functions ?

JohnS added:
 >    d) What degrees of recursion can you call imports from exports,
 >       exports from imports, etc ?
 >       - Lets keep it limited at first
 >       - Mentor suggests Russ's proposal as a starting point

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

JohnS added:
 >    c) Clarify how cycle stamp handling is done in SCE-MI 2
 >    d) Clarify how separation of external clock specifications
 >       from internals of transactor models leads to portability
 >       to DPI compliant simulators

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

JohnS added:
 >    a) Clarify how separation of these calls from internals of proxy
 >       models leads to portability among DPI compliant simulators

   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

johnS added:
 > 11) Issues surrounding macro semantics and compatibility
 >     with function semantics and guaranteed determinism
 >     for streaming

Per added:
 > 12) Ironing out the details of the transaction pipes with respect
 >     to batching/streaming, VLMs, and zero- versus non-zero-time
 >     delivery of messages.

-- johnS

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