Re: [oc] Interested in helping out

[WM <info@wilhelm.de>]

Hello David,

so not make me apear too stupid ;-)
I take the chance to comment your message.
You´re right but I was talking about something different.

At 12:10 27.03.00 -0700, you wrote:
>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.)

I was ONLY talking about the basic 68000. It has microcode since it is a
CISC and not RISC architecture. In principle RISC is better suited for PLDs.

>	-  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.).

I agree.

>	-  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.

This is true for the 680xx but the 68000 is simple and easy to test. I once
wrote simulation software for the 68000.

>	-  Would be difficult to get any performance out of it, because
>	   of the microcoded nature + lack of pipelining.  This means
>	   low clock speeds.

The original lacks pipelining and has microcoded structure but it would be
possible to implement without microcode and with pipelining. Of course this
consumes more gates than simpler instruction set based designs.

>> 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

As far as I remember I worked with the 68000 already in 1978 but I might be
wrong.

>	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.  

Today you even get sued if you don´t violate against any patents just to
try to stop your marketing.

>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.  

correct. I just wanted to say that usually the plain instruction set is not
the point - the way it is executed is the point. There is often a minor
difference.

>Many of these patents are very broad, so it's impossible to "avoid
>a too similar hardware architecture".  

of course it is often rather tricky. But it is not impossible. Just look to
the Transmeta design. They use some clever ways to walk around some Intel
patents.

>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).

Let´s keep optimistic ;-)
opencores is publishing information only. 

>> 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.  

I fully agree. 

>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.  

this is only part of the story. Motorola tried to decrease the microcode
and introduced the coldfire architecture which is just a 68k with seldom
used instructions missing. 
Just to remind: all PALM computers systems today use a 68K chip called
dragonball which is a 68K with integrated controllers for LCD etc.
The reasons to switch to PowerPC are more complex. The use in Apple Systems
made good development tools available and the RISC architecture is easier
to scale for pipelining and speed.

>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.   

I agree but Power PC would also be not adequate for FPGA.

>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).  

the success of Microchip and Scenix show there is still a big market for
such chips. Especially Scenix has pushed the speed envelope.

>	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.  

This reminds me to the Tensilica approach of a configurable microprocessor.
For embedded application specific designs (embedded is most times
application specific ;-) this makes sense.

>	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.  

I agree. Such a core could be easily added to other components is SOC designs.
For non SOC designs there are probabbly already enough cheap alternatives
like scenix etc.

Joerg

---------------------------------------------
        Wilhelm Mikroelektronik GmbH
 Sueggelstr. 31  -  44532 Luenen  -  Germany
phone ++49 2306 928280  fax: ++49 2306 928289
       internet: http://www.wilhelm.de
---------------------------------------------