Home grown CPU core legal?

Jim Granville wrote:
> 
> H. Peter Anvin wrote:
> >
> > I have no way to know how this is turning out.  My current goal is to
> > make sure it implements in < 1000 LEs on Cyclone, without using
> > blockRAM for the register file.
> 
>  Isn't some form of BlockRAM a defacto standard on all
> 'consider for new design' FPGAs - so not using that would
> restrict your options ?
> 
>  -jg

So are hardware multipliers these days.  I believe all the latest chips
have them as well as multi-standard IOs.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

I am convinced that a generic version would inevitably be inferior in
performance and/or price, compared to the dedicated one. I know that Ken
and G�ran used many Xilinx-specific features when they designed
PicoBlaze and MicroBlaze. And I assume that the Altera guys were
operating in a comparable way when they designed Nios.
The generic ones will be the "worst of both worlds", unless you really
believe in clairvoyant synthesis.

Peter Alfke, Xilinx

> I am convinced that a generic version would inevitably be inferior in
> performance and/or price, compared to the dedicated one. 

But, there's nothing like rolling your own for fun/educational
purposes and then having something useful at the end of it all.  I
think it would also be easier to add new features and enhancements to
your own design since the code was developed in your own way of
thinking and coding style.  In the end, maybe it will just be "yet
another RISC core" on opencores.org, but at least it's yours and
you'll have a good understanding of it's capabilities...even if all it
can do is blink an LED!

BP

Followup to:  <3FB15BB3.5B87@designtools.co.nz>
By author:    jim.granville@designtools.co.nz
In newsgroup: comp.arch.fpga
>
> H. Peter Anvin wrote:
> > 
> > I have no way to know how this is turning out.  My current goal is to
> > make sure it implements in < 1000 LEs on Cyclone, without using
> > blockRAM for the register file.
> 
>  Isn't some form of BlockRAM a defacto standard on all 
> 'consider for new design' FPGAs - so not using that would 
> restrict your options ?
> 

Some form thereof, yes, but I tend to run out of blockram a lot faster
than running out of LUTs.  Note that it's not that I'm saying you
couldn't use it, I'm saying I want to be at < 1000 LE without using
blockram.  About 300-400 of that would be replacable with a blockram.

	-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

Followup to:  <3FB16CEB.C46327DE@xilinx.com>
By author:    Peter Alfke <peter@xilinx.com>
In newsgroup: comp.arch.fpga
>
> I am convinced that a generic version would inevitably be inferior in
> performance and/or price, compared to the dedicated one. I know that Ken
> and G&#4294967295;ran used many Xilinx-specific features when they designed
> PicoBlaze and MicroBlaze. And I assume that the Altera guys were
> operating in a comparable way when they designed Nios.
> The generic ones will be the "worst of both worlds", unless you really
> believe in clairvoyant synthesis.
> 

Of course.  But it would have the advantage that it could run on
either.

	-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

Peter Alfke wrote:
> 
> I am convinced that a generic version would inevitably be inferior in
> performance and/or price, compared to the dedicated one. I know that Ken
> and G�ran used many Xilinx-specific features when they designed
> PicoBlaze and MicroBlaze. And I assume that the Altera guys were
> operating in a comparable way when they designed Nios.
> The generic ones will be the "worst of both worlds", unless you really
> believe in clairvoyant synthesis.
> 
> Peter Alfke, Xilinx

"Clairvoyant Synthesis", now that sounds like a good product!  Is there
a startup somewhere working on that? 

I can see product announcements touting the new FPGA CS that eliminates
the need for product planners, designers and even testing as it would
already know that the design was ready for production!  No specs to
write, no coding to compile and even simulation could be skipped.  Just
think of the design you want and out pops a bit file.  Boy, what will
they think of next?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

