Re: Binding Requirements: transparency

John Shields wrote:
> 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.
I agree with your view on the need for "transparency". I had a similar 
requirement when designing Verilog-AMS, i.e. the analog designers should 
be able to design analog modules and the digital designers digital 
modules and neither should be required to know how the other's stuff 
worked; the job of creating  the components that stitch the AMS design 
together could be done by a third party (a CAD engineer or automated 
tool) who is expert in neither analog or digital design.

I'm fairly sure the concepts in Verilog-AMS can be generalized for 
binding SV, VHDL, and SC. I'm not entirely sure where the extra data 
about how to stitch designs together should go, but given that SC is 
just C++ I think we should probably look at what kind of databases are 
freely available that would serve the purpose that have C/C++ APIs, and 
we should probably look at doing it in XML for Spirit compatibility - 
though I'm no XML/Spirit expert and it has been a while since I worked 
with relational databases (anybody familiar with OpenAccess?).

Kev.
>
> 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.