Hi John, I think that we can and should narrow the discussion at this time. When you sent your proposal you stated (I quote): "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." Please define which vendor you are referring to; simulation vendor or acceleration/emulation vendor? It is reasonable to ask acceleration vendor to modify the back-end compilation flow. I have no objection that acceleration vendors would fill the empty functions "with the right substance" for any of the 3 language domains. 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. 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? 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. Using Verilog 2001 will allow all of us to quickly evaluate the simulation flow and assess if there are any issues we need to resolve for VHDL. I am not asking for an optimal and final version of the flow for simulation. The intent is that you will show the stated simple implementation as a proof of concept and as illustration of the proposed simulating flow. Thanks, Shabtay >-----Original Message----- >From: John Stickley [mailto:John_Stickley@mentor.com] >Sent: Tuesday, October 04, 2005 10:32 AM >To: Shabtay Matalon >Cc: itc@eda.org >Subject: Re: supporting DPI in VHDL - possible scenarios for implementation > >Shabtay, > >Perhaps a simpler way to state my response: > >If you take say a plain ModelSim (or NCSim, or VCS) >compiler and compile a SCE-MI I design with empty macros >today, although everything is compiled in a language >compliant manor, nothing will happen in the simulation >because those macros "had no guts". > >Similarly if you take a ModelSim compiler and compile a SCE-MI II >design with empty functions today (or export functions that >no one calls), although everything is compiled in a language >compliant manor, nothing will happen in the simulation, >again, because those callees or callers "had no guts". > >But, if, in either case, you add special infrastructure >compilation support so that the empty macros or functions are >filled with "the right substance", you now have something >very useful that supports transaction communication between >the HDL and C environments. > >There is absolutely nothing different in this regard with >one approach vs. the other and if you operate with the >premise that the SCE-MI I standard is valid, then you >can made the same case for the SCE-MI II standard. > >-- johnS > >John Stickley wrote: >> Shabtay, >> >> Responses embedded. >> >> Shabtay Matalon wrote: >> >>> Hi John, >>> >>> >>> >>> While your email below illustrates legitimate scenarios for how DPI >>> could have been implemented by a VHDL compiler, this does not show how >>> an existing VHDL simulation compiler will run your code example w/o >>> being modified. >>> >>> >>> >>> I conclude that your proposal could only be implemented by modifying >>> standard IEEE VHDL compilers or by regenerating the code by the >>> Infrastructure Linker such that that existing VHDL compiler will read >>> the modified code. I would also conclude by deduction that the same >>> assumptions apply to Verilog 2001. Do you agree with this technical >>> conclusion? >> >> >> johnS: >> I strongly disagree. There are two aspects to a compiler: >> >> 1. IEEE VHDL compliant language analysis >> >> 2. Vendor specific native code generation. >> >> My approach does not change 1. >> >> My approach suggests that vendor specific code generation can >> be changed or that reasonable source transformation can be >> performed. >> >> Yes vendors will need to do something to support SCE-MI 2. >> Just as they need to provide infrastructure linker support >> for SCE-MI 1. We've never made claims to the contrary nor >> did the original requirements state that the standard must >> not require any vendor compiler changes or enhancements. >> >> Infrastructure linkage and/or code generation can both >> be considered a core part of vendor compiler capability. >> This is no change from SCE-MI I. >> >>> >>> >>> >>> We at Cadence understand the desire for elevating abstraction using a >>> DPI style functional interface in SCE-MI 2.0. However given that >>> existing IEEE compliant simulators do not support your proposed >>> DPI-like function based approach w/o being modified we cannot accept >>> your proposal. >> >> >> johnS: >> Again, I've not changed IEEE compliancy requirements. Great pains were >> taken to avoid this. Everything is done with supported language >> constructs as you've seen. There is absolutely no illegal syntax. >> >> Just as synthesis tools interpret special attributes or >> meta-comments in the source code, so does a SCE-MI II >> instrastructure compiler interpret the language legal >> attributes as we've defined them. >> >> I think you can make the argument that if you can represent >> the equivalent functionality with transformed source, then >> you can also alter generated code to acheive the same effect >> without transformed source. >> >> One can further make similar arguments for SCE-MI 1. >> >> SCE-MI 1 macros are nothing more than empty macros. >> Yet we insert "magic infrastructure" underneath them >> automatically as part of an extended infrastructure >> compile process. >> >> We have not violated IEEE compliancy with SCE-MI I any more >> than we do with replacing empty functions with "magic >> infrastructure" underneath in SCE-MI II. >> >>> >>> >>> >>> Please keep in mind that while ITC is chartered to define the >>> acceleration interfaces and thus it can set requirements for >>> acceleration compilers, its decisions are not usually even known to >>> the developers of simulators. There is a number of logic simulation >>> tools in use, some of them supplied by the companies represented in >>> ITC and some are not. Some simulators are open source products >>> maintained by the volunteer communities. You cannot reasonably expect >>> these tools to be changed beyond what is required by HDL language >>> standards. >> >> >> johnS: >> Industry standard IEEE compliant VHDL parsers that create an >> intermediate representation of what they have parsed do not >> need to change in any way with what I've proposed. >> >>> >>> >>> >>> Unless you or others members of the committee can come up with a >>> viable functional based interface that does not require modifying >>> existing simulator compilers or requiring code regeneration in >>> simulation flow, I would encourage you and the committee to consider >>> defining a DPI based solution for SystemVerilog only. Only a solution >>> that is fully within defined HDL semantics (that does not require code >>> regeneration) should be considered for Verilog 2001 and VHDL. >> >> >> johnS: >> I think we've made the case that a function call based approach >> may be, at worse, slightly more difficult to implement than a macro >> based approach but violates no more principles or agreed upon >> requirements for SCE-MI 2 than the macro based approach. >> >> -- johnS >> >>> >>> >>> >>> Thanks >>> >>> >>> >>> Shabtay >>> >>> >>> >>>> -----Original Message----- >>> >>> >>>> From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of John >>> >>> >>>> Stickley >>> >>> >>>> Sent: Thursday, September 29, 2005 6:39 AM >>> >>> >>>> To: 'itc@eda.org' >>> >>> >>>> Subject: supporting DPI in VHDL - possible scenarios for implementation >>> >>> >>>> >>> >>>> Greetings ITC Techies, >>> >>> >>>> >>> >>>> As per an action item requested of Duaine and me, >>> >>> >>>> the following e-mail presents possible scenarios for how one >>> >>> >>>> might implement DPI over VHDL purely in a software simulator >>> >>> >>>> environment. >>> >>> >>>> >>> >>>> It does not describe scenarios for synthesis of DPI based code >>> >>> >>>> to an emulator environment. However, for this case, function >>> >>> >>>> calls can conceivably be replaced with synthesizeable infrastructure >>> >>> >>>> layered over SCE-MI 1.1 macros where message input and output >>> >>> >>>> ports are used to carry function input and output messages >>> >>> >>>> across the communication link. >>> >>> >>>> >>> >>>> In the text below, imported and exported 0-time functions are >>> >>> >>>> described separately. >>> >>> >>>> >>> >>>> Specifically VHDL is described is it makes the case that >>> >>> >>>> DPI-like interfaces can be implemented over a language >>> >>> >>>> that does not natively support DPI without requiring >>> >>> >>>> extensions to the language itself. Rather, legal, compliant >>> >>> >>>> attributes are used to alert the language compiler >>> >>> >>>> and/or SCE-MI infrastructure linker to generate extra >>> >>> >>>> infrastructure to support the DPI call interface. >>> >>> >>>> >>> >>>> It is important to note that this does not present >>> >>> >>>> any new requirements for SCE-MI that were not already >>> >>> >>>> there for SCE-MI 1.1 macros in terms of infrastructure >>> >>> >>>> linker support. In fact, in some cases it has proven to >>> >>> >>>> be easy to implement a function call based interface >>> >>> >>>> since, on most industrial HDL software simulators, some >>> >>> >>>> capability already exists for function call type interfaces >>> >>> >>>> - such as foreign functions in VHDL and PLI user defined tasks in >>>> Verilog. >>> >>> >>>> >>> >>>> -------------------------------------------------------------- >>> >>> >>>> Imported 0-time functions >>> >>> >>>> >>> >>>> Imported functions can be declared in VHDL as procedures and >>> >>> >>>> can be called from user clocked RTL processes. Here is an example >>> >>> >>>> of a simple user application written in VHDL that makes use of >>> >>> >>>> the proposed DPI imported function interface: >>> >>> >>>> >>> >>>> entity PipelineEgressTransactor is port( >>> >>> >>>> TokenOut: in std_logic_vector(127 downto 0); >>> >>> >>>> Clock, Reset: in std_logic); >>> >>> >>>> end PipelineEgressTransactor; >>> >>> >>>> >>> >>>> architecture DPI of PipelineEgressTransactor is >>> >>> >>>> --This is a Imported Function declaration-- >>> >>> >>>> procedure UploadEgressTransaction( >>> >>> >>>> signal countOut : in std_logic_vector (31 downto 0) >>> >>> >>>> signal dataOut : in std_logic_vector (63 downto 0); >>> >>> >>>> signal statusOut : in std_logic_vector (31 downto 0)) is >>> >>> >>>> begin end procedure; >>> >>> >>>> attribute foreign of UploadEgressTransaction: >>> >>> >>>> procedure is "sce_mi import DPI-C"; >>> >>> >>>> >>> >>>> begin >>> >>> >>>> process (Clock) begin >>> >>> >>>> if(Reset /= '1' and IsStdLogicVectorZero(TokenOut) = '0') then >>> >>> >>>> UploadEgressTransaction( >>> >>> >>>> TokenOut(31 downto 0), >>> >>> >>>> TokenOut(95 downto 32), >>> >>> >>>> TokenOut(127 downto 96)); >>> >>> >>>> end if; >>> >>> >>>> end process; >>> >>> >>>> end DPI; >>> >>> >>>> >>> >>>> There are a number of scenarios in which an implementation can >>> >>> >>>> implement the "guts" of the empty placeholder function, >>> >>> >>>> UploadEgressTransaction(). >>> >>> >>>> >>> >>>> By no means do we try to dictate any one of those ways here. >>> >>> >>>> We only want to suggest possibilities for implementation. >>> >>> >>>> Different vendors would most likely choose different solutions >>> >>> >>>> depending on what is optimal in their environment. >>> >>> >>>> >>> >>>> 3 of those possibilities are mentioned here: >>> >>> >>>> >>> >>>> 1. 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 foreign language interfacing mechanism would look similar >>> >>> >>>> to the one that SCE-MI 1.1 macros would have to use today. >>> >>> >>>> >>> >>>> Note: No source code transformation is required with this approach >>> >>> >>>> as the extra infrastructure is emitted directly into the >>> >>> >>>> native code output unit. >>> >>> >>>> >>> >>>> 2. VHDL foreign functions - this is similar to 1 above. If a >>> >>> >>>> vendor has created a mechanism in their simulator to implement >>> >>> >>>> "foreign functions" as designated by the `FOREIGN attribute >>> >>> >>>> as described in the LRM, this mechanism can be easily be leveraged >>> >>> >>>> to implement imported DPI functions. In fact, a very good case >>> >>> >>>> can be made that such an implementation could be relatively easy >>> >>> >>>> since this feature already supports function calling semantics >>> >>> >>>> and most vendor have already have some sort of support for >>> >>> >>>> foreign functions. >>> >>> >>>> >>> >>>> Using the `FOREIGN attribute syntax shown in the example >>> >>> >>>> above (which is also consistent with LRM recommended uses >>> >>> >>>> of this attribute to denote foreign functions), the vendor >>> >>> >>>> could directly implement DPI imported functions as foreign >>> >>> >>>> functions using their vendor specific mechanism that is >>> >>> >>>> already in place for foreign functions. >>> >>> >>>> >>> >>>> 3. If the vendor simulator is mixed language and already supports >>> >>> >>>> a SystemVerilog DPI interface, the internals of the VHDL call >>> >>> >>>> could be a wrapper that directly calls a SystemVerilog DPI >>> >>> >>>> imported call. >>> >>> >>>> >>> >>>> This option is similar to 2 except it utilizes existing DPI >>> >>> >>>> capability rather than existing foreign function capability. >>> >>> >>>> >>> >>>> The modified internals for the VHDL call could either be >>> >>> >>>> directly generated as native code (as described in 1 above) >>> >>> >>>> or the user's source code could be slightly transformed to >>> >>> >>>> give the empty placeholder function a body that calls the DPI >>> >>> >>>> function. >>> >>> >>>> >>> >>>> ----------------------------------------------------------------------- >-- >>>> >>> >>> >>>> Exported 0-Time Functions >>> >>> >>>> >>> >>>> The SCE-MI 2 DPI proposal states that 0-time procedures in >>> >>> >>>> VHDL can be attributed as exported DPI functions and called >>> >>> >>>> from C. >>> >>> >>>> >>> >>>> Exported functions can potentially do the following: >>> >>> >>>> >>> >>>> 1. C->HDL message passing or config ops (input args) >>> >>> >>>> 2. C->HDL query ops (output args) >>> >>> >>>> >>> >>>> The exported function would be a VHDL procedure that >>> >>> >>>> can do assignments of input formal argument values to >>> >>> >>>> surrounding signals for passing input messages and can do >>> >>> >>>> assignments of surrounding signal values to output formal >>> >>> >>>> arguments for passing output messages. >>> >>> >>>> >>> >>>> To achieve this, an exported function can be declared as a >>> >>> >>>> specially attributed procedure in the declarative region of >>> >>> >>>> an architecture. >>> >>> >>>> >>> >>>> In the following user VHDL application example, the exported >>> >>> >>>> function, 'ServiceIngressTransaction()' assigns to signals >>> >>> >>>> 'serviceCallDetected', >>> >>> >>>> 'holdingCount', 'receivedCount', 'receivedData' and >>> >>> >>>> 'receivedStatus' declared in the architecture scope. >>> >>> >>>> >>> >>>> -- the following is a Exported Function definition-- >>> >>> >>>> procedure ServiceIngressTransaction ( >>> >>> >>>> signal holdCountIn : in integer; >>> >>> >>>> signal receivedCountIn : in std_logic_vector (31 downto 0); >>> >>> >>>> signal dataIn : in std_logic_vector (63 downto 0); >>> >>> >>>> signal statusIn : in std_logic_vector (31 downto 0)) is >>> >>> >>>> begin >>> >>> >>>> serviceCallDetected <= '1'; >>> >>> >>>> holdingCount <= holdCountIn; >>> >>> >>>> receivedCount <= receivedCountIn; >>> >>> >>>> receivedData <= dataIn; >>> >>> >>>> receivedStatus <= statusIn; >>> >>> >>>> end procedure; >>> >>> >>>> attribute foreign of ServiceIngressTransaction: >>> >>> >>>> procedure is "sce_mi export DPI-C"; >>> >>> >>>> >>> >>>> process begin >>> >>> >>>> wait until (Clock'event and Clock = '1'); >>> >>> >>>> if(serviceCallDetected = '1') then serviceCallDetected <= '0'; >>> >>> >>>> >>> >>>> if (Reset /= '1') then >>> >>> >>>> while holdingCount > 0 loop >>> >>> >>>> holdingCount <= holdingCount - 1; >>> >>> >>>> wait until (Clock'event and Clock = '1'); >>> >>> >>>> end loop; >>> >>> >>>> >>> >>>> TokenIn <= receivedStatus & receivedData & receivedCount; >>> >>> >>>> wait until (Clock'event and Clock = '1'); >>> >>> >>>> >>> >>>> TokenIn <= (others => '0'); >>> >>> >>>> wait until (Clock'event and Clock = '1'); >>> >>> >>>> end if; >>> >>> >>>> end process; >>> >>> >>>> >>> >>>> Here again are 3 possible scenarios for implementing this exported >>>> function. >>> >>> >>>> >>> >>>> 1. The vendor can modify their compiler so that in addition to >>>> generating >>> >>> >>>> simulation code for the user's architecture and procedure, it also >>> >>> >>>> generates an additional process block in the same architecture >>> >>> >>>> scope. This process block communicates directly with the C side >>> >>> >>>> using special synchronization signals together with whatever >>> >>> >>>> VHDL foreign language interface (FLI) that is supported by that >>> >>> >>>> vendor. >>> >>> >>>> >>> >>>> The special process block would wait until one of the >synchronization >>> >>> >>>> signals indicates that a call to the exported function >>> >>> >>>> was initiated. It would then take the input data arguments >>> >>> >>>> passed along from the C side via the FLI and make >>> >>> >>>> a call to the actual exported procedure defined by the >>> >>> >>>> user. The output arguments of the call would be passed >>> >>> >>>> back to C side via the FLI. >>> >>> >>>> >>> >>>> It might look something like this: >>> >>> >>>> >>> >>>> -- Auxiliary process to manage calls to exported >>> >>> >>>> -- ServiceIngressTransaction() function >>> >>> >>>> ServiceIngressTransaction_wrapper: process >>> >>> >>>> -- These variables updated via C interface API >>> >>> >>>> variable holdCountIn : integer; >>> >>> >>>> variable receivedCountIn : std_logic_vector (31 downto 0); >>> >>> >>>> variable dataIn : std_logic_vector (63 downto 0); >>> >>> >>>> variable statusIn : std_logic_vector (31 downto 0); >>> >>> >>>> begin >>> >>> >>>> -- Wait for signal triggered via PLI, VHPI, FLI >>> >>> >>>> -- or similar C-API interface. >>> >>> >>>> wait on ServiceIngressTransaction_trigger; >>> >>> >>>> >>> >>>> -- Make the actual call to the exported function (args >>> >>> >>>> -- are set in wrapper >>> >>> >>>> ServiceIngressTransaction ( >>> >>> >>>> holdCountIn, receivedCountIn, dataIn, statusIn ); >>> >>> >>>> >>> >>>> -- Toggle trigger to notify C side (via value change callback) >>> >>> >>>> -- that call is complete. >>> >>> >>>> ServiceIngressTransaction_trigger >>> >>> >>>> <= ~ServiceIngressTransaction_trigger; >>> >>> >>>> end process ServiceIngressTransaction_wrapper; >>> >>> >>>> >>> >>>> 2. In a mixed language simulator this process could >>> >>> >>>> be a Verilog process that is placed completely outside the >>> >>> >>>> user's original source unit and makes the call to the exported >>> >>> >>>> function using cross scope references. Using this approach would >>> >>> >>>> require absolutely no source code transformation and it could be >>> >>> >>>> implemented with no alterations to the vendor's compiler as well. >>> >>> >>>> Rather an extra module would be created by the infrastructure linker >>> >>> >>>> containing the cross scoping wrapper processes and could be compiled >>> >>> >>>> into its own separate database unit that is elaborated along >>> >>> >>>> with the rest of the design. >>> >>> >>>> >>> >>>> 3. If the vendor simulator is mixed language and already supports >>> >>> >>>> a SystemVerilog DPI interface, an actual DPI exported function >>> >>> >>>> can be added as a wrapper that then calls the VHDL exported >>> >>> >>>> function. >>> >>> >>>> >> >> ______________________________/\/ \ \ >> John Stickley \ \ \ >> Mgr., Acceleration Methodologies \ \________________ >> Mentor Graphics - MED \_ >> ________________________________________________________________ >> > >-- > >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 Tue Oct 4 17:52:16 2005
This archive was generated by hypermail 2.1.8 : Tue Oct 04 2005 - 17:52:39 PDT