Home grown CPU core legal?

[Bruce P.]

I've always been interested in designing my own 8-bit CPU core in an
FPGA for educational purposes. After visiting www.opencores.org, it
seems the easiest/most popular way to go about this is to make the CPU
core be compatible with an existing ISA (Instruction Set Architecture)
from an available device (e.g. 8051, PIC, etc.). That way I could use
readily available development tools to write code, debug, create a hex
file, etc.

If by some chance I ever used my home grown, ISA compatible, core in a
commercialized product, would there be legal issues? Chances are I
would never use my own and would probably use a Nios or Microblaze
instead, but if I just needed a simple little core, it could prove
useful.

I know very little about the IP core business, but I've seen off the
shelf compatible CPU cores for sale, so I'm guessing these IP
companies must pay companies like Microchip when they sell a PIC
compatible core?

Just curious if anyone has any insight into how all this works.

Thanks.

-Bruce

 

[Kolja Sulimma]

If by some chance I ever used my home grown, ISA compatible, core in a
commercialized product, would there be legal issues? Chances are I
would never use my own and would probably use a Nios or Microblaze
instead, but if I just needed a simple little core, it could prove
useful.

AFAIK (and IANAL) the only effective legal way against a processor
clone are patents. This means that very old designs like the 8051,
6502, PIC, etc. should be no problem.
The patents only affect ways to design or implement the processor, not
the ISA. So if you knew the patents you could design the CPU in a way
that does not violate the patent. Unfortuanatle as an amateur you can
never be sure what kind of wierd patents suddenly surface out of
nowhere.

The ISA can not be protected effectively. This does not mean that a
pissed processor vendor will not send a hord of lawyers after you to
scare you or to cover you in loads of expensive paperwork. Therefore
you should stay away from CPUs from companies that live from processor
licensing fees. (Like ARM or MIPS)

If you really want to play it safe you should implement a SPARC ISA.
That's an open standard.

Or do a reimplementation of picoblaze or microblaze or xr16. I believe
that Xilinx won't mind another Microblaze implementation that helps
selling there Chips. (Göran, can you comment on that?)

And Jan Gray explicitely stated that he does not object to
reimplementations of his xr16 design.

Kolja Sulimma

 

[Goran Bilski]

Hi,

I can't see why Xilinx would be against a clean room implementation of
MicroBlaze.
It would actually be quite interesting.
We actually want to promote the use of MicroBlaze.
We are not getting our money from MicroBlaze sells but rather on the
FPGAs that MicroBlaze uses.
If someone did a clean room, open source implementation of MicroBlaze it
would probably letting us sell more FPGAs.

As Kolja said, you can't really effectively patent an ISA, only an
implementation.
BUT an implementation can have certain features which you can patent and
thus make it hard to design around that patent.
ARM has the shadow registers at interrupts and MIPS has the unaligned
word access handling,...

Even if you did a clean room implementation of ARM and avoid all
patents, ARM will sue you to the end.
So unless you have big financial backing that will pay your lawyers, you
will not win.

Göran

Kolja Sulimma wrote:

If by some chance I ever used my home grown, ISA compatible, core in a
commercialized product, would there be legal issues? Chances are I
would never use my own and would probably use a Nios or Microblaze
instead, but if I just needed a simple little core, it could prove
useful.



AFAIK (and IANAL) the only effective legal way against a processor
clone are patents. This means that very old designs like the 8051,
6502, PIC, etc. should be no problem.
The patents only affect ways to design or implement the processor, not
the ISA. So if you knew the patents you could design the CPU in a way
that does not violate the patent. Unfortuanatle as an amateur you can
never be sure what kind of wierd patents suddenly surface out of
nowhere.

The ISA can not be protected effectively. This does not mean that a
pissed processor vendor will not send a hord of lawyers after you to
scare you or to cover you in loads of expensive paperwork. Therefore
you should stay away from CPUs from companies that live from processor
licensing fees. (Like ARM or MIPS)

If you really want to play it safe you should implement a SPARC ISA.
That's an open standard.

Or do a reimplementation of picoblaze or microblaze or xr16. I believe
that Xilinx won't mind another Microblaze implementation that helps
selling there Chips. (Göran, can you comment on that?)

