[vhdl-200x-ft] Use of String Literals in Fixed Point and Floating Point Operations

David,
>> In reviewing your DVCon Slide 11 I find:
>> Do not use string literals in operators
>> A <= B + “000100”;
>>
>> This is interesting. You can detect and disallow it.
>> Alternately, since you can detect it, would another
>> reasonable approach be to caste the dimensions of
>> "000100" to be the same as B?
>
>
> How do I know that was the meaning? The problem is that
> you could mean:
> 6 downto -3 <= 4 downto -3 + 5 downto -2
> I'd rather not guess at all then guess wrong.
>

The above seems to say that "type saftey is important".
Note I lean this way quite abit, however, it
seems inconsistent with the conclusion we reached for
textio. For a textio read that does not return enough
data is an assertion error, but not a fatal error, and
no value is returned hence, for some implementations the
value will be the same as the previous value. This
seems to say that strongly enforced checking is not
required - make sure to read your logs.

If we want to ensure type saftey in literals, then
we may want to create fixed and floating point
string literals. Perhaps a task for the next revision.

Along the same lines, it may be useful to be able to
extract the subtype of a data object so we can coerce
the dimensions of another object. For example:

   signal A : sfixed(4 downto -3) ;
   signal Y : sfixed(5 downto -3) ;

   Y <= A + A'subtype("00110100") ; -- maybe it should be a'type?

------------------
Now going in the other direction from strict type saftey.
When I do the following, 6.5 gets sized to be the same
size as A right?

   Y <= A + 6.5 ;

However, in the following case, the literal is useless.
   signal A : sfixed(4 downto -3) ;
   signal Y : sfixed(5 downto -3) ;

   Y <= A + "00110100" ;

With the textio "play on" rule of thumb, it
would seem natural that if the literal had the same
length as A above, then assume it is the same range.
It is the most reasonable interpretation. If I wanted
something else, I would have to define it as a constant
(which I would probably do anyway).

Lets suppose we put this rule into effect. When happens
if they really ment that the literal had different
dimensions than the non-literal argument (such as
(5 downto -2) as you suggested above)? The subprogram
assumes the literal size to be (4 downto -3) and the
size of the result is (5 downto -3) which does not
match the size of the target Y (6 downto -3), so we get
an error.

   signal A : sfixed(4 downto -3) ;
   signal Y : sfixed(6 downto -3) ;

-- Intended literal dimensions are (5 downto -2)
   Y <= A + "00110100" ;
                    \____________/
(6 downto -3) (5 downto -3)

So this does not seem so bad. You make an assumption
about the size and if you are wrong, then it results in
a run time error.

In this view of the world, to work with a literal as a
different range, it can be sized by using a constant
or a subtype:

   constant LeftObj : sfixed (4 downto -3) := "00110100" ;
   subtype RightType is sfixed(5 downto -2) ;

   signal Y : sfixed(6 downto -3) ;

   Y <= LeftObj + RightType'("00110100") ;

> However, in the "package generic" version of the floating point
> package, I CAN make this assumption. Useful?

For the generic package, the IO on the subprograms
is a constrained type. Therefore, all literals
get converted to that type with that range. So
with the package generics, if add two literals,
they will be interpreted to be the same type as the
object being assigned to:

Y <= "some literal" + "some literal" ;

It will be an error if the literals do not have exactly
Y'length values.

For the non-generic package, or at least the one that does
not constrain the exponent and fraction widths, then
the above does not apply. In this case the formal to
the subprograms is unconstrained. Floating point is
different than fixed point. In floating point, both
inputs and outputs must be the same size. We do not
have access to the output, so we cannot support addition
of two string literals, however, it would be reasonable
to assume that any string literal that has the same
length as the other argument also has the same dimensions.

--------------------------

Note I am not saying that we should do this.
If we do nothing and report it as an error now, we can
always fix it later.

I lean more towards correct by specification. I would be
more comfortable if textio died on a bad read. My
assumption is that the file is perfect and if a read
detects it is not perfect - die. To make sure the file
is perfect, pre-scrub the file. Methodology wise,
running a test for 24 hours and having it fail or
repeat the value from a previous read are bad. Which to
me means that pre-scrubbing the file is requried in
either case, so the continue on, does not help me much.

I would be most comfortable having fixed and floating
point string literals or using constants or using type
qualifiers to identify the type.

Having said this, making an assumption that a fixed or floating
point string literal is has the same dimensions as the
non-literal argument (provided they are the same length),
bothers me less than having textio reads only be an assertion
error.

Cheers,
Jim

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~