Hi NSS,
-----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 archive was generated by hypermail 2.1.8 : Tue May 22 2007 - 17:22:59 PDT