Russ, My proposal to John to illustrate using Verilog 2001 the proposed function-based approach for simulation focuses the discussion. I am truly hoping that John will pick this up and share the results with us so we can move forward on this crucial point. You rephrased some of the points in my email in a way that I disagree with. In particular you implied that we proposed a SystemVerilog only SCE-MI 2.0 standard. I don't know if it makes sense for me to go through a lengthy response to each at this time. I would only state again that we are always stated that SCE-MI 2.0 must support all 3 HDLs on the HW side including SystemVerilog VHDL and Verilog 2001. The question on the table is only how it should support these and not if it should support these. We also have been holding on officially bringing our macro based proposal now to the committee in spite of the fact that these macros meet all principles stated across the three HDLs with the only exception that these are not function-based on the HW side. We also stated our support for SCE-MI 2.0 to be DPI-based standard for SystemVerilog. Thanks, Shabtay ________________________________ From: Russell Vreeland [mailto:vreeland@broadcom.com] Sent: Tuesday, October 04, 2005 12:01 PM To: Shabtay Matalon; 'John Stickley'; itc@eda.org Subject: RE: supporting DPI in VHDL - possible scenarios for implementation Shabtay, after re-reading your email for the perhaps 4th time, I think I see what it is you're objecting to. I haven't changed my mind about the dismissibility of your point, and your point was somewhat obscured in your email, but for the sake of clarity, let me try to rephrase it into several points, then I'll comment... a) the principle objection is that a simple library will not support function-based calls because there are an infinite # of possible function names comment: agreed, this is one basic difference between the function-based approach and a macro-based approach. b) objection is that this requires 'modifying standard IEEE VHDL compilers" comment: disagree. What it requires is something akin to a small piece of what an IFLC does -- call it code regeneration -- to operate on code that has the SCEMI compliant empty functions with attributes. These function calls would be replaced by calls to a finite # of library functions which would use the attributes to implement the necessary binding. The output of this mini-IFLC would then be IEEE-compliant VHDL. Perhaps, to assuage the objection that simulator vendors that don't have emulation products and wouldn't be developing sophisticated IFLC tools couldn't run these SCEMI 2.0 VHDL models in their simulators, this mini-IFLC could be written and made public. All it would have to do is parse the function + attribute and replace it with a standard library function with binding information usable by some FLI-using implementation. Probably could be done in perl without much difficulty. Algorithm would be: -- look for function -- look for attribute -- if attribute indicates SCEMI2.0 DPI function, replace function with library function call, with all the other info from the function included so that binding may be done underneath. perl could input the function name as a 2nd attribute or some other parameter so that the name would be available to the FLI for binding. -- on to next function I wouldnt' expect the guts of this mini-IFLC to be made public; the actual FLI code on both VHDL and C sides would be "exercise left to student". However, the situation at this point wouldn't be any different (reg'd these smaller simulators) than the situation today with SCEMI1.1. (see my last paragraph below). Even better would be, if a simulator had mixed language support, to replace the VHDL function call with infrastructure that implements a SystemVerilog module instantiation with actual DPI calls. This would be a harder problem -- converting a function call to a structural implementation is beyond a one-pass perl script -- but shouldn't be difficult for a major-league simulation vendor. The advantage would be that once this is done, there literally is nothing to do on the C side. Of course, if a simulator really had mixed-language support, why wouldn't its SCEMI2.0 models be done in SystemVerilog to begin with... and avoid all this problem? c) objection: any "code regeneration" requirement is reason to abandon the function-based approach for VHDL / old Verilog comment: disagree. The benefits of a common C side for modeling far outweigh this one-pass fiiltering requirement. As I see it, the paramount goal of this SCEMI 2.0 initiative is to enable verification IP to be written such that it ports seamlessly from pure simulation to emulation. Also as I see it, the only way to move in that direction is to use a simulation standard for emulation testbench messaging (DPI for SCEMI 2.0). Everything else must flow from that. Arcane macros are a dead-end for this goal -- no simulation-only IP will ever be written using them. d) "you cannot expect these tools (other simulators from vendors that dont' have emulation products) to be changed beyond what is required by HDL language standards" there is no expectation or requirement that any tool need be changed. It's comments like these that obfuscate the point that there is some filtering or "code regeneration" required for a function-based solution in VHDL. This filtering is independent of the simulator which need not be changed in any way. Another comment: In practice, running SCEMI 1.1 testbenches can't be done on simulators that don't support SCEMI1.1 explicitly because these simulation vendors don't make public their SCEMI 1.1 libraries. Perhaps the code regeneration methodology for SCEMI 2.0 support of VHDL would make it easier to port testbenches to the smaller simulators because the C-side requirements would be less than for SCEMI 1.1 once the straightforwardness of code swapping on the VHDL side is assumed. --------------------------------------- --- Russ Vreeland (949)926-6143 --- --- vreeland@broadcom.com --- --- Senior Principal Engineer --- --- Broadcom Corporation --- --------------------------------------- -----Original Message----- From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Shabtay Matalon Sent: Tuesday, October 04, 2005 9:58 AM To: John Stickley; itc@eda.org Subject: RE: supporting DPI in VHDL - possible scenarios for implementation 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? 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. 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. 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. 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. > >-- johnS > >______________________________/\/ \ \ >John Stickley \ \ \ >Mgr., Acceleration Methodologies \ \________________ >Mentor Graphics - MED \_ >________________________________________________________________Received on Tue Oct 4 18:14:41 2005
This archive was generated by hypermail 2.1.8 : Tue Oct 04 2005 - 18:14:53 PDT