Re: [sv-cc] Updated errata spreadsheet (7/8/2004)

   Francoise (and everyone who may have an unreported bug to file),

   Please go ahead and file these in the new bug tracking system
   that we are going to use shortly.

   o The bug tracking page is located at:

   http://www.eda.org/svdb

   o I believe Jay Lawrence has the Cadence login information.

   o Please file separate bugs for each different issue, i.e.
   do not club everything into a single bug. Although this takes
   a little bit of time for the submitter, it will greatly
   help us resolving issues later.

--
Swapnajit Mittra
Project VeriPage ::: http://www.project-veripage.com/
-- Francoise Martinolle <fm@cadence.com> wrote:
Well what happened to all the erratas I had sent...
sv-cc@eda.org Subject: [sv-cc] Other errata for VPI Cc: chas@cadence.com, 
joao.Geada@synopsys.com
The instance diagram (31.12) shows iteration on scopes, processes, defparam 
and clocking blocks for packages, this is wrong according to the BNF which 
does not allow these things to be declared in packages.
Additionally, the access to the default clocking should be removed from a 
package reference handle.
Array of packages does not make sense so the iteration on instances from an 
intance array returning a package should be removed, same for accessing the 
index (vpiIndex) of a package array element.
Additionally the vpiFullName of a package should be defined. As SV allows 
to have package names be the same a module names, we have a potentially 
ambiguity with look up by hierarchical name if both top level modules and 
packages have the same name.
If something is declared in $root or in $unit, what is his fullname of a 
global thing or the fullname of a global thing living to a compilation 
unit? This is undefined at the moment.
Can vpi_handle_by_name return handles to things defined in the global name 
space of a compilation unit?
Can vpi_handle_by_name found imported items from a scope handle to a module 
importing the package. I would expect that the answer is no, since the 
imported item is not declared in the module but is just imported.
Can we resolve these issues?
Francoise
'
To: sv-cc@eda.org Subject: [sv-cc] New erratas on Vpi
Section 31.12 Typespec
Why do we have a var bit typespec , it does not make any sense.
This should be removed
the property vpiTagged should not be a string property but a boolean property
Note 3 and 17 should refer to section 31.22 instead of 31.21
There is an inconsistency between the description of the vpiArray property 
in the notes and the fact that this property is labeled array member in the 
diagram, I believe this is the result of the merg of the 1364 reg diagram 
and 1364 variables diagram.
We have to choose a meaning for vpiArray for now the variables diagrams 
which reprensent both regs and variables.
Additionally if you read notes 2 and 4, you would understand that a packed 
array variable has the vpiArray True. Therefore the note 11 is wrong 
because packed array variables have a value property. Only unpacked array 
variables do not have the value property.
Note 19 is incorrect:
bit var bit = reg bit
it should be var bit= reg bit
In fact this is not a strict equivalence, we should rather say the the 
vpiBitVar would be #defined the same as vpiRegBit for backward 
compatibility, and you should note that a vpiVarBit could be a 2 state 
scalar variable which is not a vpiRegBit since regs have 4 state values.
Note 20: we say that the vpiScalar property can be applied to a packed 
struct or union, but does this mean that it will return true of the packed 
union or struct has a single bit member?
At 02:08 PM 7/9/2004 -0400, Joao Geada wrote:
________________________________________________________________
The best thing to hit the Internet in years - Juno SpeedBand!
Surf the Web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!