[sv-bc] VPI model issues on interfaces


Subject: [sv-bc] VPI model issues on interfaces
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Feb 03 2004 - 14:41:37 PST


Instance diagram
-~-~-~-~-~-~-~-~-~-~

defparam should only be available for modules since it is deprecated in SV
Why are interface and interface arrays iterations common to instances? Can
you have
interfaces in packages?

Interface
-~-~-~-~-~-~-~-~-~-~
why iteration on modpath from interfaces, do we have specify blocks inside
an interface?
It does not look like we have specify blocks declared in interfaces.
However there is a section in the interface chapter which states that
specify blocks inside module can refer to an interface signal accoding to
the direction provided by the modport.
It does not mean that specify blocks can be inside interfaces. In fact the
formal bnf disallows it.
I think that the modpath IEEE diagram needs to be modified to show that a
path term expr can be an interface signal.
Intermodpath diagram needs to also be modified to show interface signals. I
am not sure how though.

Interface tf decl
-~-~-~-~-~-~-~-~-~-~

should interface tf decl be eliminated as there are not iterations leading
to it from the interface class or from anywhere? Unless it is meant to be
tf_decl since it appears in the IO decl diagram 30.15?
I think we only return the tf decl which appears as io decl in modport. The
reason for this is because they represent the tf prototype declaration for
which there may be multiple implementations.
May be the name tf decl or interface tf decl could be changed.

modport:
-~-~-~-~-~-~-~-~-~-~
should relation from modport to interface be named vpiInstance like in the
interface diagram?



This archive was generated by hypermail 2b28 : Tue Feb 03 2004 - 14:48:01 PST