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

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:
Received on Wed Jul 14 09:13:06 2004