Hi,
Last meeting did not have a quorum, but we did review this document.
I've updated it below to note:
1) The recommendation that this be a future requirement, i.e., that
there is no need to meet it in the first mixed language
interoperability specification.
2) An additional use case, namely passing SV interfaces down the
hierarchy as opaque types. It was reported that customer feedback has
requested such a feature.
Regards, John
------------------------
Introduction
--------------
This is regarded as a future requirement for the SV-XC mixed language
interoperability specification.
We do not need it immediately, but this is discussion of the issues and
the details that must be considered.
Background
----------------
Based on our current SV-XC requirements and an understanding of the type
system in SV, VHDL, and SC, it is clear there are going to be
incompatible types of objects between the languages. One very
reasonable model of handling them is to say that incompatible types just
can't appear at the language boundary. If there is a need to do so,
then the owner of the object must convert the type in some user-defined,
application specific manner to a compatible type. The benefit of that
conversion includes the ability to work with the converted compatible
type, to read/write its value, perform operations on the data, etc. The
compromise is that there will likely be loss of information in the
conversion, or loss of ability to maintain invariants supported by the
original type. A good example might be a class in SV converted to a
record in VHDL by copying data members. In SV, I could only affect the
object through its public methods, which may guarantee some relationship
between values of data members is never violated. In VHDL, I can break
that relationship capriciously. Of course, I could do a "good job" of
providing a functional interface to the record that helped maintain
semantic invariants of the original class, too. Regardless it is no
longer a natively supported invariant of the type.
The fact that incompatible types can't appear at the language boundary
is the status-quo for SV-XC and the compromise it presents is
reasonable.
Is it acceptable to say that incompatible types just can't appear at the
language boundary? If so, the only way left to deal with them is to
extend the type systems appropriately so that more compatibility between
types is enabled. That is a difficult, long lead time proposition at
best, but certainly it is possible and will happen over time for some
important types. What if it were possible to declare a type that was
compatible with any type, but only with a use model restricted to
propagating connections through the design hierarchy? The first question
is whether there are important use cases that such a feature would
enable.
Important Use Cases
--------------------------------
Consider a case where a SV design unit wishes to pass a class object
down the hierarchy to leaf level SV instances. If there is any
intermediate VHDL models through which this must be passed, they may
have no need to interact with that object, but they would have a
responsibility to pass it through the hierarchy to their children. If
they do need to interact with it, they will need an SV child instance to
accept it and convert it to something they can handle. But regardless,
they still need to pass it further down the hierarchy with its full
semantic meaning and integrity. (I'll note the use case may also exist
in scenarios with SV/SC and SC-VHDL).
Is this an important use case? One conceptual model for it may be an
environment class that all objects interacting with a testbench must
have. An oft used model for access in Verilog is hierarchical reference
and it is unclear when such an object must really be passed through the
model hierarchy. Let's assume this is an important case.
Another similar use case exists for SV interfaces being passed down he
hierarchy.
These represent a connection abstraction and the ability to instantiate
components
that use formal interfaces would depend on this mechanism. We also
assume this
is an important use case.
If anyone would care to elaborate on this or other use cases that are
expected to be important, it will help with the evaluation of the opaque
type requirement. This will be a critical aspect of gaining support
even if SV-XC itself needs no further convincing.
Analysis and Elaboration Considerations
-------------------------------------------------------
Let us begin with the idea that only a formal port may be declared to be
of an opaque type. It can only be referenced as the actual connection
to another formal port in an instantiation statement. You may connect
any object to this opaque formal port in a parent's instantiation
statement including another opaque formal port. You may connect an
opaque formal port to another design unit port of any type.
One can say a simple thing about such an opaque typed object. It must
convey a reference to an object through the hierarchy such that when an
opaque port that is connected to a concrete object above it in the
hierarchy is finally connected to another concrete port below it, the
final port is fully aware of all the details of the concrete object it
is connected to. The connection of the two actual typed objects
involved must be semantically valid. Is that enough?
What happens when a concrete typed object, the actual or hiconn, from
language A is passed to an opaque typed port, the formal or lowconn, of
language B. The instantiation statement is written in language A. What
are the analysis considerations in language A?
In elaborated design, the concrete actual may be conveyed by value or by
reference, depending on its type. It may only be read or provide values
(e.g., current value and driving value of a signal), depending on its
type and object kind, or it may be written or driven. If the concrete
actual may only be read, analysis can recognize an illegal connection to
a formal port when that port declares a direction, out or inout,
implying that it will write a value or drive a signal. There is a
similar case when the actual may only be written. There are potential
restrictions on the number of writers. An unresolved signal in VHDL may
only have one writer, for example.
In general, where the formal port indicates how it will access an actual
connected to it and when the actual has access restrictions, there is a
semantic analysis that must take place to determine correctness. If
language A requires the prototype of the design unit to be visible for
such analysis, it is an analysis time semantic check. If not, it is an
elaboration time semantic check. Even if it is an elaboration time
check, a further consideration is whether the semantic analysis is
expected to be local or global across the design hierarchy. By local,
it is meant that the actual object type and kind and the formal port
type and kind it is connected to have enough information to perform a
semantic check. By global it is meant that the entire hierarchical
structure of the connections that make up this net must be elaborated
before the semantic check can be made. Many of these port connection
rules checked at elaboration are expected to be local and arguably will
benefit from being local.
What happens when a opaque typed object, the actual or hiconn, from
language B is passed to an concrete typed port, the formal or lowconn,
of language A. The instantiation statement is written in language B.
What are the analysis considerations in language B?
It is really not conceptually different from the first case. The formal
is a concrete type which indicates direction, pass by value of reference
semantics, signal or variable semantics, and associated connection
rules. You know little about the actual (as we've defined things so far
anyway). The first case was just the reverse. You can't do analysis
until you know something about the opaque type or the context of the
object that has that type. So far, one may never know enough at
analysis time and at elaboration time whatever you need to know may
depend on non-local information.
I suggest that is an unacceptable scenario. If we follow our existing
requirements, we do not intend to define an SV-XC specification that
requires change to the model of analysis and elaboration in existing
languages. We further wish to guarantee strong typing rules across
languages will not be weakened by virtue of mixed language connections.
Some of these semantic checks are done at analysis time or as local
elaboration analysis. In particular, VHDL defines a one pass
elaboration model that would expect connection rules to be checked
locally.
This is not a proposal for how to declare and opaque port types in SV,
VHDL, and SC, but an exploration of requirements. Such a proposal is
required to convey information that would support local checking of pass
by value or reference semantics, signal or variable semantics, and
associated connection rules for multiplicity and access restriction.
Let's now expand on the initial idea and consider allowing local
declarations of opaque objects. What is the use case for a locally
declared opaque object? The implication is that you would have to be
able to initialize it and/or assign a value to it. If the proposition
is that an opaque type is intended to be a reference to a type
unrepresentable in the language, then a locally declared opaque type
object would ultimately receive its value by assignment from an opaque
type port. Is that valuable? One could assign an opaque type object to
another opaque type object. Ultimately, one would make a port connection
of that opaque type object. Are there any other valid operations on an
opaque object? I would suggest there are not. The only operations that
would be valid are ones on the underlying concrete type and such
operations exist only in the language of the concrete type, not the
language where the opaque object is declared. In fact, I suggest the
assignment to a local opaque object would only have the semantics of a
port connection. Indeed, the semantics checks of the validity of the
assignment, e.g., whether an opaque object can be validly read or
written, is analogous to semantic checks on whether a port connection is
valid or not. Such checks are typically made at analysis time and would
require additional information defined in the declaration of the opaque
typed object to support it.
Now it is possible that a language would define its opaque type such
that an object of a concrete type in the same language could be
connected to it. What is the use case for that? Whatever it is, could it
not be satisfied by parameterized types? For that matter, what does
that use case have to do with mixed language needs? I suggest that this
is not a requirement for mixed language specification, but may happen to
fall out of adding opaque types as another implication.
Other Implications
------------------
It is important to say explicitly that opaque types are an extension to
each language. If language A wishes to pass an unrepresentable type
through language B, it is language B that must add a opaque type to its
language and define the supporting connection rules. In addition, SV-XC
specifications for language A instantiation of a design unit in language
B must state the validity of connections of objects of its concrete
types to B's opaque type port and define mixed language connection rules
of its own, as appropriate.
Language B may have its own additional considerations for an opaque type
that transcend this mixed language issue. An example is VHDL-AMS has a
desire to support the ability to exchange an a design unit that is a
discrete model abstraction (i.e., a pure digital model), for its
equivalent one modeled as a continuous abstraction(i.e., an analog or
mixed signal model). If it were true that the entity declaration of the
2 models was the same, and the architecture representing each model is
where all the differences are, it is a trivial use case. If the
differences appear as ports that are signals in one case and terminals
or quantities in the other, this involves rewrite of the instantiation.
There is a desire in VHDL-AMS to have a "wire" port that would allow any
kind of connection. At elaboration, the final nature of the net and the
insertion of conversions (D2A or A2D) would be handled.
Language B may wish to restrict the use of opaque types so that they
only apply to a foreign connection or allow opaque types to be more
broadly used within the language. Such considerations are not part of
the basic use case that SV-XC wishes to enable and are not requirements
that SV-XC will make on SV, VHDL, or SC.
The point is that the standards group responsible for the specific core
language need to be presented with only the essential mixed language
requirements and, most likely, a straw proposal for an opaque type for
its consideration. It would be very useful for those requirements to
include the use cases intended to be satisfied by the result.
Proposed General Requirements for Opaque Type Support
------------------------------------------------------------------------------
For SV, VHDL, and SC, the following general requirements apply to
support connections through a mixed language design hierarchy where the
type of the object being passed through the design hierarchy cannot be
represented in the language of one of the design instances:
*the ability to declare a port of an opaque type for a design unit that
would accept a connection to an object of any type.
*the ability to declare a local object of an opaque type and initialize
it from another compatible object of an opaque type.
*the ability to assign an object of an opaque type to/from another
compatible object of a opaque type, subject to locally checkable
constraints.
In other words, not only are the final concrete type of both objects
involved with not
*the ability to connect an object of an opaque type to a compatible port
of an opaque type.
*the ability to complete a connection across design hierarchy from an
object of some concrete type to another object of a compatible type,
where the intermediate ports involved in the connection are of an opaque
type.
*the continued ability to check the correctness of a connection of an
object to a port locally at the point where the declarations of the
object and port are known according to the language in which the
instantiation appears. That is a mouthful, but the point is that even
if the type of the object and/or port is opaque, some basic connection
rules should be checkable. These include direction of and multiplicity
of assignment, pass by reference or value semantics. The fundamental
idea is serious structural flaws normally checked locally at analysis
time or at elaboration based on local information about the structure
continue to be checkable locally.
*In no case do the semantics of connections rules in a language lead to
erroneous designs because they can no longer be enforced when opaque
type objects are involved.
*No operations or reading/writing of the "value" or properties of an
object of an opaque type are possible other than port connection or
assignment of one opaque type object to another compatible opaque type
object.
*It shall be illegal to cast an object of an opaque type to a specific
concrete type. The rationale is that this either allows operations
which may be semantically invalid or amounts to RTTI of an equivalent
type in the language where the cast operation takes place. This
conflicts with underlying essence of the opaque type which is intended
to allow conveying unrepresentable types across the design hierarchy.
*the opaque type does not imply that objects of any kind may now be
connected to ports. In language A, if you cannot connect a variable to
a port because ports can only be signals, well, you still can't connect
a variable to a port in an instantiation statement in language A. It
does not matter that the port is an opaque type. This mechanism does
not allow you to connect a variable of a concrete type in language A
through the hierarchy via opaque port types to a variable of a
compatible type in language A. You never could pass variables through
ports in language A and you still can't.
Further Action
-------------------
It is not clear yet that an opaque type can be added to one language
without considering the individual connections rules of all three of
these languages together first.
A proposal for a specific language addition of the opaque type must
analyze all the existing connection rules in that language associated
with ports to determine what information must be declared for a port of
an opaque type to support semantic checks at the instantiation boundary.
In addition, a detailed requirement associated with a connection in a
foreign language may require addition information about a port of an
opaque type.
The required information may be conveyed syntactically by existing
grammar, e.g., port direction, or may be added though additional port
attributes or as the result of defining multiple opaque types that imply
the desired information.
If any connection rule implies that information that qualifies the
opaque type must come from the foreign language, this detailed
requirement must be forwarded to that language.
--
This message has been scanned for viruses and
dangerous content by
MailScanner, and is
believed to be clean.
Received on Tue Nov 13 16:07:42 2007