Subject: [sv-ec] FW: BOUNCE sv-ec@eda.org: Non-member submission from [Raghuraman R
Bounced email to SV-EC. Looks more like an sv-cc discussion to me.
-----Original Message-----
>From owner-sv-ec Tue Dec 31 03:13:41 2002
Hi,
Raghu here.
I have gone through the entire thread of mails. I felt missed out on such a
Regarding C++ interface, I dont see any difference from the current set of
Of course, that doesnt preclude the usage of C++. Here what we do, code
My opinion is that whether its C/C++/SystemC, the problems are manifold
The usage of Perl is very very advantageous for the user because the user
Another advantage of Perl is that it allows RAD (rapid application
There are already mechanism to embed Perl Interpreters in C-code itself. In
Thats why I believe that if the simulator vendors allow the VPI interface in
Another advantage with Perl is that power users can really use it to the
Kevin Cameron wrote:
Alec Stanculescu wrote:
Raghuraman R
ASIC
Texas Instruments (India) Ltd.
Phone : +91-80-5099113
http://www.india.ti.com/~raghu
* Think. *
This archive was generated by hypermail 2b28
: Mon Jan 06 2003 - 09:06:04 PST
From: David W. Smith (david.smith@synopsys.com)
Date: Mon Jan 06 2003 - 09:06:31 PST
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]
Sent: Tuesday, December 31, 2002 3:14 AM
To: owner-sv-ec@eda.org
Subject: BOUNCE sv-ec@eda.org: Non-member submission from [Raghuraman R
<raghu@ti.com>]
Received: from go4.ext.ti.com (go4.ext.ti.com [192.91.75.132])
by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id
gBVBDZYr002466;
Tue, 31 Dec 2002 03:13:39 -0800 (PST)
Received: from dlep51.itg.ti.com ([157.170.141.75])
by go4.ext.ti.com (8.12.6/8.12.6) with ESMTP id gBVBDYiR001232;
Tue, 31 Dec 2002 05:13:34 -0600 (CST)
Received: from mailsvr.india.ti.com (localhost [127.0.0.1])
by dlep51.itg.ti.com (8.12.6/8.12.6) with ESMTP id gBVBDTts014272;
Tue, 31 Dec 2002 05:13:31 -0600 (CST)
Received: from apdsparc155.india.ti.com (apdsparc155 [157.87.88.141])
by mailsvr.india.ti.com (8.8.8/8.8.8) with ESMTP id QAA19504;
Tue, 31 Dec 2002 16:43:29 +0530 (IST)
Received: from ti.com (localhost [127.0.0.1])
by apdsparc155.india.ti.com (8.9.3/8.9.3) with ESMTP id QAA20753;
Tue, 31 Dec 2002 16:43:26 +0530 (IST)
Sender: a0756945@india.ti.com
Message-ID: <3E117BD6.22BAD44E@ti.com>
Date: Tue, 31 Dec 2002 16:43:26 +0530
From: Raghuraman R <raghu@ti.com>
Organization: Texas Instruments (India) Ltd.
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Alec Stanculescu <alec@fintronic.com>
CC: Vassilios.Gerousis@Infineon.Com, Shalom.Bresticker@motorola.com,
Vassilios.Gerousis@Infineon.Com, sv-cc@server.eda.org,
sv-ec@server.eda.org
Subject: Re: [sv-ec] FW: VPI in Perl..
References:
<9843A649BAD7FB4686F6FCBC840D600E02FCAA43@mucse001.eu.infineon.com>
<200212301637.gBUGbUO28509@f4.fintronic.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
debate on what I have been thinking alone :-)
calls provided by VPI. Unless there is a planned object passing mechanism
to the Verilog (can Verilog handle objects being passed to it?), C++ linking
doesnt seem to give any advantage.
everything in C++, and have the interface functions in C (ie. return types
belong to C - just put an extern C block around all function declarations to
resolve name mangling issues).
- the various platforms/architectures) and the various compilation routines
that the user has to undergo). We have often found issues when we work
across Sun, Linux and HP.
now has one set of code which will work uniformly across all platforms.
ScriptSim (http://www.nelsim.com/scriptsim/python_demo.html)
does a fairly good job but its a set of limited capabilites and also doesnt
absolve me of the compilation routines.
development). To write a simple monitoring program in C will need a lot
more effort than it could be to write in Perl.
fact, I have tried out a small program which simply does this. The
interface is a C-function which is registered with the simulator, as is the
case for all VPI calls). This function is just a dummy function, which just
calls perl routine. This Perl routine does all the job. I have also
created look-alike VPI functions in Perl (using SWIGging - see
http://www.swig.org). So the simulator calls a C task, which calls a Perl
routine, which again uses C-VPI functions to do what it wants. This work is
a good example of reaching New York by going to Mars!
Perl, it could make lot of things easier. There is OOPerl as well, so that
even if we plan to have a mechanism for passing objects back to Verilog in
the future, we can implement it through Perl.
hilt. Perl can used for storing data as well as programming. Imagine if
you store test vector data in Perl, how simple it would be!!!
>
> Shalom.Bresticker@motorola.com wrote:
>
> >I have seen a few ways to integrate Perl into Verilog,
> >one or two inside Motorola and one or two outside.
> >
> >Shalom
> >
> >
> There is a proposal I wrote for linking C++ with dynamically loaded
> libraries, but it could equally well load Perl (or any other
> interpreter):
>
> http://www.eda.org/sv-cc/hm/att-0501/01-sv2c.pdf
>
> Example:
> http://www.eda.org/sv-cc/hm/0544.html (follow thread)
> http://www.eda.org/sv-cc/hm/att-0544/
> http://www.eda.org/sv-cc/hm/att-0547/
>
> Unfortunately, it just got voted down for being too complex. Feel free
> to join the CC committee and vote for its return :-)
>
> Regards,
> Kev.
>
> Hi Raghu,
>
> Integrating Pearl into Verilog is an excellent idea. The best way to
> get this done is to motivate one of the Verilog vendors to support it
> and to donate the integration to Accellera so that it can make its way
> into the standardization process as a feature that is tested by an
> implementation.
>
> At Fintronic we have already integrated C/C++ to Verilog without the
> need for PLI/VPI. The idea is that the user can write the bodies of
> Verilog Tasks/functions directly in C, based on some assumptions
> regarding the conversion of the input, output, and inout parameters.
>
> If you would be interested in participating in this effort you could:
>
> 1. Review Fintronic's support for C/C++ without PLI, by visiting
> www.fintronic.com and checking "Support" and then "Read our FAQ" and
> reading section 3.8 "How do I call my own C functions without using
> PLI".
>
> 2. Suggest how to extend this mechanism for Pearl. Specifically, the
> detail of how do we tell the Verilog compiler that the body of a
> function is written in Pearl as opposed to C/C++, and at which
> point should it be executed (i.e. after compilation, after
> elaboration, or during simulation).
>
> 3. Test our implementation for both C/C++ and Pearl integration to
> Verilog.
>
> Once we have something useful working we can donate it to Accellera
> under the same conditions as teh other donnations, and from there it
> can make its way to the IEEE and IEC.
>
> Best regards,
>
> Alec Stanculescu, President and CEO
> Fintronic USA, Inc.
> alec@fintronic.com
--
Regds,