RE: [vhdl-200x-ft] Bit rules

-- Jim Lewis wrote --

> Ryan,
> > PROPOSAL 4
> >
> > Define mixed signed/unsigned logic. Add "+", "*", "-", and "/"
operators
> > for all combinations of UFIXED/SFIXED. This is another fairly common
> > operation in signal processing hardware that is well-defined. David
noted
> > that bit literals need a type cast anyway, so we shouldn't have the same
> > problem as mixed arithmetic in numeric_std.
>
>
> I have concerns about this:
> Con:
> Based on usage of std_logic_arith, if we were to
> introduce a bit string literal format for these,
> these functions would limit the bit string literal
> to assignments.
>
> Remedy:
> Keep using conversion functions, there may be much
> to using this than a bit string literal format.

Fact:
It's not going to happen because you need to do a subtype conversion or go
through a conversion function to get a meaningful index range.

> Con:
> In consistent with numeric_std. I like consistency.
> OTOH, I like necessary functionality too.

"A foolish consistency is the hobgoblin of little minds." I like
consistency, too. What, then, is wise consistency?

I still wish we had these operations in numeric_std, but I've already
pontificated on that topic. The reasons I've heard for not having mixed
operators in numeric_std are (1) maintain backward compatibility, and (2)
convenience in some cases. With the fixed_pkg, (1) we have no required
compatibility (just desired consistency), and (2) the cases in which lack of
mixed arithmetic were convenient are no longer meaningful (see "Fact"
above).

So we can be consistent purely to be consistent, or we can add useful
functionality. Yes, this is different from numeric_std: it's better! Are
we not allowed to move on and make progress?

> Pro:
> How else would we do: Y_SFIXED <= A_UFIXED - B_UFIXED ;
>
> With unsigned, there was a simple way to do this by
> extending the left index and type casting. However,
> here the indicies are important. What would happen to
> the indicies in:
>
> Y_SFIXED <= SFIXED('0' & A_UFIXED) - SFIXED('0' & B_UFIXED) ;

You're right on. I don't know what happens to the indices, but it hasn't
been important with SIGNED/UNSIGNED. Also, type casting with constrained
subtypes can wreak havoc on my proposed ascending/descending conversion.
Conversion functions (kindly provided by David) are the way to go.
Incidentally, I think type casting and/or conversion functions will be much
less common with properly defined mixed operations.

> Question:
> Can you elaborate, "all combinations of UFIXED/SFIXED".
> I have some concerns about:
> Y_UFIXED <= A_UFIXED + B_SFIXED ;
>
> Too much overloading and it may be difficult to properly
> constuct a multi-operator expression:
> Y_UFIXED <= (A_UFIXED + B_SFIXED) + C_UFIXED ;
> ^^^^^^^^^^^^^^^^^^^
> Return of either SFIXED or UFIXED ok
> with the concerned case.

"All combinations of UFIXED/SFIXED" refers to the inputs, not the outputs.
If you look back at my result bit width rules, this just means defining
mixed operations in both orders (i.e. UFIXED+SFIXED and SFIXED+UFIXED). I
believe all the homogeneous operators return a result of the input type
except UFIXED-UFIXED. All the mixed operators return SFIXED.

> Keep pounding on it.

Thanks for the feedback. Are we there yet?

---
Ryan Hinton
L-3 Communications / Communication Systems - West
ryan.w.hinton@L-3com.com