And Jan Gray explicitely stated that he does not object to
reimplementations of his xr16 design.

Kolja Sulimma

 

[Symon]

Hi Goran,
So, playing devli's advocate, Xilinx wouldn't mind if the clean room
Microblaze was targeted at their competitors' devices? Or do you think that
no one would do this because Microblaze only efficiently fits the Xilinx
devices? Or the competitors have their own solutions for their parts?
I wonder....
cheers, Syms.


"Goran Bilski" <goran@xilinx.com> wrote in message
news:boodq5$bgr2@cliff.xsj.xilinx.com...
Hi,

I can't see why Xilinx would be against a clean room implementation of
MicroBlaze.
It would actually be quite interesting.
We actually want to promote the use of MicroBlaze.
We are not getting our money from MicroBlaze sells but rather on the FPGAs
that MicroBlaze uses.
If someone did a clean room, open source implementation of MicroBlaze it
would probably letting us sell more FPGAs.

 

[Goran Bilski]

Hi Symon,

I don't think Xilinx would be happy but I don't think we would do
anything against it.
I also think that MicroBlaze will be better implemented in our FPGA than
in our competitors.

If someone did a clean, pure RTL implementation of MicroBlaze, I think
that someone will very quickly try it on our competitors FPGA.

I have a pure RTL version of MicroBlaze and it doesn't look good when
targeting other devices than Xilinx's devices.

But someone started from scratch, the design would probably not be so
biased against Xilinx.

Göran

Symon wrote:

Hi Goran,
So, playing devli's advocate, Xilinx wouldn't mind if the clean room
Microblaze was targeted at their competitors' devices? Or do you think that
no one would do this because Microblaze only efficiently fits the Xilinx
devices? Or the competitors have their own solutions for their parts?
I wonder....
cheers, Syms.


"Goran Bilski" <goran@xilinx.com> wrote in message
news:boodq5$bgr2@cliff.xsj.xilinx.com...
Hi,

I can't see why Xilinx would be against a clean room implementation of
MicroBlaze.
It would actually be quite interesting.
We actually want to promote the use of MicroBlaze.
We are not getting our money from MicroBlaze sells but rather on the FPGAs
that MicroBlaze uses.
If someone did a clean room, open source implementation of MicroBlaze it
would probably letting us sell more FPGAs.

 

[Nicholas C. Weaver]

In article <b890a7a.0311100755.72deef43@posting.google.com>,
Kolja Sulimma <news@sulimma.de> wrote:

The ISA can not be protected effectively. This does not mean that a
pissed processor vendor will not send a hord of lawyers after you to
scare you or to cover you in loads of expensive paperwork. Therefore
you should stay away from CPUs from companies that live from processor
licensing fees. (Like ARM or MIPS)

I'm not so sure about this, look at some of the unique ISA features
(eg, the initial conditional execution in ARM, the IA64 deferred
exceptions (good idea) and rotating register file (bad idea)). I
think these items can and are patented.

If you really want to play it safe you should implement a SPARC ISA.
That's an open standard.

Just don't call it SPARC. You have to say "Sparc Compatabile IEEE
whatever" until you pay sparc money. But that's no big deal.

Or do a reimplementation of picoblaze or microblaze or xr16. I believe
that Xilinx won't mind another Microblaze implementation that helps
selling there Chips. (Göran, can you comment on that?)

Microblaze is probably a nice one, since it should map well to large
families of FPGAs.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Bruce P.]

If you really want to play it safe you should implement a SPARC ISA.
That's an open standard.

Or do a reimplementation of picoblaze or microblaze or xr16. I believe
that Xilinx won't mind another Microblaze implementation that helps
selling there Chips. (Göran, can you comment on that?)

Thanks, the Picoblaze looks like a simple one to look at first.
Plenty of documentation and free tools as well.

BP

 

[Jake Janovetz]

news@sulimma.de (Kolja Sulimma) wrote in message news:<b890a7a.0311100755.72deef43@posting.google.com>...

Or do a reimplementation of picoblaze or microblaze or xr16. I believe
that Xilinx won't mind another Microblaze implementation that helps
selling there Chips. (Göran, can you comment on that?)

