[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/