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

Re: [openrisc] Getting the size down



You could consider to remove or reduce the multiplier. OpenRISC is able to
multiply two 32-bit values resulting in a 64 bit result. 

1. you can remove the multiplier completely (by setting the result to a constant
value, zero) and do multiplication in software. Changes in gcc is needed.

2. you could change the implementation of the multiplier. The current design
multiplies in two cycles. A shift-and-add implementation is much smaller. And
slower, typically 64 cycles. Changes needed in openrisc implementation. The
pipeline must be stalled while the calculation is done. No change is needed in gcc.

3. you could minimize the multiplier. For a certain design 32 bit by 32 bit
resulting in a 32 bit result might be enough.

Alternative 1 & 2 are used by ALTERA for their NIOS core. Depending on your
input both the NIOS core and gcc files are produced by their generator.

I used the third alternative for the design I made for Voxi (which uses no
uCLinux, only our software run as the only process). 

Implementation consideration like these, if fully supported by verilog
implementation and gcc port, makes OpenRISC even more competetive.

regards
/Michael Unneback

Quoting Damon Brantley <brantley@mcloudteleco.com>:

> I am currently working with a board made by Digilent that has a Spartan IIe
> with 300k 
> gates. By removing all the cache and debug logic, the openrisc cpu uses
> about 84% of the available space.
> My last test project,which interfaced with the vga display, pushed the
> utilization up to 96%.
> Are there any other places where I can do some pruning and get the size
> down more. To get ucLinux up and 
> running I need at least enough space to add the memory controller to access
> some external memory 
> and the UART.
> 
> 
> --
> To unsubscribe from openrisc mailing list please visit
> http://www.opencores.org/mailinglists.shtml
> 



--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml