RE: supporting DPI in VHDL - possible scenarios for implementation

From: Russell Vreeland <vreeland_at_.....>
Date: Tue Oct 04 2005 - 12:01:04 PDT
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 12:01:52 2005

This archive was generated by hypermail 2.1.8 : Tue Oct 04 2005 - 12:02:15 PDT