RE: [sv-cc] Assigning Mantis Items

Hi all
OK, I did the first four of my list that looked the easiest:
561
570
571
572

If anyone has time, since this is a completely new process (and style)
for me, let me know if they look OK, (Chas - you actually entered all
four of these, I know you are busy, but if you get a chance to see if I
fixed 'em approximately the way you thought they should be fixed I'd
appreciate it...)
Thanks
Abi
 

-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
Charles Dawson
Sent: Wednesday, October 26, 2005 1:43 PM
To: SV-CC
Subject: [sv-cc] Assigning Mantis Items

Hi All,

Here is an initial assignment of Mantis Items.
Please read them over, and if possible, make proposals.  If you don't
think you can address a particular issue, let me know.

Thanks!

   -Chas



Charles Dawson
0000804,27.55 Generates has bad assertion and typespec enclosures
0000800,27.30 clocking blocks could have been modeled using delay
devices
0000785,27.55 vpiSize is of type int not bool
0000784,27.11 low and high conn are not drawn properly 0000751,vpiPrefix
can be a class defn too 0000756,vpiExpr of expr?
0000755,vpiValueRange target should be range rather than distribution
0000754,vpiConstraintItem relation missing from header file 0000753,No
VPI object for an iterative constraint

Ankur Kuchlous
0000750,"In VPI, constraint from class defn differs from constraint in
class obj"
0000749,vpiParent for constraint?
0000265,sv_vpi_user.h has redundancy
0000734,Resolve issues in 15.3 with regard to PLI callbacks
0000748,vpiParent of var select can only be array var 0000747,Add common
VPI properties to typespecs 0000746,What is VPI iteration to get
typespecs from an instance?
0000745,vpiName for SystemVerilog tf call?
0000744,Does vpiMethods iteration include built-in functions and tasks?

Ralph Duncan
0000883,Wrong field names in s_vpi_vecval struct in svdpi.h file
0000880,DPI functions should be allowed to return non-small values
0000872,Typo with "Partsel" in F.9.3
0000793,29.4.3 has vpiAssertVacuousSuccessCovered but missing in include
file
0000791,27.43 There is no 'vpiAssignmentOp' in the include file
0000790,27.40 continue and break should be bold
0000789,27.27 need to handle tfs connected by name and default values
for args 0000758,Examples in DPI clause should use "DPI-C" rather than
"DPI"
0000757,"vpiExtern, vpiDPIExport, and vpiDPIImport have no #define's"

Jim Vellenga
0000743,cbSizeChange vs. cbTypeChange
0000742,Need VPI info on parameters that are types 0000741,File and line
number for vpiClassObj?
0000740,Does vpiIsProtected apply to a vpiClassObj?
0000739,32.27 Wrong outline for VPI constraint
0000738,32.28: method as parent or origin of VPI frame
0000529,32.21 & 32.22 Cannot get a handle to a class instance
0000736,More clarifications on DPI string arguments and pass by
reference
0000480,32.26 use of vpiRefObj here but not in 32.12

Sachchidananda Patel
0000733,32.17 -- inconsistent use of vpiTypedefAlias
0000732,Representation of super and this in VPI?
0000429,Need a separate section on VPI routines 0000727,Review
constraint of 32.23
0000450,32.7 confusing note
0000486,32.34 Why are variables of property spec special?
0000438,Annex I - missing values in object and property definitions
0000559,31.4.2 Only need one collection type
0000560,31.4.1 & 31.4.2.1 Overloading vpi_handle() is a bad idea

Andrzej Litwiniuk
0000580,31.8.4 section is not necessary and colloquial
0000581,31.8.4.1 Need to clarify the first paragraph
0000583,31.8.4.2 terminology first defined in a footnote?
0000584,31.8.4.2 implies that vpi_goto() creates new handle
0000587,31.8.7 Please replace the term "user" with a more accurate term.
0000588,31.9 uses the term "user", and has grammatically incorrect
sentences 0000590,31.10 Should provide dlopen() like functionality
0000592,31.12 return values for functions is backwards
0000565,31.6 remove first paragraph of this section

Abigail Moorhouse
0000568,31.8.1 initialization and loading functionality is optional?
0000570,31.8.1 Need prototype for vpi_load_extension()
0000571,31.8.1 unnecessary complication added for vpi_close()
0000572,31.8 make use of the term 'user'
0000573,31 superfluous functionality added in the name of performance
0000579,31.8.3.2 This section should be replaced with a object model
diagram
0000561,31.4.2 vpi_free_object() should be explicitly referenced here
0000562,31.5 needless restriction on traverse object creation - poor
terminology
0000563,31.5 diagram in figure 31-18 needs to be redrawn

Michael Rohleder
0000556,31.2 Beginning of this section not needed in larger context of
spec
0000557,31.3.1 specific references to objects should be removed
0000558,31.3.3 rename section to "Access availability"
0000589,31.10 cannot set the user_data field 0000442,Annex I -
Organization?
0000306,vpi_put_value is not defined for systemVerilog datatypes
0000305,vpi_get_value behaviour is not defined for systemVerilog
datatypes
0000436,30.4.3 is inconsistent with the diagrams in section 32

Francoise Martinolle
0000424,29.3.1  Should this be here?
0000421,29 - This section should be folded into Section 32
0000378,Descriptions should include when the order is important
0000374,Should be better way of knowing the return values for many
properties 0000057,VPI cannot access the dependent packages for a given
instance 0000045,VPI access to elements of complex literals 0000068,VPI
access to assertion local variables
0000459,32.13 Have we considered the implications of including arrays
here?

Steven Dovich
0000430,29.5.1 Use vpi_remove_cb() to remove callbacks
0000555,31.1 Introduction not needed in context of the larger document
0000567,31.7 arbitrary overloading of the routines
0000593,31.12 Routines should be in table format
0000463,32.16 should not perpetuate unused functionality 0000788,Should
we return vpiOtherFunc for vpiFuncType when on a void function?
0000484,32.28 and 32.29 Should not define callbacks in notes 0000752,No
way to tell in VPI if method task or function is static

--
Charles Dawson
Senior Engineering Manager
NC-Verilog Team
Cadence Design Systems, Inc.
270 Billerica Road
Chelmsford, MA  01824
(978) 262 - 6273
chas@cadence.com