"Bruce P." wrote:
> 
> > I am convinced that a generic version would inevitably be inferior in
> > performance and/or price, compared to the dedicated one.
> 
> But, there's nothing like rolling your own for fun/educational
> purposes and then having something useful at the end of it all.  I
> think it would also be easier to add new features and enhancements to
> your own design since the code was developed in your own way of
> thinking and coding style.  In the end, maybe it will just be "yet
> another RISC core" on opencores.org, but at least it's yours and
> you'll have a good understanding of it's capabilities...even if all it
> can do is blink an LED!
> 
> BP

When I was in school we worked on a paper design of a microcoded
processor as a teaching tool.  We had homework on it and had to design
new features on our exams.  I even had a question about it on my Masters
comprehensive exam.  I approached my professor about designing a
simulation of it to run on the Univac mainframe for the undergrad
students to learn from.  But I guess I was ahead of my time as he did
not see the value in that.  Or maybe he had the foresight to see the
complications it might create :) 

I guess this is a pretty common thing at Universities now.  All they
have to do is get you a FPGA design package with a simulator.  


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Hello Jim,

For the most part, I agree with your legal analysis regarding cloning
cores.  The primary issues have to do with whether or not an
architecture is protected by patent and if not, how you market or use
the resulting clone so as not to infringe existing copyrights,
trademarks, trade dress or confidentiality/license agreements.

But in my view, this is not the main issue with cloning an existing
architecture.  The main issue has to do with how you are going to
debug it once you get it into an FPGA wherein it is completely
embedded with no address or data lines coming out.

Accordingly, I'd like to take this opportunity to simply state that
I've posted developmental versions of both my 8051 and 6805
microcontroller cores for free downloading at www.quickcores.com.  The
8051 is in original Verilog RTL format and includes on-chip JTAG
real-time monitoring and debug logic, including 144-channel trace
buffer.

I've successfully synthesized them using Synplify and Quartus II web
edition.

If anyone would like to start a thread about how the JTAG real-time
monitor works, I'd be happy to engage.

Regards,

Jerry D. Harthcock
QuickCores
p.s., I also have the 9-bit RISC which I'd be happy to post if anyone
is interested.

Jim Granville <jim.granville@designtools.co.nz> wrote in message news:<3FAFFAE7.2939@designtools.co.nz>...
> 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

In article <borkg7$p06$1@cesium.transmeta.com>,
H. Peter Anvin  <hpa@zytor.com> wrote:
>Some vendors have 9/18-bit blockRAMs, some don't.  I'm trying to be as
>generic as possible.  It also makes it easier to port tools like
>gas/binutils/gcc.

Both Brand A and Brand X have midsize (8-16 bit wide + parity, with
>128 addresses in that range) memories, and any other viable FPGA will
as well.

Thus it is safe to have parameterized cache and register file with
instantiates the correct size memories, as part of your design, and
still remain vendor neutral.  You WANT to use these devices for both
register file and memory.

The thing that Brand A is missing are the SRL16/LUT as RAM features
which give very small memories (16-64x1b), while Brand X all the
BlockRAMs (midsized memories) are the same size while Brand A's
memories come in different sizes.


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

In article <3FB16CEB.C46327DE@xilinx.com>,
Peter Alfke  <peter@xilinx.com> wrote:
>I am convinced that a generic version would inevitably be inferior in
>performance and/or price, compared to the dedicated one. I know that Ken
>and G&#4294967295;ran used many Xilinx-specific features when they designed
>PicoBlaze and MicroBlaze. And I assume that the Altera guys were
>operating in a comparable way when they designed Nios.
>The generic ones will be the "worst of both worlds", unless you really
>believe in clairvoyant synthesis.

I think generic will be inferior, but not THAT inferior, given the
register files and caches can and should be done in the "everyone has"
BlockRAMs.

But in order to make it generic, these structures will probably need
target-specific parameters and options (dual ported or not, size
range) which are instantiated.

Also, the other big disadvantage in the generic version is going to be
a lack of placement.  Placement is good for 10-30% performanec
increases.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu