Jim,
I'm not sure I can pronounce what is good design and what is not. I do know
that casting is not necessary if mixed operators are defined. Converting
ufixed to sfixed may also result in overly conservative result sizes. For
example,
signal a : UFIXED(0 downto -9);
signal delta : SFIXED(-3 downto -9);
signal result1 : SFIXED(1 downto -9);
signal result2 : SFIXED(2 downto -9);
result1 <= a + delta;
result2 <= TO_SFIXED(a) + delta;
since TO_SFIXED() adds a '0' on the top of a UFIXED. The conversion
function is loses information: the mixed operator knows a to be in the range
[0, 2), while the matched operator must assume TO_SFIXED(a) can be in the
range [-2, 2).
I really want mixed arithmetic for the multiply operator. That is the only
place I am using mixed arithmetic in current designs.
The fixed point operators have enough information to properly calculate and
(usually) properly size the result for matched and mixed arithmetic. I
expect to be able to do it. I can't think of a reason for it to be bad
design. Am I missing something?
---
Ryan Hinton
L-3 Communications / Communication Systems - West
ryan.w.hinton@L-3com.com
-----Original Message-----
From: Jim Lewis [mailto:Jim@SynthWorks.com]
Sent: Wednesday, July 07, 2004 12:27 PM
To: Hinton, Ryan W @ CSW-SLC
Cc: 'vhdl-200x-ft@eda.org'; vhdlsynth@vhdl.org
Subject: Re: [vhdl-200x-ft] Bit Rules & methodology for handling math
issu es
Ryan,
> C. Encouraging good DSP design by forcing the designer to specify what
> happens to the bits.
I agree. So the following is good:
Y_ufixed <= Resize(A_ufixed + to_ufixed(B_unsigned), ...) ;
Is it not also a good design practice to encourage
designers to specify when they are mixing operand types?
Y_sfixed <= Resize(A_sfixed + to_sfixed(B_ufixed)) ;
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received on Wed Jul 7 11:45:12 2004
This archive was generated by hypermail 2.1.8 : Wed Jul 07 2004 - 11:45:13 PDT