Once a version of microblaze becomes widely available on the Cyclone
series (or other Altera chip) and starts selling Altera chips, I'm
sure Xilinx would mind.

Jake

 

[Ralph Mason]

"Goran Bilski" <goran@xilinx.com> wrote in message
news:booi3e$bg72@cliff.xsj.xilinx.com...

Hi Symon,

But someone started from scratch, the design would probably not be so
biased against Xilinx.

Perhaps you should do one that is biased *towards* Xilinx parts ;-)

Ralph

 

[Goran Bilski]

Well, MicroBlaze is biased against Xilinx FPGA.
The whole ISA is done towards our devices.

That's why I mean it will probably not be efficient in other FPGA
vendors architecture.
But I think it would be very suited for an ASIC implementation.

Göran

Ralph Mason wrote:

"Goran Bilski" <goran@xilinx.com> wrote in message
news:booi3e$bg72@cliff.xsj.xilinx.com...


Hi Symon,





But someone started from scratch, the design would probably not be so
biased against Xilinx.




Perhaps you should do one that is biased *towards* Xilinx parts ;-)

Ralph

 

[Jim Granville]

Symon wrote:

Hi Goran,
So, playing devli's advocate, Xilinx wouldn't mind if the clean room
Microblaze was targeted at their competitors' devices? Or do you think that
no one would do this because Microblaze only efficiently fits the Xilinx
devices? Or the competitors have their own solutions for their parts?
I wonder....

Xilinx's protection does not come from attack on the clean room clone,
but rather from the protection of the Microblaze name, and tool flows.
So, anyone would be free to create an opcode compatible core,
if they wished, but not to use the brand, nor the Xilinx tool flows.

