RE: more on Bernard's SCE-MI 2.0 issue

Hi Bernard,

Have you sent a simplified version of your examples using SCE-MI 1.1 and
simulating using DPI? I'd like at least to send it to few people to look
at if it arrives while I am on vacation for 3 weeks.

Regards,

Shabtay 

>-----Original Message-----
>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of John
>Stickley
>Sent: Tuesday, June 26, 2007 1:45 PM
>To: bdeadman@sdvinc.com
>Cc: 'itc@eda.org'
>Subject: more on Bernard's SCE-MI 2.0 issue
>
>Bernard,
>
>I discussed your issue further with some of my Mentor
>colleagues we came to the conclusion the standard itself
>probably needs no changes to solve your problem.
>
>It's more a question of efficiency of implementation of
>the standard.
>
>In thinking about it further, we realized that if you can
>model this successfully in a DPI compliant S/W simulator
>(which you said you could do by putting the imported call
>in a combo block), there's no reason, you cannot do the same
>in an emulated environment.
>
>Furthermore, there's no reason the emulated environment
>needs to implement that call inefficiently as you had
>expressed a concern about (i.e. multiple calls over a
>communication link as combo logic "settles out").
>
>In fact, I would say that in any cycle based simulator
>- which an emulator typically is, any such combo blocks could
>be modeled pretty efficiently so as minimize the number
>of calls to the imported function that are needed to
>still get the right answer.
>
>This is really more of a question of efficiency of
>implementation and the standard itself makes no restrictions
>on how this could be optimized. And as Per first mentioned,
>implementations do have the freedom to use an uncontrolled
>clock underneath if necessary to implement DPI calls.
>So, in effect, implementations can automatically (implicitly)
>do what you're doing in the SCE-MI 1.1 implementation by stopping
>the clock (explicitly).
>
>Now, this said, you do need be careful how you write
>the imported function in question. You have to write
>it in such a way that if it was called multiple times
>in a given clock cycle by the same combo block, it
>would not lead to erroneous behavior. In other words,
>if each call advances some state on the C side, that could
>lead to inconsistent behavior when going from one implementation
>to the next.
>
>But obviously you have to worry about this whether emulating
>or simulating - irrespective of whether you're using a
>SCE-MI 2 implementation or just a plain SystemVerilog DPI
>implementation in a S/W simulator.
>
>And I'm assuming you've already designed the function
>to be somewhat pure in the sense that it is resilient
>to side effects of multiple calls.
>
>-- johnS
><eom>
>
>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.


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