Re: [openrisc] Getting the size down

["Jim Dempsey" <tapedisk@ameritech.net>]

You could add an unimplemented instruction trap. The trap could be designed
to be fast and bypass the CPU's interrupt processing technique. e.g. the IP
and (some of) the flags are latched and the interrupt flags are disabled
(including unmaskable) and then transfer is made to the emulation code which
may or may not reside in the same address space as the standard memory. If
interrupt latencies are an issue the emulation design could incorporate a
redo instruction instruction.

Using this the binary code generated by gcc, for use with system with
multiply, divide, ... would be unchanged. Also the runtime system code would
be unchanged.

Jim Dempsey

----- Original Message -----
From: "Michael Unnebäck" <michael@voxi.se>
To: <openrisc@opencores.org>
Sent: Wednesday, April 23, 2003 3:31 AM
Subject: 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

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