Use model and compliance

Hi Everyone,
    I hope you are enjoying the holidays. In our last meeting, I agreed to
propose some wording related to compliance issues and the different
philosophy of the two parts of the standard. Here is the proposed wording.
This would be inserted after the first paragraph of section 4.0, which is
included to place it in context.

SCE-MI provides two primary mechanisms for connecting a model written in HDL
to a model running on a workstation. The software side of the interface
allows access from the workstation side, while the hardware side of the
interface allows access from the HDL side. The two mechanisms are a
message-passing environment which was standardized in the previous version
of this standard and generally referred to as SCE-MI 1.1 and a new
functional call based mechanism based on the SystemVerilog DPI (see section
4.7). These extensions form the basis for this new SCE-MI 2.0 draft
standard.

There is another significant difference between these two use models and
that is what it means for an implementation or model to be compliant with
the standard. 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. The same is true for models - they are either
compliant with the standard or not. With the new use model added in this
version of the standard, a different philosophy is used. This is because one
of the primary the goals of these extensions is to make it as easy as
possible to move transactor models written to run in a simulation
environment, to be migrated to an emulation environment. The ideal would be
for the emulator to support all of the features of the simulator, but this
is not possible due to technical and business reasons. The standard thus
defines the minimum set of features that should be supported to be deemed
compliant, but each and every vendor is free to add additional features to
their interface. This also impacts what it means for a model to be compliant
with the standard. To be SCE-MI 2.0 compliant, the model can only utilize
the features defined in this standard and any additional features assumed to
be available by a specific implementation make it non-compliant and thus
potentially non-portable to other implementations.

Please let me have any changes or corrections that you would like to see in
the final version.
Best regards,
Brian