RE: Use model and compliance

Per, John, Brian, Jason

Few comments embodied.

>-----Original Message-----
>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per
Bojsen
>Sent: Thursday, January 04, 2007 10:07 AM
>To: itc@eda.org
>Subject: Re: Use model and compliance
>
>Hi Brian, Shabtay, and John,
>
>you have some good comments.  My main concern is the labelling
>of the subsets as SCE-MI 1 (or SCE-MI 1.1) and SCE-MI 2.  This
>can lead to the at best imprecise and at worst wrong impression
>that SCE-MI 2.x is purely DPI.  
[Shabtay] I agree with Per that associating SCE-MI 2 use model with the
DPI subset is indeed imprecise.  I thus suggested that we decouple the
use model naming issue from the DPI subset issue.

If we do that the paragraph can only focus on the DPI subset issue where
we seem to have an agreement on what we want to convey and separately
deal with whether the terms SCE-MI 1 and SCE-MI 2 use models are
appropriate and need to be changed.


>I also like the labels Brian
>came up with (message passing and function call) and agree with
>John that we should be using them instead of SCE-MI 1.x and
>SCE-MI 2.x.  After all, they are both part of SCE-MI 2 and
>it is not even correct to say that the message passing subset
>is equivalent to SCE-MI 1.1 as it has been updated since SCE-MI 1.1.
>That is, if one restricted oneself to the message passing subset
>of SCE-MI 2.x, it is not guarenteed that the application will
>be portable to a strict SCE-MI 1.1 implementation.
[Shabtay] While the names SCE-MI 1 and SCE-MI 2 use models are not
ideal, they still convey that these two use models are quite
distinctive. I have some reservations about the proposed "message
passing" vs. "functional call" use models because these are simply not
mutually exclusive. On the SW side, both use models call a function and
both use models exchanges massages which is defined by SCE-MI 1.1 as "a
data unit of arbitrary size an abstraction to be transformed over a
channel". Scemi pipes which are part of the SCEMI 2 use model also
convey messages by this definition and so does DPI to my understand of a
message definition. 

The key differences between the two use models are the means by which
messages are conveyed (mainly on the HDL side) and thus I would suggest
that we either 

a. Stick with the term SCEMI 1 and SCEMI 2 use models
b. Find more suitable terms that clearly distinguish between the use
models. 

Given where we are we may use SCEMI 1 and SCEMI 2 use models as place
holders and revisit the terms in SCE-MI 2.1. Given that SCE-MI 2.0 is a
draft we are allowed to make a change in this area moving forward.

>
>Another issue that John hints at is the issue of what does it
>mean for a model to be compliant with the standard.  I am not
>sure we can fully define that as we have not restricted and
>defined the modelling subset.  This means that although a model
>may use the SCE-MI API in a compliant way it is still not
>guaranteed to be portable to another compliant implementation
>as it may be using features outside of the SCE-MI API that
>are not portable, e.g., language constructs that are only
>synthesizable on some platforms.
[Shabtay] I think we all agree that making a model compliant with an
interface does not make it portable. But this would be stating the
obvious. I thus proposed that we focus on the DPI subset issue which I
tried to capture in my alternative phrasing.
>
>Also, I am not happy with the distinction between the message
>passing and function call interfaces in terms of the leeway
>an implementation is given for implementing it and adding
>extensions.  Quoting from Brian:
>
>   With the message passing use model, all implementations must
>   implement each and every feature of the standard in order to
>   be deemed compliant with the standard.
>
>My point is that this is true of the *whole* standard.  You
>must implement all features of the standard to be compliant.
>There are no optional features.  
[Shabtay]  I agree and this is again stating the obvious and should not
be mentioned in the clarification.

There are areas that have
>undefined behavior especially in the function call subset,
>but that is different.
>
>So the question is this in my mind: is an implementation
>that includes extensions still compliant?  In some sense
>this is meaningless since we have no way of checking this.
>Even if we had a compliance test suite we would be in trouble
>unless the test suite was extremely clever.  I think it is
>not possible in the extreme since you cannot think of every
>possible extension and check that it is *not* implemented.
[Shabtay] This last paragraph from Per is at the essences of the issue
which I agree with. 

I'd like distinguish between the following two issues:

a. Adding extensions in general - I agree with Per that this is not
technically enforceable and thus SCE-MI 2.0 (and the paragraph) should
in my opinion stay away from this topic. 

b. Extensions which are part of the SV DPI, but beyond the minimal set
required my SCE-MI 2.0.

For the latest, we have to admit that SCE-MI 2.0 only defines the
minimal subset that must be supported on all SCE-MI 2.0 complaint
engines but does not prohibit different engines to implement more of the
DPI SV features beyond the SCE-MI 2.0 mandated subset. Furthermore,
implementing more SV DPI features (over the subset) w/o providing
warnings or errors does not make the implementation non SCE-MI 2.0
compliant.

While we have our differences if this is a major or a minor issue, I
think we only need to simply convey this simple fact. If you agree let
me suggest that you review the wording in my proposal leaving aside for
now the use model terminology which I believe we agreed to handle
separately.

Here is it again:

"SCE-MI provides two primary mechanisms for connecting a model written
in HDL to a model running on a workstation. The earlier one is known as
the SCE-MI 1 use model and the later one is known as the SCE-MI 2 use
model that includes as sub-set of the SystemVerilog DPI standard. 

However, while the ideal would be for the emulator to support all of the
features of the SystemVerilog DPI standard, this is not possible due to
mainly technical reasons. The standard thus defines the minimum set of
features of the SystemVerilog DPI standard that should be supported to
be deemed SCE-MI 2.0 compliant, but each and every vendor is free to add
additional features to their interface as long as these are supported by
SystemVerilog DPI. 

This also presents some challenge to a SCE-MI 2.0 compliant model. To be
SCE-MI 2.0 compliant, the model should only utilize the features defined
the SCE-MI 2.0 standard meaning that any additional SystemVerilog DPI
features assumed to be available by a specific implementation makes the
model non-compliant with SCE-MI 2.0 and thus potentially non-portable to
other SCE-MI 2.0 implementations. In particular a model that uses any of
the SystemVerilog DPI features beyond those supported in SCE-MI 2.0 may
work in simulation mode but may break in emulation mode. It is also
important to note that SCE-MI 2.0 compliant implementations are not
required to flag an error or warning when models use any features in
SystemVerilog DPI beyond the SCE-MI 2.0 DPI subset defined in SCE-MI 2,
but may present undefined behavior in this case."


>
>Per
>
>
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.