RE: EXTERNAL: Re: [vhdl-200x] Sizing of variables and signals from initial values

Ryan,

First, let's look at the integer usage model in VHDL. Integer operations always evaluate as full integers, regardless of the subtypes of the arguments. Even if I subtract two naturals, the difference is an integer, and quite possibly negative. The result only (and automatically!) takes on the subtype of natural when I assign the result to an object of subtype natural. In synthesis, the size of the expression logic is pruned to match the results as expressed in the assigned subtype. As a result, numeric accuracy is preserved without having to manually manage any "sizes".

To make this integer usage model applicable to arbitrary sized numeric (integer and fixed point) quantities, I propose the following two changes. 
	
1) Create a universal fixed point type system (since fixed point can represent integral, fractional, signed and unsigned quantities) that behaves somewhat like integers do: There would still be separate sfixed/ufixed types, but operations on either would always evaluate as sfixed, large enough to hold the largest result possible (excluding division). I propose that the existing fixed point packages be modified to place the base ufixed/sfixed types in a separate package (perhaps the existing fixed_float_types package), and provide the new operators, procedures, etc. in a separate package. The existing fixed_pkg and fixed_generic_pkg could alias the base ufixed/sfixed type definitions from the new package (or fixed_float_types) for backward compatibility. Then a new package could be created to define the new operators (always return sfixed), conversions, etc. For simplicity, it could also alias the existing ufixed/sfixed types).

2) To make this universal fixed point type system more like integer and its subtypes, we need a way to overload assignment statements, so that the type conversion and resizing could be "taken care of" automatically. Therefore I also propose that we allow overloading assignments by treating them as infix notation procedure calls (the same way we overload infix functions for operators). In order to do that, there would have to be some accommodations peculiar to these "procedure calls":

a) The only part of the assignment statement being overloaded is the actual data transfer itself. We assume that the equivalent process still surrounds a simple assignment for conditional/selected assignment statements, and that waveforms are handled after any data conversion is performed by the overloaded procedure.

b) The compiler would still recognize the size/type of the LHS of an assignment when evaluating the RHS for any anonymous literals, expansion of 'others', etc. This avoids the need to specify the range of the target conversion, as in to_ufixed(), etc. Note that these overloaded assignment statements could be used in initializations on declarations. Thus overload the assignment to allow assigning/initializing a "universal fixed point" from an integer (or float) literal.
       
c) We would need a way of disambiguating the built-in assignment statements, particularly within the overloading procedure implementation. We would either have to decree that any assignment statements used in an overloaded assignment procedure implementation are the native assignment statement. Or we could prefix such assignment statements in postfix notation with something like standard.":="(L,R); The latter would not work for initializers. Alternatively, we could decree that any assignment from a quantity of same type and range as the target is by definition the unadulterated assignment. This is something like the restriction on resolution functions to always return the value of the lone driver if there is only one driver.

d) For safety, we might want to limit assignment conversions to closely related types and subtypes. The ability to overload assignments opens up a lot of potential uses, not all of which would be in the spirit of the founding principles of VHDL. Perhaps we should tread slowly during the first steps. This would preclude assignments that convert from integer/real literals to sfixed/ufixed, but perhaps that would be an acceptable limitation.

e) The addition of overloaded assignments plugs a serious hole in the existing fixed point packages: assignments between like types and sizes, but differing ranges, are allowed, while silently changing the interpretation of the contents. For example if I assign a ufixed(3 downto -4) value into a ufixed(7 downto 0) variable, the transfer proceeds silently, but it is not numerically correct. 
	
The combination of these two proposed changes would provide the benefits of integer (excepting performance), signed/unsigned and sfixed/ufixed, with one numeric type system in a uniform and predictable manner.

I am completely open to other, even partial solutions, but I would prefer something that supports both integer and fractional values, preferably as seamlessly as possible.

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.