Hi Shabtay, I'm still working on an example - pressure of work, plus a wrong turn in trying to make a "simple" example have held me up a little, but I'm still trying to get the example together before tomorrows meeting for anyone who has the time to look at it. Regards Bernard. Shabtay Matalon wrote: > 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. -- 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.Received on Wed Jun 27 08:37:42 2007
This archive was generated by hypermail 2.1.8 : Wed Jun 27 2007 - 08:37:50 PDT