=============================================================================== 1076.1 Ballot Resolution Commitee Comment Resolution Report ------------------------------------------------------------------------------- CRR Number: 12 Topic Addressed: Ports and mixed connections Related CRs: 12 (Ken Kundert, Cadence, affirmative) 55, 73, 75 (Garland J. Bayley, Analogy, negative) 113 (Dan Damon, Mentor Graphics, affirmative) 155, 160 (Steven Greenberg, Analogy, negative changed to affirmative) 210 (John A. Eldon, Raytheon Electronics, affirmative) 223 (Steffen Rochel, Simplex Solutions, affirmative) 241, 242 (Ken Kundert, Cadence, negative) Relevant LRM Sections: Resolution Status: Partly in review by balloters =============================================================================== Comment Reports Summary ~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- CR012 I believe that VHDL-AMS is a reasonable language for the description of systems at an abstract level. However, it is a fact that as one refines the level of representation of various blocks, the ports often must change type. For example, from signal flow to conservative; or from event-driven to continuous time. VHDL-AMS enforces unreasonable and burdensome restrictions on how the user can connect ports at different levels of abstraction. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ I feel that VHDL-AMS must support 1. direct interconnection of signal-flow and conservative ports. 2. automatic insertion of A->D and D->A converters when connecting ports with event-driven and continuous time semantics. ---------------------------------------------------------------------- CR055 Analog values are communicated through terminals with a nature. Digital values are communicated through signals with a type. They cannot be mixed! In Verilog you can specify module dig_bus ( dbus ); tri dbus [1:2]; In Verilog-A you can specify module ana_bus ( abus ); electrical abus[1:2]; These languages as yet do not have a way to bundle these, but it is not hard to imagine that they can be easily extended in a fashion similar to C in Verilog-AMS. For example: module mix_bundle ( mbun ); struct { tri dbus [1:2]; electrical abus [1:2]; } mbun; With the separation of declarations by types and natures, VHDL has no possibility of allowing such natural usage of the language. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Merge natures into types. Make a way within the type system to distinguish analog types from digital types. Drop terminals and be able to distinguish analog and digital signal portions by their type declaration. ---------------------------------------------------------------------- CR073 The paragraph from line 1823 to 1831 says that the effective values of ports (including terminal ports) are set to a value. This is inconsistent with the notion that terminals have no value. Line 1910 indicates that terminals of a subnature that have no value can be initialized with a value from and initialization expression. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Get rid of natures and terminals. ---------------------------------------------------------------------- CR075 Line 1870 says that only quantities of mode out can be left unassociated. However, beginning at line 1825 the document defines what to do with an unassociated quantity of mode in. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Change 1870 to mode say mode in? ---------------------------------------------------------------------- CR113 Users want to connect signals and quantities directly. Currently a connection between analog and digital is done by manually inserting an A/D or D/A element. Most companies such as Mentor Graphics will probably provide an automated way to accomplish this. Unfortunately VHDL-AMS competes with Verilog-AMS which does have this capability. The automatic data conversion of Verilog is one of the many things that make it easier to use - therefore more popular. I have heard many times that strong type casting is a good thing, but I have yet to see an example that illustrates why this is so. People who use this tool are electrical engineers, not computer programmers. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Provide a mechanism for automatic conversion from one data type to another. ---------------------------------------------------------------------- CR155 There is no discussion in this section of the words "in" and "out" when applied to the interface_quantity_declaration. Since the the non-terminal "mode" was not used in the definition, I assume that the terminals "in" and "out" are not modes. Thus anything said about modes does not apply. Quantities are specifically not in the list of the class of objects for which the "mode" is later discussed. On the other hand, section 4.3.2.2 does call the terminal "in" a mode. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Add a discussion in section 4.3.2 of the "in" and "out" items in the interface_quantity_declaration. ---------------------------------------------------------------------- CR160 In section 12.2.4 second paragraph, I find the words "If a given port is a port of mode in whose declaration includes a default expression, and if no association element associates a signal, quantity, or expression, then the default expression is evaluated and the effective value of the port and the driving value of the port (if the port is a signal port) is set to the value of the default expression. In section 12.2.5 note 3 "Only interface quantites with mode out can be left unassociated" It appears to me that section 12.2.4 is telling what to do with an interface quantity of mode in that is unassociated and section 12.2.5 is saying that such a situation cannot exist. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Note 3 in section 12.2.5 should be removed. The constraints that caused this note to be written need to be redone. ---------------------------------------------------------------------- CR210 Although I am voting to approve IEEE Project 1076.1, and although I admit I'm biased towards Verilog, I believe VHDL should provide automatic conversion of data types, to allow users to connect signals and quantities directly. Adapting this user-friendly Verilog feature into VHDL would permit users to write more efficient, streamlined code, without compromising the integrity of the language. ---------------------------------------------------------------------- CR223 The configuration mechanism in the draft LRM is not modified to support a flexible mechanism to change between different abstraction levels for design units, especially to switch between digital and analog representation. Necessary converter elements have to be added manually or by an external design environment, which limits the portability of a design description. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ From my point of view a conversion mechanism between digital signals and analog terminals (as well as vice versa) has to become part of the configuration mechanism in the extended VHDL LRM. ---------------------------------------------------------------------- CR241 A fundamental contribution of VHDL is the Entity/Architecture concept. It provides the ability to include multiple models for each block in a single textual description, and then to configure the various models into different representations for the same design. Another important feature of VHDL is its strong typing. Unfortunately, the strong typing of VHDL reduces its ability to support multiple configurations because the type of the ports for every architecture must be the same as in the entity. This is a minor issue in a purely event-driven sirnulator, however it is devastating for a mixed-signal simulator. The fact that continuous-time and event-driven signals are of different type means that a they cannot share the same entity port. Thus an "analog" architecture and a "digital" architecture cannot share the same entity. The end result is that the current 1O76.1 proposal does not effectively support multiple configurations in a single description. Of course, this is not strictly true. The current proposal supports multiple configurations in exactly the same fashion as VHDL. However, the known limitations of VHDL are not addressed in this proposal, and those limitations effectively prevent support of multiple configurations for mixed-signal circuits. Thus, the current mixed-signal proposal fails to conform to the basic precepts of the original VHDL language. To overcome this limitation would require additional tools that either automatically insert interface elements or rewrite the descriptions. Either way, additional information is needed, and the form of that information is not the subject of this or any standard. The current proposal is incomplete, leaving us in basically the same place we started: without a portable descnption format for mixed-signal circuits. The electronics industry has a critical need for portable description formats for all types of circuits. The establishment of the Virtual Socket Interface (VSI) alliance and its support by so many companies is strong evidence of this fact. Endorsement of portable description formats is one of the primary goals of the VSI alliance. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Given the importance of a portable description format, and given that in practice, the current proposal does not support a basic precept of the original language, and finally given that DR-40, DO-1, and DO-32 all strongly suggest that this capability must be provided, it seems clear that we should not accept this proposal until this issue is addressed. The Verilog-AMS effort has solved the "automatic insertion of interface elements" problem. I propose that we incorporate that work into our 1076.1 proposal. ---------------------------------------------------------------------- CR242 The current proposal provides two types of analog ports, Quantities and Natures. Quantities support signal-flow semantics and Natures support conservation semantics. Unfortunately, in the current proposal, these two types of ports are incompatible, meaning that they cannot be directly connected. In a top-down design process, one starts with signal-flow descriptions of the various components. As the design progresses, the components are converted to conservative descriptions as the design of the components is refined. During most of the design process, part of the circuit is represented at the signal-flow level, and the rest is represented at the conservative level, with models from each level connected to each other. The problem with the current proposal is that since signal-flow ports cannot be directly connected to conservative ports, when a particular model is refined from the signal-fiow level to the conservative level, the model for each component that connects to it must also be rewritten. This represents a huge burden for the user. In fact, the burden is so great, that it will severely limit the amount of top-down design done with this language. Thus, the current proposal does not satisfy DR40 and DO-1, which clearly states that top-down design is a high priority and must be well supported. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ There were two proposals for the equation formulation method before the LDC. The probe/source proposal and the one incorporated in the existing proposal. Both formulations were found to be equally expressive for conservative relations, however the probe/source formulation had two clear advantages. First, the probe/source formulation is the one being used by Verilog-AMS. If it were also adopted by 1076.1, models developed for one could easily be ported to the other and if a user knew one language, it would be relatively easy to learn the other. Second, the probe/source formulation supports both signal-flow and conservative descriptions in a unified manner. In addition, with the probe/source formulation, signal-flow and conservative descriptions can be directly connected in a natural manner. This is clearly a very desirable feature, and the LDC spent quite some time trying to extend the existing proposal to provide this feature, without success. The question of which equation formulation method should be used was never properly decided. A vote was taken early in the process, and the results were inconclusive. This was before the probe/source formulation was completely mature, and before the real advantages of this formulation were known. After the initial vote, the issue was lost in the battle over the Jade and Opal proposals, and was never properly considered. I propose that we abandon the current equation formulation method in favor of the more powerful probe/source formulation This would eliminate the need for different types for signal-flow and conservative ports and would provide a certain degree of compatibility with Verilog-AMS. Finally, it would eliminate the seemingly arbitrary restrictions placed on the existing formulation method that were needed to support tolerances. =============================================================================== Analysis and Action Taken ~~~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- CR012, CR113, CR210, CR223, CR241, CR242 These ballot comments sound a similar and very important theme; the need for a mechanism to interconnect entities defined using different abstractions in their interfaces. The requirement dates to the earliest formulation of the requirements for a VHSIC Hardware Description Language. The mechanism designed in response to that requirement is largely unaltered from the earliest precursor of the current language, VHDL 7.2. It is the configuration specification and the slightly more powerful configuration declaration, to be used in conjunction with type conversions on the formal and actual parts of a signal association. The mechanism is explicit; there are no hidden or default type conversions in VHDL. On the other hand, the conversion code does not need to be replicated with each instantiation of a component, but can instead be part of a shared configuration declaration or configuration specification. Type conversions functions in associations integrate smoothly with resolution functions to resolve a single value for multiply driven nets. The explicit mechanism provided is limited. Associations can be many to one, or one to many, but not many to many. Conversion cannot include delay or memory (hysteresis). Finally, associations between objects of different kinds are forbidden (because only signals are allowed). Our investigations led to the conclusion that arbitrary conversions can be coded in the language as it stands. We where not successful in devising a syntactic shorthand for conversion logic. We concluded that any solution would require substantial changes to the base language. These results were presented and discussed at the 10th LDC meeting (see "Mixed Netlists" in appendix A). CR241 proposes that the conversion mechanism of Verilog-AMS be duplicated in VHDL-AMS, but the two base languages (Verilog and VHDL) are different in substantial ways that make it impossible to merely import features from one to the other. However, any solution will resemble Verilog-AMS in that the full modeling power of the extended language is required to handle all possible conversion cases. CR223 suggests that the configuration mechanism be extended to meet the new requirements. This possibility was not directly explored in our investigations; however, the extension of the conversion at association was investigated (Mixed Netlists 3.1.1 in appendix A). All of the comments with the exception of cr242 are concerned with analog to digital and digital to analog conversion. CR242 is concerned with the incompatibility between quantity and terminal ports. The objection is overcome by the simple expedient of not using quantity ports in a top-down design methodology whose target is a netlist of interconnected conservative ports. Interface quantities are designed for abstract modeling. In fact, Verilog-AMS has only conservative ports, but this fact is syntactly disguised in the case of monadic disciplines. The only difference is that VHDL-AMS requires the thorugh branch quantities hidden in Verilog-AMS to be explicitly declared. This seems a minor matter. When required, indirect connections between quantities and terminals can be readily accomodated using conversion logic (see Quantity/Terminal Associations, appendix A 3.2.2 and appendix B) that is a special case of the more general problem of mixed associations. CR242 expresses concern with what the balloter considers to be procedural mistakes in the conduct of the Language Definition Committee and offers a history to justify the claim. The existing language supports arbitrary conversions of the sort required, although it is not automatic or effortless. The conversion logic can be encapsulated in a "wrapper" design entity or included within the instantiating architecture. Rather than implementing any partial solution, we choose to delay adding features in this area until a comprehensive solution is worked out. Both the Verilog-AMS solution and the suggestion to extend the configuration mechanism should be investigated. The record does not support the balloter's version of events in CR242. As a recommendation for future revisions, the BRC suggests to devise a comprehensive conversion mechanism, encompassing all combinations of signal, terminal and quantity associations of arbitrary types and including memory and delay. ---------------------------------------------------------------------- CR055 VHDL already has a construct similar to the "struct" of the C language; that is, the record. But in VHDL, the elements of a record object are restricted to be of one "kind" (signal, variable, or constant)and (if the object is in the interface) one "mode" or direction (in, out and so on). To be consistent, we have limited terminal and quantity elements in a parallel fashion. The rule about mixing kinds in a record greatly simplifies the language, and the cost (not being able to mix signals and terminals in a record) is small, because you can always use separate interface elements. But why did we need new object kinds in the first place? Won't variables and signals do? After considerable thought, we found we had to introduced new object kinds. I say considerable thought, because it has always been our policy to reuse the existing language as much as possible before we begin thinking about adding new things. The reason for adding the quantity object is that it gets its value in a way that is not consistent with any existing object kind. A signal gets its value when a future scheduled event comes due; a variable gets its value when a process executes an assignment to it; once the value of a constant has been established during elaboration it cannot change. In contrast, the unknowns of a set of equations all get their values simultaneously at each time a solution is sought. The value of any given quantity is updated in a way dependent on every equation in the model, even if those equations don't talk about the quantity explicitly. A quantity object can be used as an interface element in a port list just like a signal, but a connection of one quantity to another is nothing like a conservative electrical connection that respects KVL and KCL. A quantity connection is a kind of dataflow connection, something like a signal-to-signal connection. We needed a new connection object to model a conservative connection, so we invented the terminal. We could, as the balloter suggests, drop the terminal in favor of a new class of distinguished signals with semantics different from the existing signals. For example, we could replace the word "terminal" everywhere with the phrase "analog signal". But an analog signal (in this new terminology) is very different from a signal. You can't schedule a new value or use its name in an expression, because it has no value by itself (only the quantities defined relative to it have values). You can't associate it with a regular signal in a port map because you have to introduce some kind of A/D or D/A converter (or both) to define what the association means. The separation between signals and terminals in VHDL-AMS is very similar to the separation of registers and nodes in Verilog-AMS. A nature (analogous to a discipline in Verilog-AMS) is a kind of supertype. It is built up of two subtypes, one for the across aspect and one for the through aspect. In this sense, it is already merged with the type system. Again, the choice of introducing the nature was not taken lightly because (as the balloter has noticed) it adds considerable complication to the language. But we needed to keep the defining classes of terminals separate from the classes of variables, signals, constants and quantities (all of which are characterized by types and subtypes). A regular type cannot be used for the doubled-up terminal, and the doubled-up terminal classes (natures) aren't applicable to the other objects. Giving both kinds of class definers the name "type" would have been confusing. We can take some comfort from the fact that the designers of Verilog-AMS came to the same conclusion. No definitional changes are contemplated at this time. ---------------------------------------------------------------------- CR073 The text at line 1823 bears on ports "... whose declaration includes a default expression." A terminal declaration may not include a default expression. The text at line 1826 characterizes the circumstance when "... a port of mode in is associated with an expression." Terminals do not have modes (and hence cannot be of mode "in"), and cannot be associated with expressions. The text at line 1909 is relevant when "...the object declaration includes an explicit initialization expression." A terminal declaration may not include an initialization expression. The text at line 1914 refers to "... any implicit default value...", but terminals do not have any implicit default value. The proposed resolution does not seem to be closely focused on the problem. The reasons for the existence of natures and terminals are discussed elsewhere, in the white papers in the response to comment CR55. The portions of the LRM that are causing the confusion are almost all from the original 1076 LRM. When read carefully, the problems sited by the reviewer can all be resolved satisfactorily. No changes to the LRM are contemplated consequent to this ballot comment. ---------------------------------------------------------------------- CR155 The balloter is correct is observing that the terminal symbols "in", "out", "buffer" and so on are not explicitly defined to be mode indicators. However, the production for the nonterminal mode implies as much. The use of "in|out" for quantities rather than the non-terminal "mode" in 1076.1 is paralleled by the use of "in" in the syntax for the interface constant declaration in VHDL 1076-1993. The reason in both cases is the same; not all modes are allowed. It would be more proper but perhaps more confusing to use the non-terminal in the syntax and then to restrict the allowed values by a static semantic rule in the text. The effect of the mode of a quantity interface element is described in 12.6.6. ---------------------------------------------------------------------- CR075, CR160 Note 3 in section 12.2.5 was an editing error left from a preliminary draft of this section. The content of section 12.2.5 has been moved to section 12.6.6 (the analog solver) and the notes of 12.2.5 added to the notes of 12.6.6, except note 3. ---------------------------------------------------------------------- =============================================================================== Revised Definitions ~~~~~~~~~~~~~~~~~~~ section 4.3.2 at line 991 (477) For an interface quantity declaration, the subtype indication must define a nature subtype. See section 12.6.6 for a discussion of the effect of modes in and out in an interface quantity declaration. current section 12.6.5 renumber to 12.6.6 at line 2558 (956) 4‹ Mode out on an interface quantity of a block indicates that this block provides one characteristic value corresponding to the quantity set of which this interface quantity is a member. 5‹ If none of the formals in a quantity set has mode out, then a characteristic value must be provided in the declarative region where the free quantity or unassociated interface quantity has been declared. =============================================================================== APPENDIX A: MIXED NETLIST WHITE PAPER Mixed Netlists Ernst Christen christen@analogy.com 1. Introduction The two new objects of VHDL 1076.1, quantity and terminal, can be used as interface elements in the extended language. A quantity may be part of the interface of a block or a subprogram. A terminal may be an interface element of a block. We now need a method to create hierarchical VHDL models using design entities with arbitrary combinations of signal, terminal and quantity ports in their interface lists. The LRM describes the semantics of signal associations in port maps. The Quantities paper does the same for both terminal associations and quantity associations. This paper addresses the issue of interfacing objects of different classes, for instance a signal and a terminal, in general and in the context of association lists. 2. Requirements 2.1 Requirements for Mixed Netlists The DOD contains a number of objectives related to the interface between a continuous object (a terminal or a quantity) and a discrete object (a signal). We believe that the same kind of objectives should apply to the interface between a terminal and a quantity. In many cases quantity ports and signal ports are abstractions of conservative connections, which in the 1076.1 language are described by terminal ports with appropriate reference terminals. The interface between different objects must therefore bridge different levels of abstraction, which requires the capability to describe arbitrary behavior at the interface. The following list of requirements for mixed netlists takes this into consideration. a) Support top-down design, by supporting the hierarchical decomposition of a model that includes interfaces between signals, terminals, and quantities. b) Support unidirectional interfaces (e.g. quantity -> terminal, terminal -> quantity) c) Support bidirectional interfaces (e.g. for a bus driver/receiver) d) Support modeling of such effects as input/output impedance, timing, current drive capability. e) DO12: The model of the interface between analog and digital descriptions should be customizable by the user. We extend this to also include the interface between terminals and quantities. f) DO32: Default conversions between analog and digital connection points should be provided. We extend this to also include the interface between terminals and quantities. DO33 through DO36 also deal with A/D and D/A interaction, but at the behavioral level. Therefore, they are not included here. 2.2 Requirements Analysis Several conclusions can be drawn from these requirements: Requirement a) suggests that each interface object can be interfaced to objects of three different object classes. Requirements b) and c) suggest that for each pair of objects to interface there are several cases to distinguish, e.g. signal -> terminal, terminal -> signal, signal <-> terminal. Requirements c), d) and e) suggest that it is not sufficient, in general, to only consider the two objects to be interfaced. The interface may need additional "information" in the form of parameters, power supplies, control signals. Requirement f) suggests that some interface mechanism should be built into the language. 3. Solution Possibilities It is important to remember that in VHDL 1076.1 nets, nodes and quantity sets are constructed by the association of ports. The definitions in these places require the association elements to satisfy certain criteria: the formal and actual must be of the same object kind, and they must be type or nature compatible. The requirements listed in section 2. suggest to allow mixed nets/nodes/quantity sets. There are two conceptually different ways to approach this problem: * We represent the mixed net/node/quantity set by a VHDL 1076.1 design entity. * We focus on a single association in the mixed net/node/quantity set, one where the formal and the actual have different object classes. We believe that only the second approach, focusing on a single association, can satisfy the demands imposed by hierarchical decompositions in a top-down design environment. The following sections discuss several possible solutions. No conclusion has been reached at this time about the extent of the support for mixed nets/nodes/quantity sets in the 1076.1 language, as it is always possible to convert a mixed net/node/quantity set to a collection of pure nodes, nets, quantity sets and VHDL 1076.1 statements. 3.1 Explicit Interface Code To handle the general case of the interface between two incompatible objects, or an interface between two compatible objects that involves more than the straight connection supported by a port association (e.g. hysteresis in an interface), we must be able to use all the power provided by the 1076.1 language. We can split the perceived mixed association into two regular associations, add some declarations and insert suitable 1076.1 code that describes the behavior of the interface. The code can be included in the design entity that includes the interface between the incompatible objects, either directly or encapsulated in a block. Alternatively, this code can be placed into a design entity of its own such that it can be re-used easily. All these possibilities support requirements a) through e), and none requires any support from the language, as they all make use of standard 1076.1 language elements. For convenience, however, we might want to have a syntactic shorthand to insert interface code in a mixed association. In the following we briefly discuss three possibilities, all requiring that the code describing a particular interface be encapsulated in a block that we call a conversion block. Our conclusion at this time is that a syntactic shorthand is not feasible. 3.1.1 Functional Notation in the Association The basic idea is to have a functional notation for a conversion block that could be used in an association in a way paralleling type conversions and conversion functions. The advantage of this solution is that it uses existing syntax in a new way, making the conversion block unintrusive. On the down side it requires a lot of new semantics: * Providing a functional notation for a block (maybe restricted to an external block), including the mapping of ports to function arguments and a return class, the handling of extra ports of the conversion block, and its parameters. * The extension of a configuration specification to support such a notation. We believe that the benefits provided by this idea are too small to justify the required large investment. 3.1.2 Resolution Function like Approach The basic idea is to associate conversion block with the subtype or subnature of the formal of the association element. There are several problems with this idea. * Inserting the correct conversion block requires information about both the formal and the actual in an association element. This solution tries to hold all the information about conversion blocks on the side of the formal. * The subtype or subnature declaration would have to hold a list of known conversion blocks. Each time a new one is created the subnature or subtype would have to be changed, requiring the recompilation of a potentially large number of design entities. * Choosing the correct conversion block from the list provided with the subnature or subtype is likely to require a scheme that allows to derive a name for a conversion block from the characteristics of the association element, which violates one of our design guidelines. Because of all these problems we believe that this is not a good solution. 3.1.3 Attribute Notation A third possibility is to provide an attribute mechanism that allows to attribute the formal of a port association with a conversion block. Due to the VHDL visibility rules such an attribute would have to be specified as part of the port list. Besides this new need the attribute mechanism has similar problems as the functional notation discussed above. We therefore have the same reservations about this idea. 3.2 Implicit Interface Code To address requirement f) we will focus on simple cases where the interface between the two objects includes the bare minimum. We could define the semantics of an association that includes, for instance, a terminal and a quantity such that the association does what a user would expect. After recapturing the relevant properties of the objects in a port interface list we distinguish between the three cases of mixed associations that are possible. It is important to note that the investigations are incomplete, and no decisions have been made. 3.2.1 Salient Properties of Terminals, Quantities and Signals A terminal is a collection of quantities. For the purpose of this discussion, however, it is not so much the terminal that matters, but the quantities of an (assumed) branch with the terminal and its reference terminal as plus and minus terminals. The across quantity of this branch is the reference quantity of the terminal T, designated T'reference. We will call the through quantity of the branch Ttognd. The types of T'reference and Ttognd are the across and through types of the nature of T. Their values are determined by the analog solver. A quantity is an object of a floating point type. An interface quantity has a mode, which is either IN or OUT. The mode imposes restrictions on how an interface quantity can be associated as a formal. In the following we will refer to a quantity as Q. The value of Q is determined by the analog solver. A signal is an object of a arbitrary type (with a few restrictions). An interface signal has a mode which imposes restrictions on how an interface signal can be associated as a formal [LRM]. We will in the following refer to a signal as S. A signal gets its value through the signal update mechanism described in section 12 of the LRM. 3.2.2 Association of Terminal and Quantity There are two choices for a simple behavior at the interface between a terminal and a quantity: * Q and T'reference are constrained to be equal. This requires that they are type compatible. * Q and Ttognd are constrained to be equal. This requires that they are type compatible. We believe that the first choice is the preferred one in many situations, and the one users are likely to expect. In this case there are two possible semantics for an association of a terminal and a quantity: * Q "drives" the branch between T and its reference terminal. This case can be described as a quantity-controlled across source. * T'reference "drives" Q. This case can be described as an across-controlled quantity source, and the value of Ttognd will be 0.0. The final distinction depends on the class of the formal. a) Quantity as formal, terminal as actual We can use the mode of the formal to select the appropriate semantic: * If the mode of the formal is IN, the quantity is "driven" by the terminal * If the mode of the formal is OUT, the quantity "drives" the terminal b) Terminal as formal, quantity as actual There is not enough information in the association or the declaration of the formal that allows to select one of the two semantics. We can address the problem in two ways: * We give a mode to the interface terminal. This is undesirable because there is no use for this information except in this case. There is also no obvious mode for an interface terminal except in special situations (e.g. what should the mode of an interface terminal of a resistor be?). * We include this information in the association element, using for instance the syntax [formal =>] [mode] actual No decision has been made, as further details must be worked out. 3.2.3 Association of Quantity and Signal We again have two cases: * Q "drives" S. To propagate a value from Q to S we either must sample Q at specified times, or we must include assign a crossing signal Q'above(level) to S. In either case additional information is needed that is not present in a simple association. How this could be handled needs further investigations. * S "drives" Q. This can be described as Q being constrained to the value of S, which requires that Q and S are type compatible. Further, the implicit break must become active each time there is an event on S. The application of these two cases depends on the class of the formal. a) Quantity as formal, signal as actual Using the mode of the formal we can select the appropriate semantic. * If the formal has mode IN, the quantity is "driven" by the signal. * If the formal has mode OUT, the quantity "drives" the signal. b) Signal as formal, quantity as actual Again, we use the mode of the formal to select the semantic. * If the formal has mode IN, the signal is "driven" by the quantity. * If the formal has mode OUT, the signal "drives" the quantity. * If the formal has mode BUFFER, the signal "drives" the quantity. * Formals with modes INOUT require further work. * Formals with mode LINKAGE cannot be supported. 3.2.4 Association of Terminal and Signal This is mostly a combination of the previous two cases. We will therefore not discuss it further. 4. References [DOD] 1076.1 Design Objective Document V2.3 Revision History 0.1 Sep.8, 1995 Ernst Christen Original version 0.2 Jan.14, 1996 Ernst Christen Major update, including comments from LDC meetings and information about simple mixed associations. 0.3 April 24, 1996 Ernst Christen Replaced VHDL-A by VHDL 1076.1 or equivalent. APPENDIX B: SOME EXAMPLES OF QUANTITY/TERMINAL ASSOCIATIONS Some Examples of Quantity/Terminal Associations =============================================== 1. Fundamentals --------------- When considering associations between terminals and quantities we can make the following observations: a) Because a signal flow connection has a direction (i.e. there is or isn't a characteristic expression corresponding to the quantity) the association is directed as well. b) In a directed association either the formal "drives" the actual, or vice-versa. c) We assume that the reference quantity of the terminal is to match the quantity. d) If a terminal is "driven" by the association, then there must be a branch between the terminal and the reference terminal of its nature. (i.e. a grounded across source). 2. Possible Combinations ------------------------ The following is sample code for the various possibilities described in the white paper on Mixed Netlists. 2.1 Quantity with mode IN as formal ''''''''''''''''''''''''''''''''''' In this case the terminal "drives" the association, i.e. we have a across-controlled quantity source. Sample code looks this: -- standard declarations terminal t1: electrical; component sf1 is ... port (quantity q1: in electrical'across; ...); end component sf1; a) -- This is what we would like to do -- c1: sf1 port map ( q1 => t1 ); b) -- A generic approach is to declare an extra quantity quantity q1aux: electrical'across; -- to associate the port of the component with the extra quantity c1: sf1 port map ( q1 => q1aux ); -- and to create a conversion block block port (terminal tin: electrical; quantity qout: out electrical'across); port map (tin => t1, qout => q1aux); begin qout == tin'reference; end block; c) -- we can simplify this by replacing the conversion block by q1aux == t1'reference; -- the quantity declaration and the component instantiation statement -- remain as in b) d) -- We could also use an approach specialized for this situation -- that doesn't need any extra quantity: c1: sf1 port map ( q1 => t1'reference ); 2.2. Quantity with mode OUT as formal ''''''''''''''''''''''''''''''''''''' Here the quantity "drives" the association, i.e. we have a quantity-controlled across source that can be implemented by the following code: -- standard declarations terminal t2: electrical; component sf2 is ... port (quantity q2: out electrical'across; ...); end component sf2; a) -- This is what we would like to have -- c2: sf2 port map ( q2 => t2 ); b) -- The generic approach is to declare an extra quantity quantity q2aux: electrical'across; -- to associate the port of the component with the extra quantity c2: sf2 port map ( q2 => q2aux ); -- and to create a conversion block block port (terminal tout: electrical; quantity qin: in electrical'across); port map (tout => t2, qin => q2aux); quantity i through ground to tout; begin tout'reference == qin; end block; c) -- we can simplify this by declaring a branch from t2 to ground quantity i2 through ground to t2; -- and replacing the conversion block by t2'reference == q2aux; d) -- We could also use an approach specialized for this situation -- We still need to declare the branch: quantity i2 through ground to t2; c2: sf2 port map ( q2 => t2'reference ); 2.3. Terminal as formal ''''''''''''''''''''''' In this case the actual is a quantity, for example a free quantity. In this case we do not know whether the quantity "drives" the branch between the terminal and ground, or vice versa. This information must come from the user. The argument has been made that if the terminal is a port of an independent across source or a controlled across source then this case can also be handled as the terminal "driving" the quantity. The argument goes on to say that any other case (e.g. a port of a resistor) is of no interest, and nobody would make such a connection. This argument is flawed for the following reasons: a) We cannot prevent users from attempting to connect the port of a resistor with a quantity. b) We cannot prevent users from attempting to connect the port of a floating source with a quantity. This means that, for example, the voltage of a voltage source cannot simply be made equal to a quantity if the voltage source isn't grounded. c) This is the most important: Because entities and architectures are separate design units we cannot discover from the declarations in the entity what the architecture does. The proposals in 3.2.2 of the Mixed Netlist white paper were made in this light: either a mode for an interface terminal, with questionable meaning since it does not address 2.3a and 2.3b, or a mode in the association element. 2.3.1 Terminal driving association -- standard declarations quantity q3: electrical'across; component sf3 is ... port (terminal t3: electrical; ...); end component sf3; a) -- This is what we would like to have -- c3: sf3 port map ( t3 => q3 ); b) -- we can use the generic approach from above and declare -- an auxiliary terminal terminal t3aux: electrical; -- associate the port of the component with the extra terminal c3: sf3 port map ( t3 => t3aux ); -- and to use the conversion block from 2.1 block port (terminal tin: electrical; quantity qout: out electrical'across); port map (tin => t3aux, qout => q3); begin qout == tin'reference; end block; c) -- We are tempted to write -- c3: sf3 port map (t3'reference => q3 ); -- but there is a problem: -- the formal must be an explicitly declared interface -- object or one of its members. d) -- We can simplify b) as in 2.1, but we still must declare the -- auxiliary terminal terminal t3aux: electrical; -- and associate the port of the component with it c3: sf3 port map ( t3 => t3aux ); -- but we can use a simple simultaneous statement for the rest q3 == t3aux'reference; 2.3.2 Quantity driving association -- standard declarations quantity q4: electrical'across; component sf4 is ... port (terminal t4: electrical; ...); end component sf4; a) -- This is what we would like to have -- c4: sf4 port map ( t4 => q4 ); b) -- we can use the generic approach from above and declare -- an auxiliary terminal terminal t4aux: electrical; -- associate the port of the component with the extra terminal c4: sf4 port map ( t4 => t4aux ); -- and to use the conversion block from 2.2 block port (terminal tout: electrical; quantity qin: in electrical'across); port map (tout => t4aux, qin=> q4); quantity i through ground to tout; begin tout'reference == qin; end block; c) -- We can simplify b) as in 2.2, but we still must declare the -- auxiliary terminal and the branch terminal t4aux: electrical; quantity i through ground to t4aux; -- and associate the port of the component with it c4: sf4 port map ( t4 => t4aux ); -- but we can use a simple simultaneous statement for the rest t4aux'reference == q4; 2.3.3 Mode in association element As can be seen in 2.3.1 and 2.3.2, the declaration of the component gives no hint which of the cases applies. The mode in the association element could help to make this distinction: c3: sf3 port map ( t3 => out q3 ); could indicate that the terminal "drives" the association, while c4: sf4 port map ( t4 => in q4 ); might indicate that the quantity "drives" the association. In other words, this mode could be used to determine whether to create semantic 2.3.1 or 2.3.2. ===============================================================================