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.