Older uC cores are easier to copy (any patents lapsed), and their tools
are widely available. Things like 80C51, 6502, Z8, and even 8085....
( someone must have done a 8048 core ?

-jg

 

[Austin Lesea]

Jake,

Microblaze(tm) requires specific Xilinx features, and can not be implemented efficiently in (by) other
architectures. The specific features required are covered by patents.

Austin

Jake Janovetz wrote:

news@sulimma.de (Kolja Sulimma) wrote in message news:<b890a7a.0311100755.72deef43@posting.google.com>...
Or do a reimplementation of picoblaze or microblaze or xr16. I believe
that Xilinx won't mind another Microblaze implementation that helps
selling there Chips. (Göran, can you comment on that?)

Once a version of microblaze becomes widely available on the Cyclone
series (or other Altera chip) and starts selling Altera chips, I'm
sure Xilinx would mind.

Jake

 

[Goran Bilski]

The name MicroBlaze is a trademark of MicroBlaze.
So a cleanroom can't be called MicroBlaze.
For the tools part, yes, the EDK tools is our tools which we don't give
away for free (they costs $495 and that's including all the IP)
The actual compiler tools is GNU tools and they are open-sourced.

Göran

Jim Granville wrote:

Symon wrote:


Hi Goran,
So, playing devli's advocate, Xilinx wouldn't mind if the clean room
Microblaze was targeted at their competitors' devices? Or do you think that
no one would do this because Microblaze only efficiently fits the Xilinx
devices? Or the competitors have their own solutions for their parts?
I wonder....



Xilinx's protection does not come from attack on the clean room clone,
but rather from the protection of the Microblaze name, and tool flows.
So, anyone would be free to create an opcode compatible core,
if they wished, but not to use the brand, nor the Xilinx tool flows.

Older uC cores are easier to copy (any patents lapsed), and their tools
are widely available. Things like 80C51, 6502, Z8, and even 8085....
( someone must have done a 8048 core ?

-jg

 

[Georg Acher]

In article <3FB0002A.909E765A@xilinx.com>,
Austin Lesea <Austin.Lesea@xilinx.com> writes:

|> Microblaze(tm) requires specific Xilinx features, and can not be implemented efficiently in (by) other
|> architectures. The specific features required are covered by patents.

I like the perversion of the word "patent".

"patere", lat.: "standing open".

SCNR(tm)
--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[John Williams]

Georg Acher wrote:

In article <3FB0002A.909E765A@xilinx.com>,
Austin Lesea <Austin.Lesea@xilinx.com> writes:

|> Microblaze(tm) requires specific Xilinx features, and can not be implemented efficiently in (by) other
|> architectures. The specific features required are covered by patents.

I like the perversion of the word "patent".

"patere", lat.: "standing open".

Which is precisely what they do - the details are published (ie open),
but there is protection for the inventor to profit exclusively from that
invention for a limited period of time.

A reasonable idea in principle - it's the rampant abuse that is the problem.

Regards,

John

 

[Nicholas C. Weaver]

In article <3FAFFAE7.2939@designtools.co.nz>,
Jim Granville <jim.granville@designtools.co.nz> wrote:

Xilinx's protection does not come from attack on the clean room clone,
but rather from the protection of the Microblaze name, and tool flows.
So, anyone would be free to create an opcode compatible core,
if they wished, but not to use the brand, nor the Xilinx tool flows.

Isn't the compiler flow gcc?
--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[John Williams]

Nicholas C. Weaver wrote:

In article <3FAFFAE7.2939@designtools.co.nz>,
Jim Granville <jim.granville@designtools.co.nz> wrote:


Xilinx's protection does not come from attack on the clean room clone,
but rather from the protection of the Microblaze name, and tool flows.
So, anyone would be free to create an opcode compatible core,
if they wished, but not to use the brand, nor the Xilinx tool flows.


Isn't the compiler flow gcc?

It is indeed. I host a copy of the tools on my website, and one may
build entire microblaze linux kernels without paying a cent to Xilinx.

Of course, you won't have a processor to run it on unless you do! Same
as any gcc-targeted processor really.

Regards,

John

 

[Bruce P.]

Once a version of microblaze becomes widely available on the Cyclone
series (or other Altera chip) and starts selling Altera chips, I'm
sure Xilinx would mind.

Did I mention that my new board design has a Cyclone on it? Hmmm, "The
Cyclo-Blaze"...has sort of a nice ring to it. ;&gt

I guess if it's smaller than the Altera Nios and a lot simpler, it
could be of some use. Anyway, it should be a good learning
experience. Thanks again.

BP

 

[H. Peter Anvin]

Followup to: <762349e4.0311101431.24595dcb@posting.google.com>
By author: bpride@monad.net (Bruce P.)
In newsgroup: comp.arch.fpga

Did I mention that my new board design has a Cyclone on it? Hmmm, "The
Cyclo-Blaze"...has sort of a nice ring to it. ;&gt

I guess if it's smaller than the Altera Nios and a lot simpler, it
could be of some use. Anyway, it should be a good learning
experience. Thanks again.

I think a small core that's vendor-independent would be nice. There
are enough many things in common between most current FPGA
architectures (4- or 5-input LUTs, carry chains, dualport block RAMs
in the 4kbit size range) that doing something sane that's
technology-independent shouldn't be that hard. It may not be as
sophisticated as MicroBlaze or NIOS, but wouldn't come with automatic
vendor lock-in.

I have actually been hacking a bit on a very simple 16-bit
architecture that I'm hoping will fit the bill. No promises if or
when I'll get around to finishing it, though... at this point I'd say
the RTL is about 30% done.

-hpa



--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

 

[Glen Herrmannsfeldt]

"H. Peter Anvin" <hpa@zytor.com> wrote in message
news:bord9r$sn5$1@cesium.transmeta.com...

(snip)

I think a small core that's vendor-independent would be nice. There
are enough many things in common between most current FPGA
architectures (4- or 5-input LUTs, carry chains, dualport block RAMs
in the 4kbit size range) that doing something sane that's
technology-independent shouldn't be that hard. It may not be as
sophisticated as MicroBlaze or NIOS, but wouldn't come with automatic
vendor lock-in.

I have actually been hacking a bit on a very simple 16-bit
architecture that I'm hoping will fit the bill. No promises if or
when I'll get around to finishing it, though... at this point I'd say
the RTL is about 30% done.

The PDP-11 has a nice simple 16 bit architecture, not including the optional
instructions. (FIS and EIS for example.)

-- glen