[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rep:Re: [f-cpu] I forgot to tell you...



huh, Houston ? i got a little issue...

Michael Riepe wrote:
> > but bit 1 is not straight-forward at all). Currently i do it with a
> > lookup table in the integer world (that's lame but it should simulate
> > fast ;-D). Then there is a row of 8*(3+3=4) adders to make the byte results,
> > 4*(4+4=5) adders for the 4 shortint results, 2*(5+5=6) for the two lontgint
> > results and a final 6+6=7 adder for the full 64-bit result.
> 
> You can use my CIAdd procedure from the Generic_Adder package. Here's
> how to use it:
> 
>         function "+" (A, B : in std_ulogic_vector) return std_ulogic_vector is
>                 use work.Generic_Adder.CIAdd;
>                 constant w : natural := A'length;
>                 alias aa : std_ulogic_vector(w-1 downto 0) is A;
>                 alias bb : std_ulogic_vector(w-1 downto 0) is B;
>                 variable yy, cc : std_ulogic_vector(w-1 downto 0);
>                 variable pp, gg : std_ulogic;
>         begin
>                 CIAdd(aa, bb, yy, cc, gg, pp);
>                 -- we only care about yy here
>                 return yy;
>         end "+";

The problem here is that a N+N addition will return a N-bit result.
I remarked that when Simili elaborated the design and loudly complained
of a size mismatch...

How does one manage the cc, gg and pp outputs ? and how do we do
an aggregate of the result, that is independent of the to/downto (direction) ?

Another problem is the SIMD stuffs, which is even more complex than the adder tree...
but that's a good exercise to any VHDL designer wannabe ...

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE, who's going to sleep now...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/