John, Thanks for your inputs. Before offering use cases, I would like to share some of my thoughts on the transparency requirement of binding Firstly I believe we are coming up with generic requirements that any binding proposal must meet while attempting to address the binding questions. In that context my first concern stems from the following Para: >>>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 My concern here originally was: Are we attempting to discount some use models as illegal right in the requirements itself ? I am not averse to the idea, but if so I would be happier to see a semantic generalization of the illegal use models rather than specific references to some of them, in the requirements.For example, a generic Para in the requirements (such as the following), would be something I would look for if I were to be the proposer of the binding interoperability functionality. "Ensuring binding transparency throws up a number of use models that could potentially break binding semantics of the native languages. Such use models if any are illegal. The binding proposal must however highlight such use models and open it up for discussion. For instance the elaboration order protocol of VHDL must be honored by the interoperability proposal" We could capture other such semantic requirements that an interoperability proposal is likely to violate and ensure that any binding proposal addresses them clearly. Please note that I am not attempting to suggest the technical point in the above example. Rather I would like that the requirements define clearly the boundaries( if any )in which the proposer should operate. At the same time, I think we should take care to ensure that the requirements do not over constrain the proposer of the binding interoperability functionality. I think the interoperability user is looking to complement the strengths of the different languages rather than get tied down to their weaknesses. From that perspective I would like that the proposer brings the interesting use models to the table and the committee then decides whether it is technically viable or not. In our last meeting we agreed that the requirements will not identify illegal use models. So, that addresses my above concern. Here are related industry use cases in the AMS space. 1) In this use case the user overrides a verilog-ams module parameter using a out of module access of a design variable. Design variable declaration: ---------------------------- module globals; [...] dynamicparam real r_desVar = 100k; endmodule top-level instance (Verilog-AMS): --------------------------------- res #(.r(globals.r_desVar)) R_desVar ( out_desVar, globals.\gnd! ); -------------------- Verilog-AMS module: ------------------- module res ( PLUS, MINUS ); parameter real r = 1K; res_vhd #(.r (r) ) R0 ( PLUS, MINUS ); endmodule // res Leaf-level VHDL-AMS: --------------------- entity res_vhd is generic ( R : real := 0.0; ); . 2) A slightly modified use case may require that globals.r_desVar be overridden by a defparam 3) A further transparent requirement may be to override the VHDL generic directly instead of propagating the value through the hierarchy. In my opinion all the 3 uses cases cause a problem to the VHDL elaboration model. So if we choose to make one use model illegal, we perhaps will be forced to make the others illegal too. thanks and regards, nss ________________________________ From: John Shields [mailto:John_Shields@mentor.com] Sent: Wednesday, May 23, 2007 5:41 AM To: N.S. Subramanian Cc: sv-xc@eda.org Subject: Re: FW: Binding Requirements: transparency Hi NSS, I think you are planning to offer some use cases that may be important, is that correct? I want to address your vhdl-200x comment. First, in VHDL you define the value of generic in a generic map. That value expression is an expression that may be a function of other generics defined above and passed down the elaboration hierarchy as well other static values that may form that expression. All you may do in 200x with respect to external names is refer to static object that has been elaborated already in the value expression. In other words, from the generic map you may reach out and above to reference a constant in the value expression. This is not a parameter override mechanism. That is not similar to defparams, which reach in from anywhere to override the Verilog equivalent of a generic map, or if not present, the default value of a parameter. Even if you restricted them so they were not exactly "from anywhere", it would still change the VHDL elaboration model. Before saying more, I am interested to know if there is a relevant use case. Regards, John N.S. Subramanian wrote: -----Original Message----- From: N.S. Subramanian Sent: Wednesday, May 16, 2007 4:29 PM To: 'John Shields' Cc: N.S. Subramanian Subject: RE: Binding Requirements: transparency John, I had one concern about why we should not permit defparams to override VHDL generics. The VHDL-200X allows overriding of generics using external names in generic maps and I believe defparam attempts to do something similar. With some restrictions in elaboration order, we might be able to provide this powerful functionality transparently to VHDL instances. Perhaps we could discuss this in the meeting today. thanks and regards, nss -----Original Message----- From: owner-sv-xc@eda.org [mailto:owner-sv-xc@eda.org] On Behalf Of John Shields Sent: Tuesday, April 24, 2007 6:53 AM To: sv-xc@eda.org Subject: 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed May 23 03:13:26 2007
This archive was generated by hypermail 2.1.8 : Wed May 23 2007 - 03:13:29 PDT