CPU design

jacko schrieb:

> 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

ALL project folder are EMPTY !! :(

Antti

Frank Buss wrote:

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

Look at a uC like the Zilog Z8 - that has registers, but also a register 
frame pointer. So you use 4 opcode bits, but can shift that window, a
across all memory. The Intel 196 used a 256 byte register file

Registers are used to keep the opcodes smaller, but you are right that
it is a simple trade off. PICs use only RAM and accumulator.

A drawback of registers is that the step-up from reg to memory can give 
quite a code hit, and with FPGA BRAM, there is no speed penalty in a 
memory block much larger than most uC register fields.

Some processors allowed a split register frame, so you could (eg) 
half-shift the register map, giving 8 scratch registers, and 8 register 
parameters, in a procedure call.
To me a very good idea, but seems to not be widely used - would map very 
well onto FPGA BRAM.

-jg

In article <1156100604.972937.26240@m73g2000cwd.googlegroups.com>,
Antti <Antti.Lukats@xilant.com> wrote:

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

Ethernet is not included in the MicroBlaze price, but is $1500 extra. 
(Still a lot cheaper than doing it yourself if you place any reasonable
value on your time, and if you don't want to learn from it.)

OpenCores has several CPUs that include full gcc support.

I am pushing around pieces of Opencores to try to get a CPU + Ethernet
+ DDR + Application-specific system together on Wishbone.  I am being
stymied by just learning VHDL and knowing no Verilog at all, and not
being able to understand the various error messages the ISE spits out.
It would be nice if there were an assembled system that I could take
apart and modify.

(I found a more restricted system under OpenCores as rs232_syscon that
includes a PIC microcontroller and a serial-port-device that lets you
prod at the Wishbone bus, which might help.)

-- 
David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)

Antti wrote:
> jacko schrieb:
>
> > http://indi.joox.net for ISA
>
> ALL project folder are EMPTY !! :(
>
> Antti

i'm only one person, and so i am doing the documentation first

cheers.

feel free to contribute.

Jim Granville wrote:

> A drawback of registers is that the step-up from reg to memory can give 
> quite a code hit, and with FPGA BRAM, there is no speed penalty in a 
> memory block much larger than most uC register fields.

I wonder if there is some more scientific study about this. When I'm trying
to write a typical piece of code, it looks like registers are really
better:

; swap 6 byte source and destination MACs
	.base = 0x1000
p1:	.dw 0
p2:	.dw 0
tmp:	.db 0
	move #5, p1
	move #11, p2
loop:	move.b (p1), tmp
	move.b (p2), (p1)
	move.b tmp, (p2)
	sub.b p2, #1
	sub.b p1, #1
	bcc.b loop

40 bytes with my instruction set.

The same with something like a 68000 instruction set:

	move #5, a0
loop:	move.b $0(a0), d0
	xchg.b $6(a0), d0
	move.b d0, $0(a0)-  ; register indirect with displacement and post-dec
	bcc.b loop

12 bytes, if I need 2 bytes per instruction for the larger range of
addressing modes with registers. How much logic gates do I need for
supporting registers? Maybe not too much, if I can design it without too
much special cases.

I don't need it, but for a really fast CPU something like MIPS should work:

http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html

Every instruction, including arguments, is 32 bit. When reading it from 32
bit block RAM, this should be really fast. How much memory needs a program?

	xor $1, $1, $1
	addi $1, $0, #6
loop:	lb $3, ($1)
	sb $3, ($2)
	addi $1, $1, #1
	addi $2, $2, #1
	xori $1, $4, #6
	bne loop

32 bytes (but maybe shorter, I don't know MIPS assembler very good).

And something like the good old 6502:

	ldx# 6
loop:	lda 0, x
	tay
	lda 6, x
	sta 0, x
	tya
	sta 6, x
	decx
	bcc loop

13 bytes.

Maybe a CPU like MIPS, with fixed 32 bit instructions, but as easy to write
assembler for it like for the 68000 would be a good idea?

Forth looks interesting, too: http://www.ultratechnology.com/f21cpu.html

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

Before you comparing ISA for size, you need to look into the actual FPGA 
area needed for different ISA.
A full 68000 would most likely fill up most of your Spartan3E device and 
that is without the ethernet MAC.
Also the Ethernet MAC is usually much larger size than the CPU.
On the opencores IP, just add the size of the CPU and Ethernet MAC 
before you do any decision.

Unless you want to spend hours and hours hand-assemble the TCP/IP stack 
code, you need to find a CPU which has a full C compiler.

If your ethernet speed doesn't need to be at maximum speed, I would pick 
the ethernet lite from Xilinx since the size is much smaller than most 
available cores. If you need maximum ethernet performance then you need 
the full ethernet MAC which is much larger than the lite version.
You will need a TCP/IP stack and lwip is most likely the best choice.
For the CPU, a MicroBlaze will most likely be the smallest choice for you.

The decision also depends on how you value your time and how money you 
want to spend on this.
If the interesting part is to create this solution without any time 
limits than you should create most from scratch.
If the interesting part is to use the solution than I would spend money 
to speed up the development.

G�ran Bilski

Frank Buss schrieb:

> 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 :-)

http://www.ccm.ece.vt.edu/~amarschn/openfire/tools.html

search openfire in google groups comp.arch.fpga
and you get it a first hit

Antti

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

If you are interested in learning more than producing an actual
product, I suggest designing your own CPU as well. I have been working
on an 8-bit RISC processor, and it has definitely been eye-opening.

I posted recently about my v8 uRISC/Arclite clone, which is currently
not working while I'm implementing a deeper pipeline. I've learned a
great deal about microprocessor design and optimization as a result. I
now have a design capable of running at > 110MHz (by itself). By
understanding what the processor is actually doing in each step
(state), you can often find ways to squeeze extra functionality out of
each clock cycle. For example, since my memory is pipelined, I was able
to add a 16-bit auto-increment to the indexed load/store instructions
at no cost (cycle-wise). I was also able to increment a DBNZ (decrement
and branch if not zero) instruction at no cost. This saves 5 clock
cycles per loop for memory copies. Doesn't sound like much, but
remember that is per iteration. I can do a standard memory copy in 3
instructions - 5, if the loop count is greater than 256.

I've identified several other areas of the design that could be
optimized as well. Best of all, it's been fun - kind of like being in
college all over again, without the final.

-Seth

Maybe compiler has to be taken into account as well. Although very nice
hand-made code is possible, most of code is generated by compiler. For
a new instruction set, it's possible to modify gcc for that but I am
not sure the efficiency.

/Wayne

Frank Buss wrote:
> Jim Granville wrote:
>
> > A drawback of registers is that the step-up from reg to memory can give
> > quite a code hit, and with FPGA BRAM, there is no speed penalty in a
> > memory block much larger than most uC register fields.
>
> I wonder if there is some more scientific study about this. When I'm trying
> to write a typical piece of code, it looks like registers are really
> better:
>
> ; swap 6 byte source and destination MACs
> 	.base = 0x1000
> p1:	.dw 0
> p2:	.dw 0
> tmp:	.db 0
> 	move #5, p1
> 	move #11, p2
> loop:	move.b (p1), tmp
> 	move.b (p2), (p1)
> 	move.b tmp, (p2)
> 	sub.b p2, #1
> 	sub.b p1, #1
> 	bcc.b loop
>
> 40 bytes with my instruction set.
>
> The same with something like a 68000 instruction set:
>
> 	move #5, a0
> loop:	move.b $0(a0), d0
> 	xchg.b $6(a0), d0
> 	move.b d0, $0(a0)-  ; register indirect with displacement and post-dec
> 	bcc.b loop
>
> 12 bytes, if I need 2 bytes per instruction for the larger range of
> addressing modes with registers. How much logic gates do I need for
> supporting registers? Maybe not too much, if I can design it without too
> much special cases.
>
> I don't need it, but for a really fast CPU something like MIPS should work:
>
> http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html
>
> Every instruction, including arguments, is 32 bit. When reading it from 32
> bit block RAM, this should be really fast. How much memory needs a program?
>
> 	xor $1, $1, $1
> 	addi $1, $0, #6
> loop:	lb $3, ($1)
> 	sb $3, ($2)
> 	addi $1, $1, #1
> 	addi $2, $2, #1
> 	xori $1, $4, #6
> 	bne loop
>
> 32 bytes (but maybe shorter, I don't know MIPS assembler very good).
>
> And something like the good old 6502:
>
> 	ldx# 6
> loop:	lda 0, x
> 	tay
> 	lda 6, x
> 	sta 0, x
> 	tya
> 	sta 6, x
> 	decx
> 	bcc loop
>
> 13 bytes.
>
> Maybe a CPU like MIPS, with fixed 32 bit instructions, but as easy to write
> assembler for it like for the 68000 would be a good idea?
>
> Forth looks interesting, too: http://www.ultratechnology.com/f21cpu.html
>
> --
> Frank Buss, fb@frank-buss.de
> http://www.frank-buss.de, http://www.it4-systems.de