Re: Universal Processor (was Re: [oc] x86 IP Core)

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

CodeMorphing is considerably complex and is probably best left for the big
boys with a sizable development budget. I think what would work better is to
look at older design solutions to produce a simplified solution. In
particular I would like to suggest using a design derived from Bit-Slice
technology such as the AM2903 (AM2901 with mul/div) and AM2910 program
sequencer.

Then instead of using ROM for the control store (as in traditional design)
you use internal RAM blocks in the FPGA. For ease in development of control
store code for emulation of x86 or other instruction sets you would first
produce control store code to emulate the OpenRisc (with the 2903). The
intention would be to have control store to emulate both OpenRisc and
"system under test". In this manner you could use (develop) tools written in
C running in the OpenRisc emulation. (e.g. instruction traces) but yet not
suffer a performance hit when executing the emulation code.

The design of the AM2903 permits it to perform multiple operations within
one clock cycle making it an efficient choice for writing an emulator. In
some cases I could see some x86 instruction emulations taking only one
AM2903 clock cycle. Back in the early 80's I had some experience using the
AM2901 and AM2910 in emulating another processor. It took a little bit
getting used to but it was not all that difficult to master.

When you first look at the AM2903 your first impression will be "it's not a
complete processor". And that is precisely the point. The processor becomes
complete with the addition of the control store and the supporting
components placed around the core. There is little excess weight.

A good starting point would be

http://www.altera.com/products/ip/processors/m-cas-2901.html
(Which references http://www.cast-inc.com/)

Jim Dempsey

----- Original Message -----
From: "John Dalton" <john.dalton@bigfoot.com>
To: <cores@opencores.org>
Sent: Sunday, August 03, 2003 11:17 PM
Subject: Universal Processor (was Re: [oc] x86 IP Core)


> I'm not aware of one (I'll keep an eye out), but your
> request has given me an idea for a core.  I don't
> think I will have time to work on this idea, but if anyone
> thinks it is a good idea, they are free to develop
> it.
>
> Basically, the idea can be described as a hardware
> version of 'code morphing' technology.  Code morphing
> processors on the fly translate processor instructions
> (such as x86, 68000, etc) into a 'native' format which
> is then executed.  The 'translation' step is invisible
> to the outside world, so a program runs just as is it
> were running on an 'x86', 68000 or whatever.
>
> What if we had a processor that executed a versatile
> 'native' instruction set.  Prossibly this processor
> would be based on the OpenRisc?
>
> In conjunction with this proessor, we design a bunch
> of 'translators' which sit between the processor and
> program memory, x86 instructions might go into
> this block and OpenRisc instruction come out.  These
> OpenRisc instructions would then be executed.  In this way,
> the OpenRisc would act like an x86.  Translators could also
> be designed for the 68000, Z80, ..., name your processor.
>
> What if we generalised this concept and wrote a 'translator
> compiler'?  This would be a program that abstracts the
> methods used to write a translator.  Its input is a specification
> of the instruction set to be 'traslated' (maybe use the same
> language which is used to describe s processor to gcc?).
> Its output is the VHDL, verilog or RTL for a translator to
> translate instruction set 'X' to OpenRisc.
>
> Steps to design/build an arbitrary processor would now
> become:
> 1) Write a gcc machine description (.md) file for a processor.
> 2) Automatically generate HDL for a translator/OpenRisc combination
>     (using the generator described above)
> 3) Synthesise the resulting HDL files.
>
> Perhaps this idea has already been done, but if not, any takers
> to do it?
>
> This project would 'leverage' the opencores process as existing
> processor descriptions could be reused each time a 'new'
> processor is to be designed.
>
> Regards
> John Dalton
>
>
>
> --
> To unsubscribe from cores mailing list please visit
http://www.opencores.org/mailinglists.shtml

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