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

From: Jones, Andy D <andy.d.jones@lmco.com>
Date: Fri Aug 01 2014 - 11:18:06 PDT
The original proposal was to adopt Ada style modular types, which are normalized to zero.

I'm not convinced (nor were the Ada folks) that a non-normalized modular functionality is necessary. 

But if we want a non-normalized modular functionality, then why not implement a saturated functionality too? And who knows how many other variations of integer functionality one might want?

I hate to sound like a broken record, but I suggest that a resolved subtype implementation (with extensions to variables) would allow users to implement these and other new behaviors without waiting for yet another language change to do it. 

It would be just as easy to write a non-normal modular or saturated resolution function as it is to write a modular one (even though implementation in HW is understandably more expensive).

Extended use of resolved subtypes could do a lot of other useful things:
	An "x01" resolved subtype of std_logic
	An automatically resized vector subtype (slv, unsigned, signed, ufixed, sfixed, etc.)

If desired, resolved subtypes can already be restricted to 1 "driver", by constraining the length of the resolution function's array argument to 1 (constrain the index subtype).

Keep in mind that we can ALREADY DO THIS FOR SIGNALS! Just not for variables...

Rather than focusing on extending the language to support a specific point-need (a new type), why not focus on extensions to the language that make not only that point-need, but also other similar needs, easily handled without further changes to the language?

I have previously suggested that extending the syntax of the resolved subtype declaration is unnecessary if we are willing to define a modular resolution function in a package that takes a generic for the value of the modulus. However, this still requires one to separately instantiate the package with the modulus generic, and then to prefix the modular resolution function with the name of the package instance.

Why not simply allow the use of a short-hand package generic map in a use statement or when the package name is used as a prefix? 

If we define the modular resolved subtype itself within that generic modular package, then declaring a signal of all these resolved subtypes is as simple as:

Signal my_mod4 : ieee.std_modulo(modulus => 4).modular;
Signal my_mod1_5 : ieee.std_nonnormal_modulo(1, 5).modular;
Signal my_sat4 : ieee.std_saturated(4).saturated;
Signal my_sat_1_5 : ieee.std_nonnormal_saturated(1, 5).saturated;


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



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Aug 1 11:19:41 2014

This archive was generated by hypermail 2.1.8 : Fri Aug 01 2014 - 11:20:29 PDT