[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [fpu] Architecture
------
>Well execution units gets both operands (either from register file,
>sign-extended immediate or what ever - it is responsibility of the issue
>stage to deliver propoer operands to particular execution unit) and
>operation code (which operation must be carried out on operands). Pipeline
>stalling and other control operation over pipeline are carried out in
>datapath controller and are not part of execution units (so datapath
>controller takes care for multicycle FP instructions).
------
I fully support this idea....In fact, issue unit has to just issue the FPU
inst and operands to FPU and do not even need to know whether they are
single or multi cycle ( I am sorry, don't have much idea about OR1K, assuming
there is no out of turn execution and CPU has to wait until FPU finishes
its execution). In our architecture here, FPU acknowledges to the issue
unit when it is going to finish the execution (in fact one clock b4 that, so
issue unit can continue w/o missing a cycle). That way, FPU could be roughly
independent of CPU.
One more advantage of above approach is....we can have one simple FPU (just
for basic operation mult div etc) and we can also have coprocessor which may
be optional....because FPU and cop can be treated the same way by issue unit...
( i mean issue the inst and operands and FPU/cop will acknowledge if the intsruc
tion is meant for them).
regards,
sagheer.
*************************************************************
Sagheer Ahmad .............. Infineon Technlogies
Ph. 408-501-6774(O) .............. 1730, North First St.
Sr. Design Engineer .............. San Jose, CA.
**************************************************************