[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] SIMD and exception


Michael Riepe a écrit :

Two other questions today :)
1) i'm thinking my current way to handle SIMD will not be correct. For the moment, in each stage, i check if i do operations in 32 bit or in 64bit. The problem is it's add a MUXto each stage... and it's at lease 2 gate deep.

I count MUXes as d=1/t=1 (provided that the select line has less delay than the datapath).
ok thx...

So i think to other methods:
- select in the good way in the first stage (with a decoder, to prevent unused path to switch transistors), and select the good result in the last stage. The problem is it will use twice more component (for instance i use only one 64 bit generic_adder for both SIMD format, but now i will to do addition for single and an other addition for double float). It will also add twice more registers. The problem here is the area.

Well, some parts have to be duplicated - e.g. the exponent subtractor. You'll also need separate shifters and rounding logic for each chunk.
The generic adder, however, can be split in the middle without increasing its delay, by using custom versions of CLA and CSV (that's what I did in the IAdd unit).
So here is a problem:
There is in the first stage the exponent substraction. For single, exponent size is 8 bit, so the substractor delay is 6.So it just fit into the stage
But for double, it takes more, so i will have to slip it between stage 1 and stage 2 (putting csv and cla). So the two datapathes (single and double) will not arrive on the same time on the main adder (mantissa adder). So i cannot use the same adder for both operation (except if i bufferize single datapath and "wait" for double one).
Is there any restriction about register number because it will add lot of registers (for double and single datapath)...

- to convert everything in 64 bit and do all operation in 64 bit (i think this is how the pentium works), BUT the problem is in the last stage, i will have to cut the mantissa and exponent, and this will add some logic, so increase the number of stage by at lease one (especialy for the rounding step)

I guess that's not an option.

no prob

See above. You can assume that the target technology provides MUXes that are faster than the obvious implementation:

Y := (Sel and A) or (not Sel and B)

which would have d=2/t=2 for the datapath.

And is it the same way for logic equation:
i mean (A, B, C are std_ulogic, not vector):
(A and B) or C
d=2 ?

Yes, and t=2. It may be faster when AOI gates are used, but they're not generally available. In an FPGA, this will also be relatively fast (one cell delay).

(A xor B) xor C

d=2, but t=4 (if the target technology really uses XORs).

Again, this is relatively fast in an FPGA where most functions with 3 or 4 operands can be implemented in a single cell (or row of cells).

On a full custom chip, a 3-input XOR may be implemented as

Y := (A and B and C)
or (A and not B and not C)
or (not A and B and not C)
or (not A and not B and C);

or even

Y := not (
(not A and not B and not C) or
(not A and B and C) or
(A and not B and C) or
(A and B and not C));

which takes 3 inverters and an and-or-invert (AOI) gate, resulting in d=2/t=2. But on the other hand, you wrote "xor", so the synthesizer may create just that.

I suggest you use work.misc.xor3 (available for both std_ulogic and std_ulogic_vector) if you need a 3-input XOR. It's easier to adapt a single function to the target than to scan the whole F-CPU for stray 3-input XORs.

On the other hand, if you *know* that one of the inputs arrives late, you can as well use

Y := (A xor B) xor C; -- when C arrives late

u = (Sa and not(s) ) or (not(de xor Sa) and s)
is d=3?

Approximately d=3/t=4, but:

    -- d=2/t=3
    if s = '1' then
        -- d=1/t=2
        u := de xnor Sa;
        -- d=0/t=0
        u := Sa;
    end if;

Or, if Sa arrives substantially later than de and s:

    u := Sa xor (s and not de);

where the delay varies between d=1/t=2 (Sa -> u) to d=3/t=4 (de -> u).

Just try to keep the balance ;-)
ok thank you michael !


To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/


~~ Gaetan ~~

To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/