RE: [vhdl-200x] Proposal for improved physical types

Why not a physical unit that is actually real  based. What is the rationale for limiting physical quantities to integral multipliers of a base type? The physical type consists of a base unit, a multiple to the base unit, and a number. For Time I understand that usefulness of integral time for the efficiency of the event handling. Why the same limitation for a type such as frequency or resistenace, or etc…?

Regards
David

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Kevin Thibedeau
Sent: Thursday, January 08, 2015 1:42 PM
To: vhdl-200x@eda.org
Subject: [vhdl-200x] Proposal for improved physical types


The current implementation of user defined physical types in VHDL is tied to the implementation of integer which is a problem with most tools only supporting 32-bit integers. The 31-bit positive range of the typical integer only covers nine orders of magnitude or three SI prefixes. This severely restricts the practicality of user defined physical types. The built-in time type is typically implemented as a 64-bit integer, covering a much more useful eighteen orders of magnitude.

I would like to propose a system where a new integral subtype "physical" is provided that is guaranteed to cover the same range as the built-in time type. It would be restricted to use only in definitions of physical types to eliminate problems with using it directly as a separate integral type in other contexts.

    -- Implicit subtype to be defined in std.standard
    subtype physical is $UNIVERSAL_INTEGER
        range time'pos(time'low) to time'pos(time'high);


While VHDL permits larger integers, at this point many tool vendors are retrenched in their restriction to 32-bit implementations. It seems unlikely that this status quo will ever change due to concerns about backward compatibility. Such a situation doesn't exist for physical types which, in general, have seen limited use. The machinery for handling 64-bit time already exists in most, if not all, current tools so it would not be an undue burden to extend that to other physical types. All of the implicit operators would work as they do with time. By implementing this through a new special purpose subtype, existing code using integer as the basis for physical types will be unaffected.


With today's tools one must compromise between precision and maximum range when defining a physical type:

    -- Definition of a "frequency" physical type using today's tools
    type frequency is range 0 to integer'high units
      Hz;
      kHz = 1000 Hz;
      MHz = 1000 kHz;
      GHz = 1000 MHz; -- Usually limited to 2**31 = 2.1 GHz
    end units;

We can make the primary unit kHz to extend the range while sacrificing the ability to represent low frequencies:

    type frequency is range 0 to integer'high units
      kHz;
      MHz = 1000 kHz;
      GHz = 1000 MHz;
      THz = 1000 GHz; -- Now support up to 2.1 THz
    end units;
It would be nice to have support for mHz or better precision for more accurate representation of fractional frequencies. Using current implementations, though, a primary unit of mHz would limit the maximum frequency to 2.1 MHz which is too low for many practical uses of a frequency type.

With a 64-bit integer for physical types we can define a more useful frequency type that permits large values as well as accurately representing fractional frequencies:

    -- Implicit subtype to be defined in std.standard
    subtype physical is $UNIVERSAL_INTEGER
        range time'pos(time'low) to time'pos(time'high);

    type frequency is range 0 to physical'high units
      uHz;
      milliHz = 1000 uHz;
      Hz  = 1000 milliHz;
      kHz = 1000 Hz;
      MHz = 1000 kHz;
      GHz = 1000 MHz;
      THz = 1000 GHz; -- Up to 9.2 THz with a 63-bit positive range
    end units;

    -- Using "physical" elsewhere is prohibited
    variable not_allowed : physical;
    type invalid_array is array(physical'range) of bit;

Having special rules for when a type can be used subverts the purity of the type system but I think it is a reasonably pragmatic solution in light of the benefits it would provide.

--
Kevin Thibedeau

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