Re: Use model and compliance

Brian,

This e-mail was quite timely as it very nicely addresses the
first of two major concerns I had with scemi 1 vs. scemi 2
in reviewing the new draft:

1. Having a well placed paragraph clearly distinguishing
    SCE-MI 1 and 2 use models.

2. Some re-organization of the ordering of chapters and sections
    to delineate #1 above.

More feedback ...

Brian Bailey wrote:
> 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.

johnS:
I like what you've done with giving the formal labels "message passing
environment" and "function call environment" to the two use models
we've been informally referring to as "scemi 1" and "scemi 2" respectively.

I strongly suggest that we refer to these new labels formally
and liberally throughout the document to provide the clear
delineation between the two use models.

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

johnS:
This looks pretty good.

I'll be sending more feedback on possible re-ordering and restructuring
of the chapters and sections to drive home the separation you've
described more.

-- johnS
<eom>

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


-- 

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.