> 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.Received on Wed Mar 7 15:18:15 2007
This archive was generated by hypermail 2.1.8 : Wed Mar 07 2007 - 15:18:22 PST