RE: [sv-cc] Problems found in sv_vpi_user.h file

In my opinion, the vpiRhs of a cont assign bit should be
non-NULL if and only if it can be represented as a VPI
object of some sort.  In the example you gave, vpiRhs
would return NULL for every bit of the cont assign.

But it would be better if the 1364 LRM (or its successor)
spelled this out.  Will you file a Mantis item on this
issue so that the whole committee can eventually discuss
it?

Regards,
Jim V.

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Engineering Director                   (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd 
Chelmsford, MA 01824-4179 
"We all work with partial information." 
---------------------------------------------------------- 
  
 

] -----Original Message-----
] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
] Behalf Of Tapati Basu
] Sent: Monday, June 06, 2005 3:05 PM
] To: Charlie Dawson; sv-cc@eda.org; stuart@sutherland-hdl.com
] Subject: RE: [sv-cc] Problems found in sv_vpi_user.h file
] 
] Hi,
] 
] Is vpiLhs/vpiRhs query supported on vpiContAssignBit object ? 
] According to LRM,
] it is supported ( I mean the arrows are from the dotted 
] container box). But 
] In Verlilog PLI hand book (Stu's book), the lines are from 
] ContAssign solid 
] box and I think that makes more sense. 
] 
] I am facing a scenario where the ContAssign is : 
] assign { carry_out, sum_out} = ina + inb + carry_in;
] 
] Here I do not know how we can create a bit select object of 
] the RHS expression.
]  
] Another case might be a function call like :  assign a = func(b); 
] 
] Can someone please help me with this ? 
] 
] - Regards,
] Tapati 
] 
] 
]  
] >X-Authentication-Warning: server.eda.org: majordom set sender to 
] owner-sv-cc@eda.org using -f
] >From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
] >To: <chas@cadence.com>, "'SV-CC'" <sv-cc@eda.org>
] >Subject: RE: [sv-cc] Problems found in sv_vpi_user.h file
] >Date: Fri, 3 Jun 2005 11:17:48 -0700
] >MIME-Version: 1.0
] >Content-Transfer-Encoding: 7bit
] >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
] >Thread-Index: AcVnvVMQKxYN2oFeSTmT282shhAVVAAqVbeQ
] >X-Virus-Scanned: ClamAV 0.83/910/Fri Jun  3 09:05:05 2005 on 
] server.eda.org
] >X-Virus-Scanned: ClamAV 0.83/910/Fri Jun  3 09:05:05 2005 on 
] server.eda.org
] >X-Virus-Status: Clean
] >X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 
] M:97.0232 C:98.7678 )
] >
] >Chas,
] >
] >I suggest you pick one of the Mantis items that affected 
] Annex I, preferably
] >one that affected at least some these constants, and adding 
] a bug note to
] >correct all of these problems, including the problem Tapati. 
]  They are all
] >related to making the header file work, so it seems 
] reasonable to me to add
] >these corrections to an item that was also fixing the header 
] file.  The bug
] >note should state that it supersedes any values that were 
] assigned to those
] >constants by other changes prior to the bug note date.  Amending an
] >existing, already approved Mantis item and treating the 
] value changes as
] >typographical errors would be much easier than opening a new 
] Mantis item
] >going through the approval process at this late date.
] >
] >Stu
] >~~~~~~~~~~~~~~~~~~~~~~~~~
] >Stuart Sutherland
] >stuart@sutherland-hdl.com
] >+1-503-692-0898
] >  
] >
] >> -----Original Message-----
] >> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
] >> Behalf Of Charles Dawson
] >> Sent: Thursday, June 02, 2005 2:51 PM
] >> To: SV-CC
] >> Subject: [sv-cc] Problems found in sv_vpi_user.h file
] >> 
] >> Hi All,
] >> 
] >> A review of the sv_vpi_user.h file here at Cadence has found the
] >> following issues:
] >> 
] >> 1.  vpiLogicVar is defined as vpiRegVar; should be vpiReg.
] >> 
] >>    #define vpiLogicVar vpiRegVar
] >> 
] >> should be
] >> 
] >>    #define vpiLogicVar vpiReg
] >> 
] >> 2. vpiClockingBlock == vpiAssert
] >>     vpiClockingIODecl == vpiAssume
] >>     vpiClassDefn == vpiCover
] >>     vpiConstraint == vpiDisableCondition
] >>     vpiConstraintOrdering == vpiClockingEvent
] >> 
] >> These object type defines overlap.  We need
] >> to pick different numbers for one or the other
] >> of them.
] >> 
] >> I think it is essential that we resolve these two problems
] >> along with the one that Tapati found for the vpiAlwaysType
] >> issue.
] >> 
] >> Stu, please let me know how you would like to handle these
] >> things.
] >> 
] >>    -Chas
] >> 
] >> -- 
] >> Charles Dawson
] >> Senior Engineering Manager
] >> NC-Verilog Team
] >> Cadence Design Systems, Inc.
] >> 270 Billerica Road
] >> Chelmsford, MA  01824
] >> (978) 262 - 6273
] >> chas@cadence.com
] >> 
] >> 
] >> 
] >> 
] >
] 
] Tapati Basu
] 
] 
] 
]