CPU design

For implementing the higher level protocols for my Spartan 3E starter kit
TCP/IP stack implementation, I plan to use a CPU, because I think this
needs less gates than in pure VHDL. The instruction set could be limited,
because more instructions and less gates is good, and it doesn't need to be
fast, so I can design a very orthogonal CPU, which maybe needs even less
gates. The first draft:

http://www.frank-buss.de/vhdl/cpu.html

It is some kind of a 68000 clone, but much easier. What do you think of it?
Any ideas to reduce the instruction set even more, without the drawback to
need more instructions for a given task?

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Why not use PicoBlaze, which is freely available ?
Or MicroBlaze if you need more speed?
Peter Alfke, from home.


Frank Buss wrote:
> For implementing the higher level protocols for my Spartan 3E starter kit
> TCP/IP stack implementation, I plan to use a CPU, because I think this
> needs less gates than in pure VHDL. The instruction set could be limited,
> because more instructions and less gates is good, and it doesn't need to be
> fast, so I can design a very orthogonal CPU, which maybe needs even less
> gates. The first draft:
>
> http://www.frank-buss.de/vhdl/cpu.html
>
> It is some kind of a 68000 clone, but much easier. What do you think of it?
> Any ideas to reduce the instruction set even more, without the drawback to
> need more instructions for a given task?
>
> --
> Frank Buss, fb@frank-buss.de
> http://www.frank-buss.de, http://www.it4-systems.de

Peter Alfke schrieb:

> Why not use PicoBlaze, which is freely available ?
> Or MicroBlaze if you need more speed?
> Peter Alfke, from home.
>
>
> Frank Buss wrote:
> > For implementing the higher level protocols for my Spartan 3E starter kit
> > TCP/IP stack implementation, I plan to use a CPU, because I think this
> > needs less gates than in pure VHDL. The instruction set could be limited,
> > because more instructions and less gates is good, and it doesn't need to be
> > fast, so I can design a very orthogonal CPU, which maybe needs even less
> > gates. The first draft:
> >
> > http://www.frank-buss.de/vhdl/cpu.html
> >
> > It is some kind of a 68000 clone, but much easier. What do you think of it?
> > Any ideas to reduce the instruction set even more, without the drawback to
> > need more instructions for a given task?
> >
> > --
> > Frank Buss, fb@frank-buss.de
> > http://www.frank-buss.de, http://www.it4-systems.de

To Peter,

I can answer

1) PicoBlaze is too small
2) MicroBlaze is not free

the OP is really going to try to make a full SoC with DDR memory
controller and ethernet! as much as I have understood his reasons.

sure it would be WAY CHEAPER to just use MicroBlaze !!! cheaper means
in terms of money. The time and effort to make anything comparable to
what you can achive with EDK and a few mouseclicks, defenetly costs
more than 495USD unless your personal time doesnt count at all.

To Frank,

I was wondering (what you are up)

well doing some 16 bit doesnt make much sense, a small 32 bit RISC isnt
much larger. you could also use OpenFire and add wishbone interfaces,
makes more sense then trying it all from scratch. unless you just want
todo everything by yourself (and that is your goal, not achiving the
best with least effort)

BTW - 16 bit, I was looking at ColdFire, and well there is no coldfire
FPGA clone yet, but that may make sense (kind 68000, but more RISClike,
16 bit instruction bus)


Antti

Peter Alfke schrieb:

> Why not use PicoBlaze, which is freely available ?
> Or MicroBlaze if you need more speed?
> Peter Alfke, from home.
>
>
> Frank Buss wrote:
> > For implementing the higher level protocols for my Spartan 3E starter kit
> > TCP/IP stack implementation, I plan to use a CPU, because I think this
> > needs less gates than in pure VHDL. The instruction set could be limited,
> > because more instructions and less gates is good, and it doesn't need to be
> > fast, so I can design a very orthogonal CPU, which maybe needs even less
> > gates. The first draft:
> >
> > http://www.frank-buss.de/vhdl/cpu.html
> >
> > It is some kind of a 68000 clone, but much easier. What do you think of it?
> > Any ideas to reduce the instruction set even more, without the drawback to
> > need more instructions for a given task?
> >
> > --
> > Frank Buss, fb@frank-buss.de
> > http://www.frank-buss.de, http://www.it4-systems.de

To Peter,

I can answer

1) PicoBlaze is too small
2) MicroBlaze is not free

the OP is really going to try to make a full SoC with DDR memory
controller and ethernet! as much as I have understood his reasons.

sure it would be WAY CHEAPER to just use MicroBlaze !!! cheaper means
in terms of money. The time and effort to make anything comparable to
what you can achive with EDK and a few mouseclicks, defenetly costs
more than 495USD unless your personal time doesnt count at all.

To Frank,

I was wondering (what you are up)

well doing some 16 bit doesnt make much sense, a small 32 bit RISC isnt
much larger. you could also use OpenFire and add wishbone interfaces,
makes more sense then trying it all from scratch. unless you just want
todo everything by yourself (and that is your goal, not achiving the
best with least effort)

BTW - 16 bit, I was looking at ColdFire, and well there is no coldfire
FPGA clone yet, but that may make sense (kind 68000, but more RISClike,
16 bit instruction bus)


Antti

Peter Alfke wrote:

> Why not use PicoBlaze, which is freely available ?
> Or MicroBlaze if you need more speed?

PicoBlaze looks a bit like my idea:

http://www.xilinx.com/bvdocs/ipcenter/data_sheet/picoblaze_productbrief.pdf

