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

Agree with Andy. The beauty and affability of VHDL results from real
functions and real variables with which I can synthesize any synchronous
abstraction that I can simulate.    -- Mike Treseler


On Fri, Aug 1, 2014 at 11:18 AM, Jones, Andy D <andy.d.jones@lmco.com>
wrote:

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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.