Home grown CPU core legal?

I've always been interested in designing my own 8-bit CPU core in an FPGA for educational purposes. After visiting

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

Reply to
Bruce P.
Loading thread data ...

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

Reply to
Kolja Sulimma
050408080207040802060803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit

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:

Reply to
Goran Bilski

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.

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.

Microblaze is probably a nice one, since it should map well to large families of FPGAs.

--
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Reply to
Nicholas C. Weaver

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.

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.

Reply to
Symon

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

Sym>Hi Goran,

Reply to
Goran Bilski

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

BP

Reply to
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. :)

Jake

Reply to
Jake Janovetz

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

Ralph

Reply to
Ralph Mason
090508090504070508040605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit

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

Reply to
Goran Bilski

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

Reply to
Jim Granville

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.

Aust> > Or do a reimplementation of picoblaze or microblaze or xr16. I believe

Reply to
Austin Lesea

Isn't the compiler flow gcc?

--
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Reply to
Nicholas C. Weaver
010507050305030102070901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit

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:

Reply to
Goran Bilski

|> 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
Reply to
Georg Acher

implemented efficiently in (by) other

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

Reply to
John Williams

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

Reply to
John Williams

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

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

Reply to
Bruce P.

Followup to: By author: snipped-for-privacy@monad.net (Bruce P.) In newsgroup: comp.arch.fpga

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

--
 at work,  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
Reply to
H. Peter Anvin

(snip)

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

-- glen

Reply to
Glen Herrmannsfeldt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.