There's a mail thread captured here:
http://www.eda.org/sv-bc/hm/10502.html
Summary of responses:
- The idea was that DirectC/DPI function calls would be indistinguishable from Verilog calls (also, hence the concept of input/output/inout formal arguments missing in PLI). Thus it would be possible to switch between different implementations (i.e. Verilog vs. C) without modifying the calls.
- There's a workaround: you can easily ifdef between using PLI or DPI". It's still true with the current syntax., just put $pli_name or DPI_name in ifdef-ed macro and use 'macro in the calls
- About the motivation concerning synthesis tools. What you are really asking for is to add more features to the language for simulation vendor
to implement so that synthesis vendors don't have to implement anything? How fair is that? Why not just ask synthesis vendors to ignore DPI imported routines?
- For DPI tasks starting with $, you would have to define the precedence rules relative to system tasks. I assume that you would want the DPI
task to take precedence.
Big takeways:
1. This is in conflict with the initial motivation of the feature
2. This can be achieved through already available language features
I will add this topic for review during the next SV-BC meeting (Oct 25, 2010) and capture a more formal response.
Matt
-- Matt Maidment mmaidmen@ichips.intel.com >-----Original Message----- >From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Charlie >Dawson >Sent: Thursday, October 14, 2010 8:26 AM >To: SV-BC >Subject: [sv-bc] Wilson Snyder's proposal to ass $tasks to DPI calls > >Hi SV-BC, > >On Aug-18-2010, the SV-CC directed me to request that the SV-BC rule on >the feasibility of Wilson Snyder's proposal to add $tasks to DPI calls. > >Please let me know if you need further information on this topic. > > -Chas > > >-- >Charles Dawson >Engineering Director >NC-Verilog Team >Cadence Design Systems, Inc. >270 Billerica Road >Chelmsford, MA 01824 >(978) 262 - 6273 >chas@cadence.com > > >-- >This message has been scanned for viruses and >dangerous content by MailScanner, and is >believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Oct 14 09:29:43 2010
This archive was generated by hypermail 2.1.8 : Thu Oct 14 2010 - 09:31:34 PDT