[sv-cc] Feedback about Mantis 1752

Hi all,

here is my feedback about this proposal. It clearly shows my limited 
understanding of the topic. :-(
Hope it is still useful.

Just to make sure I fully understand the scope of the proposal:
 . vpiFrame and vipThread have been added for obvious reasons
 . vpiGenScope and vpiGenScopeArray is just sorted alphabetically now
 . vpiClassObj is added, since we also can derive it from the 
corresponding vpiClassDefn.
   Actually there is some slight difference, see the top of page 441. 
Correct interpretation ?

The additional text in blue after these changes is saying the following:
 - for the above stated exceptions there are no vpiLineNo and vpiFile, 
and it would be
   illegal to access these properties [this is not stated explicitely, 
but my implicit assumption]
 - a tool vendor might decide to have some leeway not to store this 
information. In this case
   the tool should return -1 and NULL for vpiLineNo and vpiFile respective.
   Returning these values should not be associated with an error condition.
 - I am a little confused about the last sentence. Does it attempt to say:
    . do never provide this information for a VPI typespec
    . do never provide this information for a VPI typespec, when it 
denotes a predefined type
    . do only provide this information for VPI typespecs of a 
non-predefined type (struct, union, what else ?)
    . do not expect this information to be provided for a VPI typespec
    . anything else ?

For me it looks like the key change here is the possibility for a vendor 
NOT to provide this information.
However, as a user I am not sure I really like this; although I 
understand that there is a certain tradeoff
between memory footprint and the availability of this information. So 
what is the amount of memory we
are talking about here:
 - a typical design will refer to about 1000 - 10000 files, having a 
pathname of 100-400 characters each,
    so we can assume this will require about 4MB of memory max
 - a typical implementation will require 4 or 8 bytes for any object in 
the design to store the related info,
   assuming we have 100000 - 10Mio objects, we can make the count easily.
So what is the chance for the user to choose here? Make this info 
optional, enable its creation with a switch
(so it is available when needed, e.g. for debugging or error messages), 
or require its availability all the time.
Jim could you elaborate a little bit on you point of view here ???

One more note:
Section 26.6.6, note g) states that a return value of 0 should be used 
for implicit nets.
To be consistent with the proposal I suggest to also use -1 in this 
case, or to refer to
the line of the first usage with a valid line number. Usage of 0 here 
seems to be odd to me.

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
[ ] 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, Karen Roscher, 
                                       Oliver Kaltenbach, 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.