RE: EXTERNAL: Re: [vhdl-200x] Modular types

Using the pattern of integer operators (all operations return full integers, regardless of the operands), the enclosing range of (modN+1) is of no consequence until/unless the result is assigned to or associated with another object, or the result lies outside of the range of the base type. 

To illustrate a specific advantage of this behavior, the following is my favorite technique for accessing the "borrow" output of a down-counter:

if my_natural_counter - 1 < 0 then
  do_something;
else
  my_natural_counter <= my_natural_counter - 1;
end if;

Just don't try that with my_unsigned_counter (unsigned - natural == unsigned)!



Regarding "wrongness" of applying resolution functions to variables:

Is the application of resolution functions to variable assignments really any different than when there is only one driver of a signal? 

The standard-defined resolution functions behave transparently when only one driver is associated with a signal. However, that property of a resolution function is not dictated by the standard, and the lack of said property has been exploited before in simulations and testbenches.

When the language already gives us a means of overriding a signal assignment through the resolution function, why should we invent a different means to override a variable assignment, especially if the signal and variable are of the same type? Why would we want to restrict such a capability to a single class/kind of type? All we need to do is generalize the resolution function to all objects of its associated type.

There are also some useful applications of a similar resolution function approach to fixed- and floating-point subtypes as well, especially given their operators' automatic growth of return values.

I just wish I (or anyone else) had thought/spoken of this alternative when I proposed the ability to override assignments earlier.

Andy




-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of ryan.w.hinton@L-3com.com
Sent: Monday, July 07, 2014 1:07 PM
To: vhdl-200x@eda.org
Subject: RE: EXTERNAL: Re: [vhdl-200x] Modular types

The simplest, most obvious solution I see is to (1) let all the arithmetic and other operations use integer and/or universal integer (for literals, I believe) types; and (2) effect the modulus on assignment.  

(1) is my understanding of VHDL's current integer handling.  Literals and Andy's modN + modM = ?? example suggest that changing this paradigm is problematic if not infeasible.  (Or maybe they show how smart we were to use this system in the first place. :-)

(2) will require a language change.  Applying resolution functions to variables feels wrong to me.  Another option (from Andy?) is to add the ability to overload assignment.  This also is not my favorite proposal, but it feels better than hijacking resolution functions.  And it helped solve a problem on an unrelated proposal (can't remember which one now), so maybe it's not such a bad idea.

This approach is not without pitfalls.  For example, expressions like modN+1 may be out of range of modN.

- Ryan

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jones, Andy D
Sent: Thursday, July 03, 2014 6:06 PM
To: vhdl-200x@eda.org
Subject: RE: EXTERNAL: Re: [vhdl-200x] Modular types

My original responses investigated the practicality of modular types and subtypes in VHDL, and the expanded use of resolution functions, as means to implement the desired behavior ("automatic" modulo-N, arithmetic and logical operations on integers.

Even if we provide subprograms' and entities' access to the subtype of the actuals, we still have to define the result modulus when multiple arguments' modular subtypes differ (e.g. modulo_N + modulo_M = modulo_?) for all functions and operators. And we need to handle integer literal actuals.

Otherwise, communicating the actual return type to a function (or operator) will be a very complex issue to define, especially if backward compatibility is desired with existing code. This is a rat-hole from which Verilog and SystemVerilog suffer.

I also think we need to consider the cost of implementing suggested additions to the language in the tools (simulation, formal analysis and synthesis), compared to the benefit to users. Minor updates to the language are going to be less expensive to implement, and therefore more quickly supported. No matter how useful they are, language updates don't do any good if tools don't support them. 

For all these reasons, it sure seems to me that applying resolution functions to variables, is a simpler to use, simpler to implement solution for modulo arithmetic (and logic), and still allows other transformative uses. It would be even simpler to use if the resolution_function_name could include a partial association list for the modulus parameter. In addition, a standard modulo resolution function would allow synthesis vendors to support this resolution function, and subtypes using it, without having to support user-defined resolved subtypes in general.
	
Andy


-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Brent Hayhoe
Sent: Thursday, July 03, 2014 11:10 AM
To: vhdl-200x@eda.org
Subject: Re: EXTERNAL: Re: [vhdl-200x] Modular types

On 03/07/2014 02:11, ryan.w.hinton@L-3com.com wrote:
> On Wednesday, July 02, 2014 10:11 AM, Brent Hayhoe wrote:
> ...
>> It feels like we're so close to being able to implement them now and 
>> generate a package of overloaded subprograms.
> Several people have pointed out that direct assignment remains a 
> problem even if you overload the arithmetic operators appropriately.
> That's why Andy suggested generalizing resolution functions as a hook 
> into the assignment semantics.
I thought that Andy's comments were more to do with the inability of subprograms to get hold of the actual's type constraints?

I can see some type conversions which may require reference to the function return subtype and this maybe another reason to sort out the problems with this
proposal:

http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/FunctionsKnowOutputSubtype
> ...
>> We can then create a function to return the modulus of the subtype using:
>>
>>      'subtype'high - 'subtype'low + 1
>>
>> or rather we can't at present because we can't get this from the 
>> actual part of the interface element.
> Is there a technical reason for this?  (Compiler people?)  I know 
> entity interface array objects can take their index and element ranges from actuals.
> It seems natural for an unconstrained integer or other discrete type 
> to take its range from the actual.  In fact, it seemed natural enough that I wrote a test case to confirm that these attributes *don't* pass through the interface.  This seems like it would cause problems if an out-mode actual object has a(n integer) range constraint and the procedure starts manipulating it.  I guess I don't do this much in practice, but I can certainly imagine it being a problem.
>
> - Ryan
You went down the same route as me in generating test cases to check this out.

It's one of the few places in VHDL where you cannot be specific in want you want to do. Hence the 'actual attribute and maybe we should have a 'formal attribute to be complete.

Brent.

--
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.




--
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.