Re: Use model and compliance

Shabtay,

Comments embedded ...

Shabtay Matalon wrote:
> Hi Brian,
> 
>  

johnS:
You've raised two issues here that I believe are separate ...

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

johnS:
OK, this is issue #1 which I agree with. However, I would stress
that this is related more to modeling subset which I believe
that all along we rightly avoided delving into.

It really comes down to what, of the surrounding code that
uses the DPI, can be mapped to emulation.

With SCE-MI 1 one can argue that we had the same issue.
It's just that there was an unwritten understanding that
as long as you only used SCE-MI 1 with the synthesizeable
RTL subset, there were not issues of mapping. But there
was nothing saying your SCE-MI 1 code had to be synthesizeable
RTL and, in fact, it is quite easy to write behavioral
SCE-MI 1 models that will only run on simulation, not emulation.

With SCE-MI 2, because function calls don't fall into the RTL
subset, there is an implication that an expanded modeling
subset is required to accommodate it. And I think we can
rightly argue that some effort is required to possibly
standardize what that "mappable" modeling subset should be.

However, that said, I think we can still find SCE-MI 2 quite useful
in the sense that it does formalize at least the interface
between what is mapped to an emulator and what runs in C.

We can also generally say that whatever runs on an emulator
will pretty much always run on a simulator even though the converse
is not true.

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

johnS:
For this (issue #2), I think we can do two things:

1. Discourage vendors from being the "Microsoft of incompatible
    standards extensions" and not adding non-compliant extensions
    unless they are clearly handled with special switches and warnings
    alerting the user that they are entering a super set of the supported
    standard.

2. Expand the features with future revisions of the standard to
    minimize the need for extensions in the first place.

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

johnS:
I prefer Brian's new terms "message passing use model" and "function
call use model" to SCE-MI 1 and SCE-MI 2. Let's use those instead.

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

johnS:
I'm not sure I agree with this last statement. I think warnings
may be a good idea although perhaps you're right in saying
we cannot enforce them. This probably needs further discussion
and some concrete examples. I don't think incompatible modeling
subsets fall into this category. Really they are in a category of
their own. But I think what you're talking about here is additional
functionality in the API itself right ? Can you send some
examples of this ?

-- johnS
<eom>

> 
>  
> 
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.


-- 

This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________


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