[sv-cc] Mantis item #2226

Hi all,

first of all Season's Greetings and all the best to all of you. Hope you 
had a nice time with your families and enjoyed some days off. I 
certainly did (and still do) - I am in vacation until next Monday, but 
will try to join the call today.

This email tries to nail down some feedback about the problem of dynamic 
objects and especially Abi's write-up. Many thanks to Abi for providing 
us this proposal, after reading it for the 4th and 5th time I think I 
start to understand it much better. ;-)

Since some you have requested also some use cases from a customer's 
point of view from my side, I am trying to do my best and putting some 
related information into my feedback. Hope this is useful. So let's 
start finally:

A) From my point of view there are three types or classes of 
"applications" that are usually written in PLI/VPI/DPI that can/should 
be differentiated for this discussion:
 A1) small, script-like, functions that are implementing simple things 
or a specific functionality that can be easier or more efficient 
described in the "C" language than in Verilog. Typical functions falling 
into this category are, e.g.:
   . a small parser that is reading one or more specific file(s) 
containing some configuration information
   . utility functions that are providing a specific functionality (e.g. 
string concatenation, filename/pathname extraction & building)
   . a reference model for a module that is best to describe on an 
algorithmic level without much detail needed on RTL level
   . a function that generates specific stimulus for a protocol, which 
is reusing some pre-coded C algorithm
   Most (80% - 90%) of these functions are and will be further moving in 
the DPI camp, whenever the functionality provided by DPI permits this. 
The remaining functions will very likely move to a mixture of DPI and 
VPI over time. This type of "applications" is the usual level of 
complexity generated and maintained by "normal" users, aka design and 
verification engineers.
 A2) Medium complex applications or "plug-ins" that are usually 
extending a Verilog application with specific functionality. Examples are:
   . In interface to a customer specific simulator, or a non-Verilog 
simulation engine, e.g. an Instruction Set Simulator
   . An extension of a simulator to write  a VCD file with a specific 
format for later usage (e.g. for tester pattern generation)
   . An extension of a simulator to read a specific stimulus format 
(e.g. for tester pattern resimulation)
   . An extension of a Verilog simulator for doing or setting up 
specific formal analysis tasks or library verification support activities
   The functionality required by these applications requires usually the 
usage of VPI, DPI does not provide the features needed. These kind of 
applications are usually created and maintained by "power users" and 
central CAD organizations of larger companies.
 A3) Complex applications that perform highly complex functionality not 
provided by standard Verilog applications. Functionality that falls into 
this category are usually new applications written on-top of a simulator 
or another Verilog application. Examples are:
   . A full blown high level verification language (e.g. Verisity's e)
   . A methodology to evaluate/grade the quality of testbench (e.g. 
Certess' Certitude)
   . An additional simulator interface provided by a simulator vendor 
(e.g. OMI)
   These applications are often tools by themselves, and have a high 
degree of complexity and run-time sensitivity. They are usually created 
by third-party companies or start-up's or "Advanced Tool" organizations 
in larger semiconductor companies.

The above examples are having two important distinctions:
 - the complexity of the task to be implemented by a VPI function (e.g. 
simple/medium/complex)
 - the "user" or creator of this function (e.g. designer/CAD/tool developer)

comment a) In my humble opinion (IMHO), applications of type A1) and 
their users/creator's do and will not care about the lifetime of dynamic 
objects. These kind of functionality is rarely performance critical and 
seldom very complex, so they will not gain much if they do. Instead of 
going the extra mile with aspects or similar implementations they will 
simply obtain a new variable handle every time they need it. Similar 
might be true for a certain percentage of applications of type A2), I 
assume about half of them.

comment b) Even for all applications not discussed by comment a) I do 
not see much benefit in terms of application runtime when adding the 
properties from Abi's proposal. Most of them describe the validity of 
certain properties, but leave it up to the user to handle the 
corresponding variable correctly. IMHO this creates two problems:
   - a chance to create vendor specific extensions, because CAD people 
optimize the behavior for a specific simulator/tool (often people use a 
trial-and-error approach to identify the simulator behavior and measure 
the performance)
   - not necessarily  the people writing these kind of applications have 
the time/knowledge to handle these properties correctly all the time

comment c) I am not able to find a good reasoning for the capability of 
being able to lock a specific object as described in Abi's proposal. I 
also failed to find to imagine a good use case for this feature. As 
said, sorry I am just a dumb user.

comment d) Most of the aspects in Abi's proposal just cover when a 
certain information is valid and/or can be requested. Why do we not just 
put a certain error return code to denote an invalid request when 
performing the request operation ? Adding these aspects permits us to do 
some check upfront, but is this really needed ? Just want to ask this 
question loudly ...


As a summary, I think Abi's proposal has added a lot of value, because 
it structures the problem in a well defined way. However I see some 
issues with it, I think we should discuss in the next meeting:
 - it permits the user to optimize the lifetime analysis of some 
variables and react accordingly. This would be good, if this is 
predictable over all applications, simple and would be fully 
deterministic. However I have the fear that this might fire back and 
could also result in tool specific behavior and plug-ins, mis-optimized 
behavior. I am simply not sure the user really needs to handle this kind 
of information on its own.
 - a lot of this information provided by the aspects shows what kind of 
functionality is valid for a certain handle type; aka it defines what is 
erroneous behavior when asking for a certain information using a handle. 
Why can we not handle these error cases reactively; e.g. by providing 
the appropriate error status upon an erroneous function call?
 - I am not sure whether there are not different implementations 
possible that hide this kind of complexity from the user; e.g. smart 
pointers similar to SCV which can be used as handles for dynamic 
objects. Just loud thinking again ...

Hope this is useful feedback to start from.

Happy New Year!

Best regards,
-Michael










-- 


NOTE:
The content of this message may contain personal statements which are not 
neccessarily the view of Freescale, unless specifically stated.

         ___________________________________________________     
        |                                                   |
        | Michael Rohleder            Tel: +49-89-92103-259 |
     / )| Principal Staff Engineer    Fax: +49-89-92103-101 |( \
    / / | Freescale Semiconductor,        www.freescale.com | \ \
  _( (_ |  _        New Product Development Center       _  | _) )_
 (((\ \>|_/ >  Schatzbogen 7, D-81829 Muenchen, Germany < \_|</ /)))
 (\\\\ \_/ /    mailto:michael.rohleder@freescale.com    \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \

This e-mail, and any associated attachments have been classified as:
[ ] Public
[ ] Freescale Semiconductor Internal Use Only
[x] Freescale Semiconductor Confidential Proprietary


    Freescale Halbleiter Deutschland GmbH
    Schatzbogen 7
    D-81829 Muenchen
    www.freescale.com

    Sitz der Gesellschaft/Registered Office: Muenchen
    Registergericht/Registered Court: Amtsgericht Muenchen HR B 151590
    Geschaeftsfuehrer/General Manager: Juergen Weyer, Daryl Raiford, 
                      Oliver Kaltenbach, John Pence, Andreas Wild
    USt.-ID-Nr./VAT-ID-No. DE813898243
    Steuernummer/Tax No. 143/138/30552



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.