[vhdl-200x] RE: Modular types

FYI: My untested implementation below is incorrect for a modulo function.

Untested == Incorrect!


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



From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jones, Andy D
Sent: Wednesday, June 25, 2014 12:47 PM
To: vhdl-200x@eda.org
Subject: EXTERNAL: [vhdl-200x] RE: Modular types

Martin,

This sounds really promising!

We define a new type called mod_integer : mod integer'high; (Ada syntax)

And we define standard operators and functions for mod_integer.

The Ada LRM appears silent on modular subtypes. Assuming we have modular subtypes, then users define subtypes of mod_integer for individually "sized" subtypes.

But there's a problem here: Operators and subprograms do not have access to the subtypes of their arguments and/or return types. So they cannot perform the range bounding of the results.

On the other hand, if users declare new modular types, then they (or we) cannot define operators and subprograms that work for any modular type, like we do with subtypes. I suspect this limitation in Ada/VHDL will/would severely restrict the use of modular types.

A slightly different approach to supporting modulo arithmetic on modular subtypes would be to use integer arithmetic, but an assignment/association would transform the RHS expression's result to match the LHS object's subtype.

In short, the only difference between a signed integer and a modular integer would be upon assignment/association. In fact we could just support modular subtype definitions, rather than modular types, and the existing integer operators and subprograms would suffice.



However, we don't need a modular type/subtype at all if we redefine resolution_function_name in the LRM to include an optional parameter list with static arguments. These arguments would be supplied to the resolution function, in addition to the array of driving values:

Subtype my_modular_subtype is modular(2**n) natural;

Where modular() is a resolution function that accepts a positive modulus and an integer_vector:

function modular(modulus: positive, inputs: integer_vector) return natural is
begin
  for I in inputs'range loop
    result := maximum(result, minimum(modulus, maximum(0, inputs(i)))); -- untested!
  end loop;
  return result;
end function modular;

We could define the modular() function in the standard, just to give users (and synthesis implementers) a head start.

Note that we can declare a de facto modular subtype already by declaring a function modular8(inputs), which calls the above modular(8, inputs), and use modular8 in a resolved subtype definition, without ANY change to the standard (very nice for testing)!

However, getting support from synthesis vendors is probably not forthcoming unless we define the resolution function to be supported in the standard. I can accept that synthesis would only support modulus values that are positive integer powers of 2.

Of the two (modular types/subtypes or expanded resolved subtype definitions), the latter involves much less impact to the standard, and would be much easier to implement on simulators or synthesizers (with restrictions to standard-defined resolution functions). For simulation, the potential applications of the latter are far more powerful.


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







From: owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org> [mailto:owner-vhdl-200x@eda.org] On Behalf Of Martin.J Thompson
Sent: Wednesday, June 25, 2014 9:18 AM
To: vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>
Subject: EXTERNAL: [vhdl-200x] Modular types

Greetings all,

In the last teleconference I was asked to look at what VHDL might be able to implement for "modular types", so I've taken a look at how Ada does it (quotes below are taken from the LRM http://www.ada-auth.org/standards/ada12.html).

Ada defines a modular type from the base integer type (there are "signed integers" and "modular integers").

--- quote
A modular type is an integer type with all arithmetic modulo a specified positive modulus; such a type
corresponds to an unsigned type with wrap-around semantics.
--- endquote

The modulus is known at compile-time.  As you would expect, the range of a modular type is from 0 to modulus-1.

Two extra attributes are defined :

--- quote
S'Mod denotes a function with the following specification:
function S'Mod (Arg : universal_integer)
            return S'Base
This function returns Arg mod S'Modulus, as a value of the type of S.

S'Modulus yields the modulus of the type of S, as a value of the type universal_integer.
--- endquote

The action of operators on modular types is as you might expect:

--- quote
For a modular type, if the result of the execution of a predefined operator (see 4.5) is outside the base
range of the type, the result is reduced modulo the modulus of the type to a value that is within the base
range of the type.
--- endquote

Bitwise "and", "or", "xor" and "not" are all defined for modular types (which is good).  There are interesting implications for the operation of logical operators on modular types which are not modulo-a-power-of-2.  Because they are defined as operating by taking the binary values and operating on them bit-by-bit, if the result is out of range, a final subtraction of the modulus is performed.  This doesn't change the result for powers-of-2, but other moduli may result in non-intuitive (but well-defined) answers!

Ada has limits on the maximum range of a modular type, but I would be tempted to say we shouldn't add one to VHDL, to allow for large bit vectors to be modelled. At the very least I think we should allow for bit vectors of the length of current applications (such as crypto) and add a few bits for expansion.

I would propose that any VHDL implementation of modular types would stick very closely to the Ada definition.

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

Cheers,
Martin



--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

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