SV-XC opaque type requirements

Hi,

In SV-XC discussions, there has been a suggestion that it would be 
valuable if the languages supported an opaque type such that mixed 
language connections could be made from a concrete type in one language 
that has no representation in the other language.  While no operations 
could be done with an object of an opaque type except "connection", it 
could eventually be connected to a child instance in the language of the 
original concrete type( or any other language for which a compatible 
type exists).   This document elaborates on the idea and its 
implications, so that we may consider whether this should be an SV-XC 
requirement and whether more detailed work should be taken up.

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.

An Important Use Case
---------------------
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.

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.