On 29 Jun 2014, at 4:55 am, Jones, Andy D <andy.d.jones@lmco.com> wrote: > From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of tgingold@free.fr >> Well, resolution function applies only on signals. > > Have you tried it, or are you relying on the LRM's silence WRT the effects of resolution functions on variables? I have not tried it yet. (I will soon). On Resolution Functions: (From the VHDL LRM) 4.6 Resolution functions A resolution function is a function that defines how the values of multiple sources of a given signal are to be resolved into a single value for that signal. Resolution functions are associated with signals that require resolution by including the name of the resolution function in the declaration of the signal or in the declaration of the subtype of the signal. A signal with an associated resolution function is called a resolved signal (see 6.4.2.3). A resolution function shall be a pure function other than an uninstantiated function (see 4.2.1); moreover, it shall have a single input parameter of class constant that is a one-dimensional, unconstrained or partially constrained array with an undefined index range and whose element type is that of the associated subtype or subelement subtype in the subtype indication in which the name of the resolution function appears. The resolution function name shall not be an attribute name (see 8.6). The type of the return value of the function shall also be that of the associated subtype or subelement subtype in the subtype indication in which the name of the resolution function appears. Errors occur at the place of the subtype indication containing the name of the resolution function if any of these checks fail (see 6.3). The resolution function associated with a resolved signal determines the resolved value of the signal as a function of the collection of inputs from its multiple sources. If a resolved signal is of a composite type, and if subelements of that type also have associated resolution functions, such resolution functions have no effect on the process of determining the resolved value of the signal. It is an error if a resolved signal has more connected sources than the number of elements in the index type of the unconstrained array type used to define the parameter of the corresponding resolution function. Resolution functions are implicitly invoked during each simulation cycle in which corresponding resolved signals are active (see 14.7.3.1). Each time a resolution function is invoked, it is passed an array value, each element of which is determined by a corresponding source of the resolved signal, but excluding those sources that are drivers whose values are determined by null transactions (see 10.5.2.2). Such drivers are said to be off. For certain invocations (specifically, those involving the resolution of sources of a signal declared with the signal kind bus), a resolution function may thus be invoked with an input parameter that is a null array; this occurs when all sources of the bus are drivers, and they are all off. In such a case, the resolution function returns a value representing the value of the bus when no source is driving it. -- You either need a second argument to your proposed 'resolution' function to convey modulus or you need a unique 'resolution' function for every integer subtype indication. The latter a heavy burden for VHDL design specification authors. Ada modular integers use an attributed integer variables to define modulus. It's all hidden in elaboration and type declaration. Note also Ada's modular integer declaration constrains 'LOW for the type. Using a resolution like function to latter bind modulus either leaves you open for Fizzbin like semantic restrictions, more modulus arithmetic for offsetting from the 'LOW bound or loss of power of two coherency. (Ada's modular integer has a range of 0 to modulus-1 and is intended for power of two modulus operands for those 'bit-wise' logical operators). Also evaluating an operator as an expression results in a type related to the type of one or both inputs to the operator. How do you bind a resolution indication to the result? What's the effect on an aggregate target? > Note that the LRM specifies that not just subtypes, but objects themselves (constants, ports, signals and [gasp!] variables) are all declared with a subtype_indication, which is defined as including an optional resolution_indication. Therefore, the LRM actually, explicitly supports associating a resolution function directly with a variable. It just remains silent on the effect (is or should the resolution function be called to determine the updated value for an object other than a port/signal). There's a difference between syntax and semantics. The text of the LRM conveys semantic restrictions. Note also there's more than one type of resolution indication: (From the VHDL LRM Syntax summary): subtype_indication ::= [§ 6.3] [ resolution_indication ] type_mark [ constraint ] resolution_indication ::= [§ 6.3] resolution_function_name | ( element_resolution ) element_resolution ::= array_element_resolution | record_resolution [§ 6.3] From the VHDL LRM: 6.3 Subtype declarations ... A resolution indication is said to correspond to a subtype, and associates one or more resolution functions with the subtype to which it corresponds or with subelement subtypes of the subtype to which it corresponds. A resolution indication that appears in a subtype indication corresponds to the subtype defined by the subtype indication. For that resolution indication, and any resolution indications nested within it, the association of resolution functions is specified by the following rules, applied recursively: — If a resolution indication is in the form of a resolution function name, then the named resolution function is associated with the subtype corresponding to the resolution indication. — If a resolution indication is in the form that contains an element resolution that is an array element resolution, then the subtype corresponding to the resolution indication shall be an array subtype. The array element resolution corresponds to the element subtype of the array subtype. — If a resolution indication is in the form that contains an element resolution that is a record resolution, then the subtype corresponding to the resolution indication shall be a record subtype. For each record element resolution in the record resolution, the record subtype shall have an element with the same simple name as the record element simple name in the record element resolution, and the resolution indication immediately following that record element simple name in the record element resolution corresponds to the element subtype of the element with that simple name in the record subtype. If a subtype indication includes a resolution indication that associates a resolution function name with a subtype, then any signal declared to be of that subtype will be resolved, if necessary, by the named function (see 4.6); for an overloaded function name, the meaning of the function name is determined by context (see 4.5 and 12.5). It is an error if the function does not meet the requirements of a resolution function (see 4.6). The presence of a resolution function indication has no effect on the declarations of objects other than signals or on the declarations of files, aliases, attributes, or other subtypes. -- So you're allowed to provide a resolution indication, but it has no effect. > Clearly the LRM is ambiguous on this (one way or the other) and should be corrected! It might be safer to say it used to be more ambiguous. (with respect to say -1993). >> You can't achieve modulo arithmetic with resolution function. >> If you write 17 ** 16, you get a value for a modulo type, but a overflow on integer types. > > This same behavior is also true if you use an Ada modular type, and exceed the implementation's range for Ada integers. Can you imagine what it would mean if the language had to support an arbitrarily large, pre-modulo value (e.g. integer'high ** integer'high)? There are other 'accuracy' issues: From the Ada RM: 3.5.4 Integer Types http://www.adaic.org/resources/add_content/standards/05rm/html/RM-3-5-4.html Legality Rules ... The expression of a modular_type_definition shall be static, and its value (the modulus) shall be positive, and shall be no greater than System.Max_Binary_Modulus if a power of 2, or no greater than System.Max_Nonbinary_Modulus if not. Implementation Requirements ... System.Max_Binary_Modulus shall be at least 2**16. Ada allows constraints on the size of a modulus. For VHDL the issue is quite different. 3.5.4 Integer Types ... ...The set of values for a modular integer type are the values from 0 to one less than the modulus, inclusive. -- and ... A modular_type_definition defines a modular type whose base range is from zero to one less than the given modulus. A modular_type_definition also defines a constrained first subtype of the type with a range that is the same as the base range of the type. ... -- This puts a 'number-of-bits' limit on modular types based on the modulus. The type of the modulus can be discerned from the return value of the attribute (also from 3.5.4): S'Modulus S'Modulus yields the modulus of the type of S, as a value of the type universal_integer. -- The range of the modulus is from 0 to Integer'HIGH in VHDL parlance: From the VHDL LRM: 5.2.3.2 Predefined integer types The only predefined integer type is the type INTEGER. The range of INTEGER is implementation dependent, but it is guaranteed to include the range –2147483647 to +2147483647. It is defined with an ascending range. NOTE—The range of INTEGER in a particular implementation is determinable from the values of its 'LOW and 'HIGH attributes. -- You'll have at least 31 bits and the implementation defined range of integer limits portability. Notice you're always going to be a bit short because a modulus is a natural value. This shortcoming makes it a bit less attractive for synthesis or actual hardware descriptions, where despite Martin's conjecture some of use use array types of length greater than 31 or 63 in cryptographic applications. Is anyone defining a bigger Integer minimum range? Having gone all the way through this stuff I share Martin's opinion that adding this attribute mechanism conveying a subtype indication to type Integer while constraining it's LOW value and calling it a modular integer may be the best way to go. I'd also question the usefulness of modular integers for synthesis or serious hardware modeling, as I recall Jim made arguments centered around verification. And ya, Tristan will likely tell you the implementation isn't too bad for modular integers. It can have little effect on non-modular integer use because of the word 'static' in there and you can simply reference different code for expression evaluation requiring modulus attention at elaboration time (it would complicate dynamic binding for function calls a bit). > What is different is that Ada modular types perform the modulo operation after each operation in an expression, rather than on the results of the expression being assigned to the object, as with a resolution function. For complex expressions, this might cause overflows with a resolved subtype which would not have occurred with a modular type. Expressions have type. Your complex expressions would require resolution indication inheritance (because you're using the 'resolution' function for modulus constraint). It tends to require the same changes to all those implicit operator functions as are implied by modular integers other than modulus reduction. > Even if we have to revise the LRM to employ resolution functions on variables, they would be a much cleaner, simpler and easier to use solution than modular types. I am all for borrowing things from Ada if we need them, unless there is an alternative that fits better with VHDL. The issue here is that what you are describing isn't a resolution function it's something else. It doesn't actually do resolution. > Given that resolution functions can be deployed through subtypes, such a modular implementation retains the spirit of Ada modular types, with more flexibility and compatibility. Ada modular types already exist. > If we revise the LRM in this regard, we can also provide for more flexibility in the resolution_indication, including the specification of an optional association list (for parameters or generics) with the resolution_function_name, to simplify the specification of multiple subtypes or objects with different modulus values. > > And, with resolution functions, we are not limited to modulo arithmetic on integers, but can explore similar "auto-resizing" effects on fixed point and other types. All the issues that go away with bit oriented array representations. If it's not hardware, do it the Ada way. The big fix provided by Ada modular integers is the 'LOW value, giving a natural range through type declaration. The major shortcoming is the number of bits that be expressed through powers of two and the minimum implementation range of integer (and the natural sub range). (And there are those of us who have tinkered similarly with resolution functions in -1993 compliant tools). -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sun, 29 Jun 2014 13:09:11 +1200
This archive was generated by hypermail 2.1.8 : Sat Jun 28 2014 - 18:10:19 PDT