Re: [oc] Interested in helping out

[David Kessner <davidk@free-ip.com>]

WM wrote:
> >       -  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 microcode for a 68000 is still rather large.  I won't say that
it's too large for an FPGA, but it's close!  I once looked into doing
a 68HC11 and that microcode was, in my opinion, huge!  It was at least
three times the size of the Free-6502's microcode.  In fact, that was
why I did the 6502 rather than the 68HC11.

I would estimate that the microcode for a 68000 would take up
about 500 to 1000 Virtex "slices", and about 1500 to 2000 slices for
the whole 68000.  At the same time you can make an efficient and very
fast 32-bit RISC CPU for about 2000 slices-- including cache 
controllers and the like.


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

In general, a CISC CPU is about 100 times harder to test and verify
than a simple RISC CPU (a.la. Power PC, MIPS).   The reason is that
there are many more things to verify under many more scenarios.  
Simply testing for proper status flag behavior is non-trivial.

I'm not saying that a 68000 is impossible-- just very difficult.


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

I remember seeing an FPGA version of the 68000 for sale that didn't
use microcode.  Rather, it used state machines, etc.   I'm not 
convinced that this is the "faster" approach.  

Adding pipeline stages to a non-pipelined CPU like the 68000 can 
cause unwanted side effects.  They include an increase in cycles
per instruction and a decrease in work performed per clock.  Where
the RISC CPU's benefit from pipelining is that the work performed
per clock remains the same or increases with pipelining.


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

I got these dates from two separate web sites (which had the
same dates on them).  But with today's "quality of content" on 
some web sites, it's entirely possible that they are both
wrong!  :(


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

I have been on the receiving end of an unjustified patent 
infringement lawsuit.  It has made me very cautious about these
things.  Fighting a lawsuit of this type requires an intolerable
amount of money (more than US$1 million).  The end result of
this is that we cannot look for justice in the court room if
we never have the money to get to court.  And even then, there
is often no justice.  Therefore, it pays to plan ahead and 
seriously consider such things before writing a new core.


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

With modern processors (Power PC, MIPS, ARM, etc.) often the 
instructions are not patented, but the methods behind the instructions
are patented-- and patented in such a way that implementing the
instruction in any way will violate the patent.  For example...

Company A might have a patent along the lines of, "A special 
instruction is used to switch endian modes during execution of
software".  Company A might also have a CPU that has an "XENDIAN"
instruction that switches the endian mode.  If you make a core
of this CPU and implement the XENDIAN instruction then you will
violate the patent-- regardless of how that instruction is
executed.  

The only way to get around that is to not implement the XENDIAN
instruction.  But this is not a sure thing either.  Lexra did 
something similar with one of their core.  Executing that special
instruction caused an invalid instruction exception which could
be trapped and emulated in software.  MIPS still sued, claiming
that it didn't matter if that instruction was done in software
or hardware, it still violated the patent.  The strange thing
is that Lexra doesn't supply that software, it only suggests
to it's customers that it can be done.  But apparently prompting
people to violate a patent is just as bad as violating the patent
themselves.

The XENDIAN instruction is a made up example.  But there are plenty
of other instructions that are real world problems!  The MIPS 
instructions LWL, LWR, SWL, and SWR are patented in a similar
way.  So are many of the new SIMD instructions on various CPU's.
It wouldn't surprise me at all if the conditional execution flags
used in almost every DSP are patented, as well as just about 
everything related to super scalar execution.  

The 68000 instruction set probably doesn't have these issues, 
fortunately.  It's old enough that the designers probably weren't
patent crazy.  But it is worth checking into.  But I would be
almost certain that there are patent issues with the 68040's MMU
and FPU instructions...



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

That won't stop Intel from suing!  :(


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

It doesn't matter.  By designing cores and making them available for
download, Opencores.org is making itself open to patent infringement
lawsuits.  


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

Right.  But lately (the past year or two), Coldfire is also being
replaced
by the PowerPC.  


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

A non-superscailer Power PC, without MMU and FPU but including a
sizeable
cache, would fit nicely inside a Virtex-400E with lots of room to spare.

Of course, the Power PC is patented out the wazoo!  Perhaps the only
chip with more patents is the ARM.



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

Tensilica is similar, but has significant differences.  To my knowledge,
Tensilica allows you do design the core first, adding blocks that you
would want, and then it configures the compiler/assembler to support
that CPU.  What I proposed is the reverse:  write your code first then
configure the core appropriately.  

My approach potentially has better efficiency, since the decision to cut
blocks out is made based on the real software and not what the engineer
thinks might be needed sometime in the future.  Engineers will routinely
make the CPU more featureful than what is really needed, and the 
granularity of the pruning process won't be as fine.  

Take a barrel shifter, for example.  With Tensilica you decide to 
include or not include the entire shifter.  With my approach, software
will determine that you only ever shift right by 1, 4, and 7 bits so
the unused portions could be safely removed.  


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

I think that such a processor would take less than 400 "slices" of a 
Xilinx Spartan-II.  That's about 50% of a XC2S-50, or about 20% of an
XC2S-150.  While not as cheap as some PIC's, once you consider the 
level of performance, integration, and flexibility it becomes economical
for some (but not all) applications.



David Kessner
davidk@free-ip.com
http://www.free-ip.com