John, Per, Item 1 - You stated that "Modifying the simulator compiler is not required" - My response is quite simple. Good, show me how you do it on Verilog 2001 simulator. I don't see it. Item 2 - No code regeneration - Each API dictates the methodology by which the models (transactor) need to connect to the interface (function-based or macro-based). You are telling me that I need to emit new code in SCE-MI 1.0 (or macro based approach for Verilog and VHDL). Please explain why? To my knowledge, once I have created set of files that connect to SCE-MI macros, I can link in other files that which constitute the "guts" (by instantiation) w/o touching the original files. Is this correct or not? If not, why not? Assume now that you have run the IFLC and extracted the attributes per John's proposal. Please show me how you link the guts with the original files implementing the import and export function example w/o modifying the original files in Verilog 2001. Thanks, Shabtay >-----Original Message----- >From: John Stickley [mailto:John_Stickley@mentor.com] >Sent: Wednesday, October 05, 2005 5:41 AM >To: bojsen@zaiqtech.com >Cc: Shabtay Matalon; itc@eda.org >Subject: Re: supporting DPI in VHDL - possible scenarios for implementation > >Per, > >Thanks for these responses. > >I was going to respond to Shabtay's e-mail in detail as well >but you've made all the points I was going to make and I think >I can say your version better articulated than I could have >done. > >The one thing I would add to this is, in response to Shabtay's >request that we show a Verilog 2001 alternative implementation >I would make the point that the approaches I mentioned in my >initial writeup for VHDL can be applied more or less equally >in Verilog 2001. And with Verilog 2001 we can further say >that the wrapper layers can use PLI as opposed to a vendor >specific VHDL FLI. > >Your initial point below is key. The operative word is "can". >I'm not saying a vendor is required to modify the native >code generation in their compiler. Merely that that is one >option - and possibly the most optimal one. The other option >is source code transformation by the infrastructure linker. >Any 3rd party SCE-MI implementor could do the latter option >on any industry standard simulator. These were the main points >I was trying to make. > >-- johnS > >Per Bojsen wrote: >> Hi Shabtay, >> >> > "The vendor can modify their compiler so that the empty procedure is >> > automatically replaced directly with generated native code that hooks >> > into an infrastructure implementation that directly communicates to C >> > using whatever VHDL foreign language interface (FLI) that is supported >> > by that vendor." >> >> This was your quote of John's proposal. Note that it says the vendor >> *can* modify their compiler. This implies a choice not a mandate. >> John is simply pointing out some possible optimizations an >> implementation can take advantage of. >> >> > Please define which vendor you are referring to; simulation vendor or >> > acceleration/emulation vendor? >> >> The only vendors we are interested in in this committee are SCE-MI >> vendors. In this case John is talking about SCE-MI vendors that also >> happen to be simulation vendors and who are interested in providing >> an integrated solution, i.e., essentially a simulator with builtin >> SCE-MI support. >> >> > As to a simulator vendor; he has nothing to do with SCE-MI, and it is >> > not reasonable to require him to change a compiler which BTW was not >> > required in SCE-MI 1.1 and when using in general a macro based >> > approach. >> >> And he is not required to do anything to support SCE-MI in 2.0 either. >> The SCE-MI 2.0 implementation can be provided as a third-party addon >> that runs on top of the simulator. >> >> > Russ indicated that quite a "mini-IFLC" can generate EEE-compliant >> > VHDL code (and I assume Verilog 2001 code). If this is as simple as >> > that, can you take your source code example with DPI import and export >> > declaration, use your proposed attributes based approach and empty >> > function calls, and show in Verilog 2001 that the library that you >> > generated by the infrastructure linker (implementing the communication >> > channels underneath) can be instantiated from the empty function calls >> > w/o modifying the source code or modifying the simulator compilers? >> >> What do you mean when you say `w/o modifying the source code'? Is this >> your `no code-regeneration' requirement or are you simply stating that >> the source code should not have to be rewritten by the user before >> it can be passed through the infrastructure linker? >> >> > Can you show how you implement transaction communication between the >> > HDL and C environments for import and in particular export function >> > using standard API in simulation? For the latest, if you want to show >> > how you implemented this on top of SCE-MI macros, this will also prove >> > the point. >> >> This is easy to do but it won't satisfy your `no code-regeneration' >> requirement. After all, replacing function calls with SCE-MI macros >> and associated infrastructure is going to require some modification >> of the HDL code. I assume you are aware of that so is code regeneration >> actually OK? >> >> Per >> >> > >-- > >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 >________________________________________________________________Received on Wed Oct 5 11:53:30 2005
This archive was generated by hypermail 2.1.8 : Wed Oct 05 2005 - 11:53:36 PDT