Re: FW: Questions about binding

Kevin,

Thanks for your feedback and opinions.  Since you were unsure about 
question 4, order of compilation, I'll elaborate.  Some languages 
require you to define something before you reference it.  In VHDL, for 
example, you must analyze a package before you can use it in another 
design unit.  In general, you must compile dependent design units before 
the design unit that depends on them.  Additional compilation order 
rules may apply to mixed languages.  Consider the related possibility of 
a SV package that could be shared, i.e., used in VHDL.  If we allow it, 
that probably implies that the SV package must be compiled before the 
VHDL design that depends on it.  Also, we may require order of 
compilation for other scenarios, where our intent is to allow various 
ways of implementing interoperability. For example, if you were going to 
allow references to things in a foreign design unit to be equivalent to 
a translation of that design unit to an equivalent model and define it 
as such, then you might also specify a compilation order.  That would 
allow an implementation to generate the equivalent model automatically, 
even though that is not the only way one might do it.  Anyway, that is 
the motivation behind asking the question.  (And, I am not interested in 
the answer immediately :)

You asked a direct question in 7).  The answer is, we (the sv-xc 
committee) are.  The point is, that we are not doing it now and I don't 
need to know the definition yet.  It is an important and related issue, 
but orthogonal.

Regards, John

Kevin Cameron wrote:
>
>> John Shields wrote:
>> With respect to instantiation and binding among SV, VHDL, and SC, 
>> some assumptions will help to frame the questions and separate issues 
>> that are otherwise closely related.  First, I assume that a design 
>> unit from one language that satisfies an instantiation in another is 
>> compatible.  For that to be true, the ports and parameterization of 
>> that design unit must be compatible in kind and type.  By kind, I 
>> mean whether it is a signal, variable, constant, type, etc. and by 
>> type I am refering to the data type,e.g., integer, real, string, 
>> wire, std_logic, etc.  A further characterization of type compatible 
>> is 2 types may be compatible if they are structurally equivalent, or 
>> by virtue of strong typing rules (refering to same single type in 
>> each language, for example), or perhaps by implicit conversion 
>> rules.  If an explicit type conversion is required, then without such 
>> conversion, the types are not compatible.
> I think that "binding" also probably needs to be split into separate 
> phases:
>
>    1. Selecting something to instantiate (a language neutral activity?)
>    2. Parameter transfer  - mostly copying static data
>    3. Instantiation - actually creating something
>    4. Port/reference binding - connecting up drivers & receivers, 
> shared data etc.
>
> Note: for AMS 1 & 2 could be swapped if /paramsets /are used since the 
> parameters are used to select the module to instantiate, but I think 
> we can assume it would be preferable to just put a wrapper around that 
> on the AMS side.
>>
>> The above assumptions are not meant to define what is compatible with 
>> respect to types, kinds, and design units.  It is just a definitions 
>> of terms and a separate of the issue of compatibility details from 
>> instantiation and binding.
>>
>> Some initial questions to define the binding and instantiation problem:
> My opinions below...
>>
>> 1) What is the basic boundary between languages, i.e., are design 
>> units expected to be written entirely in the same language or can 
>> foreign language constructs be used directly within a design unit?
> We should not consider foreign language constructs.
>>
>> 2) Are there any restrictions  on the final structure of a mixed 
>> language elaborated design? May any instance be a design unit from 
>> any other language?
> Very likely. Yes.
>>
>> 3) In all languages, design units are compiled into libraries and 
>> subsequently, a design may be elaborated from these design units.  
>> Are there any restrictions on the composition of a library with 
>> respect to the kinds/language of design units it may contain?
> No, can't see why you would restrict the library contents, but 
> usage/access might be limited.
>> 4) What order of compilation rules apply in a mixed language context?
> Not sure what you mean by that, but I think mixed-language compilation 
> will be somewhat more modular - i.e. separate compilation to libraries 
> and then configuration/elaboration from the libraries.
>>
>> 5) With respect to each language, what are the design units of that 
>> language and which may be instantiated in which other language?
>> /For example, A VHDL primary design unit may be a package header, an 
>> entity, or a configuration.  Package bodies and architectures are 
>> secondary design units in VHDL.  A VHDL instance is either a package 
>> instance( header plus body, if any) or a component instantiation ( 
>> entity/architecture pair).
>> /
> Not sure there's any syntax outside of VHDL to instantiate anything 
> but an entity/architecture pair (module).
>>
>> 6) With respect to each language, what are the forms of instantiation 
>> of a design unit in that language and which forms are suitable for 
>> instantiation of foreign design unit?
>> /For example, in VHDL, a package use clause implies package 
>> instantiation and components may be instantiated by direct e/a 
>> instantiation, a component instantiation, or a configuration 
>> instantiation.  A component instantiation may be configured by a 
>> component specification, a default binding rule, or an external 
>> configuration.
>> /
> I think if you are going to use VHDL at all it seems likely that you 
> would want to use it for configuration, things that you can 
> instantiate in other languages mostly look like e/a pairs (modules).
>> /
>> 7) /Each language supports parameterization of design units and 
>> mechanisms to bind those parameters to static values at elaboration.  
>> What are the forms of declaring the parameterization of a design unit 
>> in each language?  What are the mechanisms by which such parameters 
>> may be bound in each language?  What binding mechanisms with what 
>> restrictions can be applied to an instance bound to a foreign design 
>> unit?
> I think Verilog is fairly sloppy on matching up parameters, so we 
> probably need to concentrate on how mismatches are handled. I'd say 
> defparam shouldn't work across languages and all parameter/port 
> connections should be by name (bearing in mind VHDL is case insensitive).
>> /Note, there is an assumption of compatible parameters in kind and 
>> type already that will be defined separately.
>> /
> Who's doing that?
>> /
>> /8) ...questions about finer grained cross-language access within 
>> design units, hier refs, function,procedure, class methods calls need 
>> to be considered...
> True :-)
>
> Kev.
>>
>> Regards, John/
>> /

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