RE: [vhdl-200x] Modular types

I think we're in a pickle with a modular type, since operators would have to be declared for every different type declared..

Modular subtypes don't communicate to the operators how to manage the results.
	
So, what do we want?

Do we want something that automatically truncates (modulo) an integer expression result to a given "size" object, or do we want each operation to constrain its results accordingly?

Without far-reaching changes to the language, I don't know how to accomplish the latter, except with array types, which we are trying to avoid, presumably for performance reasons.

That leaves something like a resolution function that can perform the modulo operation on the expression result at assignment or association.

However, the LRM is silent on the effect of a resolution function on a variable of a resolved type. Is the resolution function called with an array of one element containing the value of the expression being assigned to the variable, similarly to a resolved signal with a single driver? In most common cases (variables of std_logic type) whether or not the resolution function is called is of no observable consequence. Anyone tried it with a non-transparent resolution function yet?

Now that functions can have generic maps, maybe that is the simplest way to accomplish a flexible modular resolved subtype: allow the resolution_function_name in a resolved subtype declaration to include a generic map, and use a generic to specify the numeric modulus for the resolution function, and therefore of the subtype.

Subtype my_modulo_8_type is modulo generic map ( 8) integer;

Such a resolved subtype would have the desired (?) behavior of happily converting a negative assigned/driven value to the positive modulo.

To avoid unintentionally allowing multiple drivers for such a subtype, if so desired, perhaps we could define some means of specifying that a signal of that resolved type can still only have one driver? Constraining the index type (0 to 0) on the unconstrained array type of the argument to the function would fail (LRM states it is an error) if more than one driver is associated with the signal. I have no idea how gracefully a given simulator would fail in that situation.


Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX





-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Martin.J Thompson
Sent: Thursday, June 26, 2014 2:33 AM
To: vhdl-200x@eda.org
Subject: EXTERNAL: RE: [vhdl-200x] Modular types

Thanks Tristan - I noticed this behaviour but forgot to comment on it.  For other interested parties, the relevant bit of the LRM is:

--- quote
For the evaluation of a type_conversion that is a value conversion, the operand is evaluated, and then the value of the operand is converted to a corresponding value of the target type, if any. If there is no value of the target type that corresponds to the operand value, Constraint_Error is raised; this can only happen on conversion to a modular type, and only when the operand value is outside the base range of the modular type.
--- endquote

Now, I can see the reasoning - without an explicit type-conversion (using 'mod), it's more in the VHDL-like "fail as early as possible" mindset.  But perhaps without an explicit type-conversion you shouldn't be allowed to assign an integer to a modular type, so it should fail at compile-time?

I imagine you've written rather more Ada code than I have, so could you elucidate a bit more on the problems the current Ada Behaviour causes please?  You mention it is "error-prone".  What would your preferred behaviour be - to fail at compile-time, or treat all assignments as asking for a "wraparound", or something else entirely?

Thanks,
Martin


-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of tgingold@free.fr
Sent: 25 June 2014 19:39
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Modular types

Hello,

> So, are there any features you would like which are not mentioned?
> Constraints which do not make sense?

Ada made a mistake for type conversion to modular type: the expression is not reduced, which is not intuitive and error prone.  (In Ada, a type conversion of a negative value to a modular type raises an error).
Don't follow that!

Regards,
Tristan.

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