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

RE: [fpu] FPU operations




> > 2. When I asked about contention on the result
> bus, it
> > was another way to ask about different execution
> > speeds of the FPU units. 
> > For example:
> > ADDER needs 3 clks
> > MULTIPLIER needs 4 clks
> > and a mul instruction is issued on clock before
> add
> > inst what will happen on the result. Both add and
> mul
> > instructions have to write to the result. as I
> know
> > there should be a method to stall the adder, how
> can
> > you manage this kind of operations?
> > 
> 
> Several possible solutions:
> - if you provide 'stall' input to the FPU then OR1K
> can assert stall
> when needed
In this case the FPU has to manage more things than
what it is supposed to do. each unit should has this
input and also the comparator that runs in parallel
must know how to stall

> - if you don't provide 'stall' input, then OR1K will
> either handle them
> at the output correctly (adder has different output
> then multiplier,
> right !?) OR it will never issue insns that could
> lead to this

I think it is useless to have different buses for each
operation, may be internally it will be possible. If I
put these different interfaces the cpu will see
different execution units


> 
> > 3. OK about the comparison status signals we have
> also
> > to add zero status but all these comparisons have
> to
> > execute in parallel with all instructions.
> > 
> I guess so.
> 

Sitll I do not know how can we make run in parallel if
each execution unit has different speed.?



> > 7. Since we are working on HDL coding why do not
> we
> > agree on the same structure and code it and have
> one
> > in VHDL and one in verilog. ( as I remmber OR1K
> was
> > written in VHDL is there any plans for writing it
> in
> > verilog?)
> > 
> Well sort of. I think for a couple of months I am
> not touching VHDL. I
> like Verilog very much and OR1320 (former OR1003
> never to be published
> in VHDL actually) is going to be verilog. This on
> also goes to silicon
> (together with OR1601 which is also verilog). But I
> don' think it is a
> problem to mix VHDL and Verilog. Just isn't too
> smart idea to do that.
> 
> > 
> > 8. I am going to modify the flow charts, block
> > diagrams and the design document soon according to
> > these discussions
> > 
> OK.

I updated the block diagram and the document, they are
located on teh same place.

> 
> BTW since Rudi is working on its own and Jamil on
> its own FPU. How
> about more closer development where both FPU would
> be basically the
> same except of the HDL used. This way there would be
> one document, one
> 'C' (or Java) test vector generator, easier to fix
> bugs etc. And more
> team spirit !
> 

I agree with that


Regards
Jamil Khatib

__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/