Re: Use model and compliance

Hi Shabtay,

> 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 don't quite get what you're saying here.  What paragraph are you
talking about?  The first one of the two paragraphs Brian was
proposing?

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

The term `SCE-MI 2 use model' is misleading though precisely because
SCE-MI 2 includes the old SCE-MI 1.1 features.  It is much more precise
to say `function call use model' or even `DPI use model'.

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

Well, we can easily put that confusion to rest by providing a clear
definition of what we mean when we say `message passing use model' and
`function call use model'.  BTW, it may be useful to put pipes in
third category as there is a valid DPI use model that does not
use pipes.  This would be a use model that would work on any SystemVerilog
simulator without SCE-MI 2 support required.

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

I think the two terms proposed are suitable enough if they are
defined.

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

This seems like this ought to be a simple thing to fix, so why not do
it now?  It doesn't change anything in terms of what you have to
implement after all.

> [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 am not sure that is obvious.  But nevermind, my point was that
I am not sure the notion of a compliant model is well-defined and
we should avoid using it or at least define it clearly if possible.

> [Shabtay]  I agree and this is again stating the obvious and should not
> be mentioned in the clarification.

I don't agree that this is stating the obvious.  Brian had a
statement that in the message passing use model an implementation
is required to implement all features of the standard to be compliant.
Brian was implying that this is not true for the new features of
SCE-MI 2, i.e., an implementation does not have to implement all
of the new features in order to be SCE-MI 2.  My whole point here
is that I disagree with this.  An implementation has to implement
all the specified features to be compliant.

Also, very importantly, an implementation must implement *all* of
SCE-MI 2 to be SCE-MI 2 compliant, including the features inherited
from SCE-MI 1.1.  Thus, an out-of-the-box SystemVerilog simulator
is not automatically SCE-MI 2 compliant.

Do we want to have a notion of being compliant with the DPI subset
of SCE-MI 2?  This would allow off-the-shelf SystemVerilog simulators
to be declared SCE-MI 2 compliant as long as we do not require
errors/warnings on non-SCE-MI 2 DPI features.

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

This is an extension of the discussion between John and you.
Speaking as a user, I would find it unfortunate if there was no
way to lint my code for SCE-MI 2 compliance when testing it on a
simulator.  I would recommend that any vendor choosing to implement
SCE-MI 2 provide some sort of warning/error mechanism or linting
mechanism that could save users a lot of grief when they realize
they built a whole infrastructure over DPI features that are not
supported by SCE-MI 2 . . .

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

I am not sure why you changed Brian's first paragraph to this.

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

Why not remove the part after the comma about being free to add
additional features?  Once again, nothing stops an implementor from
adding extensions and there is no way to enforce a ban on extensions.
We do no need to state that a vendor is free to do this.

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

Except for the part about the warnings, I am not sure why you proposed
to change Brian's second paragraph to this?  I liked Brian's proposal
because it did not specifically talk about SystemVerilog DPI features.
It was more general.  Also, it did not talk about simulator versus
emulator except to mention the motivation behind the extensions for
2.0 was to allow easy migration from simulators to emulators.  The issue
of compliance is really implementation versus implementation in general.

Per



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