[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[f-cpu] Error with the fractional flag
Michael Riepe wrote:
> On Sat, Jan 05, 2002 at 01:42:21AM +0100, Yann Guidon wrote:
> > > Where did you find that (filename)? Must have been a pretty early
> > > version, I don't even remember that I wrote it. Welcome to the
> > > `f-cpu stone ages' ;)
> > Welcome everybody :-)
> > it's called "inc.vhdl" in the message #5926, the tag is
> > $Id: inc.vhdl,v 1.2 2000/10/24 00:39:25 michael Exp $
> Whee, that's old.
come on :-) at that time, it was sophisticated ...
> But it's not a complete INC EU, just a 64-bit incrementer.
that's the heart of the unit so it's good.
I think i'm going to update it a bit and include it
in a "EU wrapper" with more stuff.
In another mail,
> On Sat, Jan 05, 2002 at 01:42:23AM +0100, Yann Guidon wrote:
> > while reading through the ASU code, i read that
> > there is no "time" for a 1-bit most-shift
> > (which would be useful for fractional operations).
> Since fractional operands are in sign-magnitude (rather than 2's
> complement) form, we'll need more pre- and postprocessing than a single
<grumble>the definition i have is not sign-magnitude...</grumble>
what, then ?
My Analog Devices DSP manual says :
"Q16 is a special case of fractional number where all the bits lie to the
left of the radix point."
OOOPS ! I understand where i was mistaken...
it says : "In addition and substraction, both operands must be in the same
format (signed or unsigned, radix point in the same location) and the result
format is the same as the input format. Additions and substrations are
performed the same way whether the inputs are signed or unsigned".
I think i have mistaken with the multiply where 1Q15 * 1Q15 makes 2Q30,
so we have to shift the duplicate sign bit out. This means that only the
IDU and IMU have a fractional mode bit in the instruction ...
All my excuses ... there is no modification required in the ASU for
supporting fractional mode. So we can drop the fractional flag. sorry.
> > I thought about the following solution :
> > 1) duplicate the unit
> > 2) drop the input xors and propagate the change in the
> > rest of one of the unit. We thus get one sub and one
> > add operation
> > 3) add the post-shift
> > Since there is a provision for a simultaneous add/sub
> > instruction, this is fine :-) The new form of ASU
> > (optional) would have the same 2 write ports
> > and the simultaneous add/sub will disallow carry/borrow.
> If addsub is required to perform both operations simultaneously, we'll
> need to duplicate the unit anyway. On the other hand, there probably
> are many programs that perform lots of ADD operations but no SUB
> (address calculations, for example). Therefore, I'd rather keep the
> ASU as-is and add an ADD-only unit.
This is not consistent with the fact that no operation triggers
2 adds per cycle... And the ASU is pipelined.
however i would still like an ASU with the duplicated
(mirored) units, one being specialized for add and the other
for sub. It leaves some headroom in the timing and is DSP-friendly :-)
I'll soon release a little "programming course" which shows how
i optimised an already optimised DCT. It's not yet finished,
i have to make a testbench to verify that i have made no error.
> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/