RE: Use model and compliance

Hi Brian, 

 

The way I see this, both SCE-MI 1 and SCE-MI 2 use model impose the same
compliance requirements. However, SCE-MI 2 in my opinion presents a
higher challenge for creating SCE-MI 2.0 compliant and portable SCE-MI 2
DPI based models. When moving DPI based models from simulation to
emulation, models that use DPI functionality beyond the SCE-MI 2 use
model subset will probably run properly in simulation but will probably
break in emulation. Furthermore, given that emulation vendors are not
restricted to supporting only the SCE-MI 2.0 DPI subset in emulation,
users won't be able to rely on SCE-MI 2.0 implementations to flag errors
when using "extended DPI functionality" provided by a SCE-MI 2.0
emulation vendor for emulation mode. This basically will force users and
model developers to use internal methods for building SCE-MI 2 compliant
models should they wish to insure that their models SCE-MI 2.0
compliance portability.

 

I thus proposed some changes in this spirit in your paragraph while
trying to narrow the scope of the philosophical differences to the
essence of the issue (DPI subset as opposed to the entire SCE-MI 2 use
model). 

 

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.

 

All,

 

Let me know what you think.

 

Shabtay

 

 

 

>-----Original Message-----

>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Brian

>Bailey

>Sent: Friday, December 29, 2006 10:06 AM

>To: itc@eda.org

>Subject: 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

> 

 


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