Binding Requirements: transparency

Hi,

We have a set of questions meant to define the problem of mixed language 
binding between SV, VHDL, and SC.  We recently agreed that this is not a 
complete enough indication of the requirements to formulate a proposal.  
We need additional general requirements and a discussion of the 
questions and their implications.  I agreed to start that discussion and 
offer my view of those requirements.  It would be great if we had a 
glossary of common terms, but I will borrow terminology and hope it 
doesn't become confusing.  A requirement that I consider very important 
for us to have a shared vision on is transparency.

Transparency
------------
If I wish to use a design unit written in language A as a component 
instance in language B, as long as that design unit's interface is 
compatible, I should be able to do it in a completely transparent 
manner. First, that means I do not have to modify or decorate that 
design unit for it to be instantiate-able.  As author of the design 
unit, I can be oblivious about the language to be used to reference it. 
This is extremely important for legacy design components, but also going 
forward in general.  I do not have to know all the HDLs, just the ones 
that I am authoring code with.

If I am authoring a design in language B and I wish to instantiate that 
component that was written in language A, I need to write an appropriate 
instantiation statement in language B.  It should be completely 
transparent whether the component I am instantiating is actually written 
in language B or some other language.  In fact, my understanding of the 
component interface can be conveyed to me via an equivalent interface in 
language B, my language.  I do not need to be an expert in language A ; 
I do not even need to know it.  I only need to know what it means to me 
expressed in terms of the language I know.

The key to achieving transparency is defining the rules for 
compatibility and understanding how to reference things. For 
instantiating design units, it is defining what are the compatible types 
for parameters and ports between the languages.  I use the term 
parameter and port, but each HDL has specific terms for what can be 
"connected to"  via instantiation and how parameterizable it is.  For a 
parameter, it includes types as well elaboration time constants.  For 
connections, it includes what the nature of the port is, e.g., a 
variable, a signal, a net,  or a reg.  It is a sure thing that some 
types and kinds will have no reasonable equivalent in a another 
language, but many will. This is a significant topic to be discussed 
separately.

There is a potential utopia that says if I have a compatible design unit 
in language A, I can configure and instantiate with any of the 
mechanisms available in language B.   It is acceptable to restrict the 
mechanisms in language B that will be allowed based on reasonable use 
models, but we should understand that is a priority call and not based 
on a technical restriction. I don't favor doing that.  I prefer we 
describe the technically viable mechanisms, even if they appear not to 
have strong use cases.  We can call them optional or that the spec has a 
different compliance level.  If we have to call them not allowed, we can 
establish, via informative documentation, that is not based on a 
technical reason.

I do expect other general requirements will imply an instantiation or 
configuration mechanism will be illegal for mixed language.  For 
example, using defparams to define elaboration time parameter values in 
a vhdl component instance should never be allowed.


Implications on Namespace
-------------------------
If I name a module or component and its parameters and ports, I must be 
able to refer to them by name in another language to achieve the desired 
transparency.  One has to reconcile the rules for constructing 
identifiers in each language. VHDL is case-insensitive; SV and SC are 
case sensitive.  There is an mechanism in both SV and VHDL, but not SC, 
for escaped identifiers that relax the rules for legal identifiers and 
allow almost any string to be used as an identifier.  There is a great 
deal of historical support for mixed language design with Verilog and 
VHDL for answering the question of how do I refer to an object named 
"foo" in another language.   After we explore that history, we establish 
rules that maximize the transparency and usability of mixed language tools.

With respect to transparency, it is desirable that the largest set of 
names be directly usable as an identifier across all these languages.  
If a legal identifier in one language is illegal in another language, it 
can only be referenced as an escaped name.  If that language has no 
escaped name mechanism, it cannot be referenced.  With respect to case 
insensitive references from VHDL to objects in a different language, 
VHDL must continue to handle identifiers in a case insensitive manner.  
Therefore it will be possible to construct a design unit that is well 
formed with no name conflicts in SV or SC, but would fail to be correct 
in a case-insensitive analysis.  For example, port or parameter names 
that differ in case only create such this issue.  It is possible for 
many, if not all, of these cases to recognize the name conflict and 
define rules that employ escaped names to insure the VHDL references are 
properly disambiguated.

All the rules that deal with cases of illegal or conflicting names have 
the effect to erode the complete transparency that is desired. It is 
necessary to have them, so that when design units cannot be changed and 
give rise to conflicts, they may still be used transparently. It may be 
a little more difficult to simply inspect the design definition and 
manually construct the equivalent abstraction for the other language.  
It will remain trivial for tools to provide aids that apply all the 
rules correctly for you and give you the transparent view that you need 
to understand. This should only happen in narrow use cases anyway as the 
majority of uses will be simple and transparent with respect to names.

Regards, John



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.