But it has more instructions and it is not as much orthogonal as my CPU, so
I think I can synthesize my CPU with less gates. But using memory instead
of registers means that it is slower than PicoBlaze, but this is no problem
for me. But maybe the main reason is, that it is fun to design CPUs :-)

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Frank Buss wrote:
> For implementing the higher level protocols for my Spartan 3E starter kit
> TCP/IP stack implementation, I plan to use a CPU, because I think this
> needs less gates than in pure VHDL. The instruction set could be limited,
> because more instructions and less gates is good, and it doesn't need to be
> fast, so I can design a very orthogonal CPU, which maybe needs even less
> gates. The first draft:
>
> http://www.frank-buss.de/vhdl/cpu.html
>
> It is some kind of a 68000 clone, but much easier. What do you think of it?
> Any ideas to reduce the instruction set even more, without the drawback to
> need more instructions for a given task?
>
> --
> Frank Buss, fb@frank-buss.de
> http://www.frank-buss.de, http://www.it4-systems.de

There are a number of RISC cores at opencores.org. The full featured
(complete with GNU toolchain) is OpenRisc1000, but that may be way more
than you need.

Do you want a processor you can simply instantiate, or are you willing
to tweak so you get the features you want? If so, you could take one of
the less ambitious cores and adjust the instruction set to optimise it
for your application.

Cheers

PeteS

Antti wrote:

> 1) PicoBlaze is too small

For me it looks like it is too large :-)

> the OP is really going to try to make a full SoC with DDR memory
> controller and ethernet! as much as I have understood his reasons.

Yes, and mainly for learning VHDL, so using finished products doesn't help
me and is not as much fun as doing it all by myself.

> well doing some 16 bit doesnt make much sense, a small 32 bit RISC isnt
> much larger.

The first use case for this CPU will be executing programs from block RAM,
for accessing all the hardware of the Spartan 3E starter kit. For this 32
bit is not needed, but I'll use generics for the bit width, because when
using more memory than 64 kB or for more complicated tasks, 32 bit may be
more useful.

> you could also use OpenFire 

Do you have a link? Searching for OpenFire at Google returns only ads for
fireplaces :-)

> BTW - 16 bit, I was looking at ColdFire, and well there is no coldfire
> FPGA clone yet, but that may make sense (kind 68000, but more RISClike,
> 16 bit instruction bus)

ColdFire looks interesting, but even more complicated than PicoBlaze, with
all the old 68000 commands, like traps.

Looks like all these CPUs are using registers. I know it is faster to do
calculations with registers instead in memory and opcodes may be a bit
smaller, when using registers as source or destination, but are there any
other drawbacks using no registers? I really like my idea using only
memory.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Frank Buss wrote:
> Peter Alfke wrote:
> 
> 
>>Why not use PicoBlaze, which is freely available ?
>>Or MicroBlaze if you need more speed?
> 
> 
> PicoBlaze looks a bit like my idea:
> 
> http://www.xilinx.com/bvdocs/ipcenter/data_sheet/picoblaze_productbrief.pdf
> 
> But it has more instructions and it is not as much orthogonal as my CPU, so
> I think I can synthesize my CPU with less gates. But using memory instead
> of registers means that it is slower than PicoBlaze, but this is no problem
> for me. But maybe the main reason is, that it is fun to design CPUs :-)

Also look at the Lattice Mico8, and PacoBlaze.
The CPU is the easy part, finding a compiler and debug software will be 
harder.
You also need to match the memory interface to the core, once you go
out of block ram, these CPUs get less elegent.

One idea that appeals to me, is to optimise a FPGA_CPU to operate from
the Fast serial flash that are very cheap and small, with negligable pin 
cost.
That probably means 16 bit opcodes ( down from the 18 allowed by Block 
Ram), and 32 bit registers, with plenty of size-extended opcodes, and 
skip opcodes. Next would be a way to load and lock a BRAM or 2 with 
interrupt and speed critical codes.

-jg

Frank Buss <fb@frank-buss.de> wrote:

>For implementing the higher level protocols for my Spartan 3E starter kit
>TCP/IP stack implementation, I plan to use a CPU, because I think this
>needs less gates than in pure VHDL. The instruction set could be limited,
>because more instructions and less gates is good, and it doesn't need to be
>fast, so I can design a very orthogonal CPU, which maybe needs even less
>gates. The first draft:
>
>http://www.frank-buss.de/vhdl/cpu.html
>
>It is some kind of a 68000 clone, but much easier. What do you think of it?
>Any ideas to reduce the instruction set even more, without the drawback to
>need more instructions for a given task?

A few years ago I made a programmable DMA controller on a system that
had no interrupt capability (too many sources) so all I/O needed to be
polled and packed into larger chunks of data.
It has a few instructions like read, mask and, mask or, jump
conditionally, write to the host. It is smart enough to be able to
deal with an E1 chip. As I write this, this controller is at work in
thousands of cards...

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

PeteS wrote:
> Frank Buss wrote:
> > For implementing the higher level protocols for my Spartan 3E starter kit
> > TCP/IP stack implementation, I plan to use a CPU, because I think this
> > needs less gates than in pure VHDL. The instruction set could be limited,
> > because more instructions and less gates is good, and it doesn't need to be
> > fast, so I can design a very orthogonal CPU, which maybe needs even less
> > gates. The first draft:
> >
> > http://www.frank-buss.de/vhdl/cpu.html
> >
> > It is some kind of a 68000 clone, but much easier. What do you think of it?
> > Any ideas to reduce the instruction set even more, without the drawback to
> > need more instructions for a given task?
> >
> > --
> > Frank Buss, fb@frank-buss.de
> > http://www.frank-buss.de, http://www.it4-systems.de
> 
http://indi.joox.net for ISA