New unresolved types

Proposal Details

• Who Updates: DanielKho, ...
• Date Proposed: 2016-10-01
• Date Last Updated:
• Priority:
• Complexity:
• Focus:

Current Situation

In VHDL-2008, several types such as unsigned and signed (numeric_std) have both unresolved and resolved versions. Propose to extend this useful feature to other types as well. Using unresolved types make it clear that there could be only a single driver to the net, and this helps reduces errors where the designer accidentally writes multiple drivers to a net. Declaring a signal as unresolved makes it easy to debug these problems.

There are several other types that are commonly used for synthesis, but do not have unresolved versions for these. Examples are bit, boolean, character, and integer from library std. Especially for synthesis, it's good for all types used to have unresolved versions, unless multiple drivers is intended in the design. KJ: The premise here is incorrect. These four types, as currently defined, are already unresolved. -- KevinJennings - 2016-10-04

Requirement

Require that the following base types be implemented as unresolved types, and have resolved versions with pre-defined resolution functions:

boolean, bit, character, integer

Require that the following subtypes be implemented as subtypes of unresolved types:

natural, positive

Require that there is a default undefined state (e.g. 'X') for these types. Resolution functions that implement resolved versions of these types can make use of the undefined state.

'Resolved' already has a clearly defined meaning with VHDL which is that 'resolved' is a function that takes a vector of some type and produces a scalar of that same type and it is used to determine a final output given multiple possibly conflicting drivers. 'Resolved' is not the same thing as removing a new value of that type (i.e. the 'X') from the list of possible values which is what you are trying to do here in order to convert from the superset integer type (which includes the 'X') to the integer type that we know today. -- KevinJennings - 2016-10-03

To further illustrate my point, as in the case of the integer type (assuming integer is an unresolved type), how do we write a resolution function that resolves multiple integer drivers by returning an undefined integer value? Say, you have two drivers of type integer, each of which drives a different integer value to the same scalar bus. How do we write a resolution function that returns an invalid integer value (e.g. NaN) in this case? -- DanielKho - 2017-01-06

Implementation details

type unresolved_boolean is ('X', false, true);
type unresolved_bit is ('X', '0', '1');
alias u_boolean is unresolved_boolean;
alias u_bit is unresolved_bit;
subtype boolean is resolved u_boolean;
subtype boolean_vector is (resolved) u_boolean_vector;
subtype bit is resolved u_bit;
subtype bit_vector is (resolved) u_bit_vector;

Proposed changes are documented here: standard.vhdl.

Code Examples

entity e is port(
     d: in u_boolean;
     q: out u_bit_vector
); end entity e;

Use Cases

Use whenever it is intended not to have multiple drivers.

Show a few of these use cases. As is, I don't think there are any compelling use cases. -- KevinJennings - 2016-10-03

Some use cases: -- DanielKho - 2017-01-05

Use Case 1:

entity uart_ascii_intf is port(
    we: in std_ulogic;
    a: inout character
); end entity uart_ascii_intf;

architecture synth of uart_ascii_intf is
    signal a_rx: character;
begin
    process(all) is begin
        if we then
            a <= 'w';
        else
            a <= NaC; -- proposed Not-a-Character example, tristated by default.
            a_rx <= a;
        end if;
    end process;
end architecture synth;

Use Case 2:

    function resolve(s: boolean_vector) return boolean is
        variable result: boolean;
    begin
        for i in s'range loop
            if is_bool(s(i)) then    -- To implement is_X or is_bool, we need to be able to check for not-a-boolean values. How?
                assert not is_bool(result) report "Multiple driving signals detected." severity error;
                if is_bool(result) then
                    result := 'X';   -- How do we return an invalid boolean value?
                else result := s(i);
                end if;
            end if;
        end loop;
        return result;
    end function resolve;

Arguments FOR

None? -- KevinJennings - 2016-10-03

Basically the intention of this proposal, no matter whether the types are already considered resolved or not, is to allow users to be able to have undriven values to some (or all) of the "bits" contained within a type. I perhaps shouldn't use the type "bit" as an example, however, for the other types such as boolean, integer, and character, it would be good if users are allowed to be able to assign undriven values to signals of these types.

In the case of "integer" for example, how do one create a resolution function that checks whether an integer is having an "undefined" value or not? Also, how do one release (or undrive) the drivers for signals of these types, say in a situation where an inout port is of type character or boolean (in the case of bidirectional ports for example)? Something similar to float_pkg's NaN would be good if applied to the integer type.

The whole purpose of this proposal is to enable the definition of NaN for integers, characters, and booleans. -- DanielKho - 2017-01-05

Arguments AGAINST

The details of this proposal are somewhat backwards. The currently defined types are already unresolved, what would be needed is to define a resolved subtype either from these existing types or from a superset type. As written, this proposal redefines existing type names to now be resolved and creates new type names to be the unresolved version. For backwards compatibility, normally one would want to maintain the existing behavior for current names and add new behavior to go along with the new names. In this situation, one should derive the new type names as being resolved forms of the current unresolved names. Example: type resolved_integer is resolved unresolved_integer; Changing currently existing type names to be resolved versions of what they are today is probably not a good idea unless there is some compelling reason to do so and there is no other solution. Rework this proposal so that the existing names stay as unresolved types. -- KevinJennings - 2016-10-03

I am fine with having unresolved_integer and resolved_integer, with unresolved_integer aliasing the currently-existing integer type. However, may I suggest we add an undefined value to the existing unresolved type. This addition shouldn't cause any backward compatibility problems. -- DanielKho - 2017-01-05

General Comments

Still figuring out a way to add an undefined state into the integer type. I was thinking along the lines:

type unresolved_integer is (range -2147483648 to 2147483647, undefined);

Another way to do this is to make the NaN value implicit to the type.

Supporters

-- DanielKho - 2016-10-01

Add your signature here to indicate your support for the proposal

Non-Supporters

-- KevinJennings - 2016-10-03 (Supply actual use case and rework so that existing types behave as they do today which is that they are not resolved)

Add your signature here to indicate your non-support for the proposal