[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] Interested in helping out
Normally, I try to stay out of these discussions. But I think I'll
throw in my two cents worth here...
WM wrote:
> yes, a 68K core would be very interesting since there is very much software
> and the design is not very complex. A clever implementation should have a
> chance to get sufficient performance.
The 68K is not a good choice for a core. Especially a core intended
for an FPGA. Here's a couple of reasons why:
- Microcode ROM is very large. Too large for just about
any FPGA. (Assuming a 68020 or higher.)
- The amount of logic required would be similar or larger
than a much faster and much more efficient 32-bit RISC
processor (MIPS, OR-1000, etc.).
- From a software perspective, the 68K is simple. From a
hardware perspective it is much more complicated than a
Power PC or MIPS. This means that it will be difficult to
make it _perfectly_ compatible, and even more difficult to
test for compatibility.
- Would be difficult to get any performance out of it, because
of the microcoded nature + lack of pipelining. This means
low clock speeds.
> Regarding the 68K architecture I´m not sure but the design is from the late
> 70th (really!) and as far as there were patents they´re probably obsolete.
Here's a rough outline:
68000: 1979
68010: 1984
68020: 1984
68008: 1985
68030: announced 1986, shipped in 1987
68040: announced 1989, shipped in 1990/1991
Much of this is recent enough that you have to worry about
patents, etc.
> Usually the chance to protect the basic ISA are rather limited. You just
> have to avoid to use a too similar hardware architecture or identical
> microcode. A lot of the original 68K instructions uses microcode.
These days it doesn't take much to get sued. There are many
companies that have patents on specific instructions, etc.
For example, MIPS has patents related to endian issues and
unaligned loads and stores. MIPS, Motorola, etc., have patents
on SIMD stuff. There are lots of patents by everyone on caches
and instruction prefetches.
Many of these patents are very broad, so it's impossible to "avoid
a too similar hardware architecture".
I have not personally done a 68k patent and trademark search.
My advice here is to be careful and don't assume anything.
It wouldn't take more than one lawsuit to shut down opencores.org
(or free-ip.com, for that matter).
> Just a few years ago 68K was the most popular CPU for embedded
> applications. Today MIPS and ARM took over the leading position. As far as
> I know there are still more 68K CPUs than 80x86 devices (corrections welcome!)
> What most people like most (me too) is that programing 68K in assembly is
> very easy.
The 68K fell out of favor in the embedded world about 6 to 8 years
ago. The main thing that has kept it going lately is that the
product life span of embedded computers is significantly longer
than PC's or consumer electronics (10-20 years vs. 1 to 5 years).
The #1 reason why the 68K fell out of favor is cost. The 68K is
an expensive device to manufacture, so the bang/buck ratio is low.
When you compare the die size of a 68040 with a Power PC (at the
same feature size), the Power PC is a lot smaller. Since the
cost of a chip is directly proportional to the die size, the 68040
is much more expensive. In addition, the Power PC is much faster
than the 68K (due to pipelining, max frequency, etc.) and it's a
no brainier to use a Power PC.
Motorola realized this when they were designing their embedded
versions of the 68K (68EC040, QUICC, etc.). Motorola soon realized
that the Power PC was the better choice and switched to it. Now you
see lots of embedded Power PC's that have taken over.
A similar thing applies to CPU cores and FPGA's. A 68030 in an FPGA
would require a lot of logic and complexity, resulting in something
that is larger and slower than an equivalent Power PC/MIPS/ARM/etc.
It is my opinion is that if you're engineering resources are
limited (and who's isn't), then your effort is better spent
designing a different CPU than the 68K.
Here is an idea that I'd like to develop but don't have the time
for:
Design a small and very fast 8 bit RISC CPU. Make it
similar to the MIPS R3000, but remove many of the advanced
features that handle pipeline hazards, etc. The key goal
is small and fast. No caches (all memory is on chip).
Integrate the assembler/compiler with the "core generator".
The assembler/compiler would analyze your program and
effectively "comment out" the portions of the VHDL code
that are not used by your program. Thus, if you only use
some parts of the barrel shifter then the unused parts are
not turned into logic. Unused portions of the instruction
decoder, ALU, etc., are also removed. For most applications
this could remove 20-40% of the logic and give a
corresponding clock speed improvement.
Remember that this CPU would be used somewhat like a PIC,
in that most code is hand written assembly with limited
amounts of RAM/ROM. It isn't intended to replace a more
full features uC like the 68HC11 or Z80. On the other hand
it should only take less than 400 Virtex "slices" and run
at over 100 MHz in a Spartan-II. There is a huge market for
such a uC that has remained untapped so far.
An alternative to this would be a similar 16/32 bit DSP,
also with a corresponding "self-optimizing assembler/core".
Although the market for this is smaller.
Hope this helps!
David Kessner
davidk@free-ip.com
http://www.free-ip.com