CPU design

PeteS wrote:

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

Adjusting the instruction set to the problem domain is a good idea. I'll
try to write the functions, first, maybe using domain specific instructions
(like a block copy command), and then I'll implement the core for it.

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

Antti wrote:
> 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
>

> 1) PicoBlaze is too small
> 2) MicroBlaze is not free
Then perhaps there should be a "NanoBlaze"? ;)
(micro, nano, pico)

> 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

-Dave Pollum

Dave Pollum schrieb:

> Antti wrote:
> > Peter Alfke schrieb:
> >
> > > Why not use PicoBlaze, which is freely available ?
> > > Or MicroBlaze if you need more speed?
> > > Peter Alfke, from home.
> > >
[]
> Then perhaps there should be a "NanoBlaze"? ;)
> (micro, nano, pico)

> -Dave Pollum

Dave,

NanoBlaze is already (R) registered trademark of Xilinx Inc.

Antti

Antti wrote:
> Dave Pollum schrieb:
> 
>> Antti wrote:
>>> Peter Alfke schrieb:
>>>
>>>> Why not use PicoBlaze, which is freely available ?
>>>> Or MicroBlaze if you need more speed?
>>>> Peter Alfke, from home.
>>>>
> []
>> Then perhaps there should be a "NanoBlaze"? ;)
>> (micro, nano, pico)
> 
>> -Dave Pollum
> 
> Dave,
> 
> NanoBlaze is already (R) registered trademark of Xilinx Inc.
> 
> Antti
> 

Damn, I'm working on a 16 bits RISC cpu optimized for S3/V4
and I was thinking of nanoblaze ... gotta find some other name
now ...



Sylvain

Sylvain Munaut wrote:
> Antti wrote:
> 
>>Dave Pollum schrieb:
>>
>>
>>>Antti wrote:
>>>
>>>>Peter Alfke schrieb:
>>>>
>>>>
>>>>>Why not use PicoBlaze, which is freely available ?
>>>>>Or MicroBlaze if you need more speed?
>>>>>Peter Alfke, from home.
>>>>>
>>
>>[]
>>
>>>Then perhaps there should be a "NanoBlaze"? ;)
>>>(micro, nano, pico)
>>
>>>-Dave Pollum
>>
>>Dave,
>>
>>NanoBlaze is already (R) registered trademark of Xilinx Inc.
>>
>>Antti
>>
> 
> 
> Damn, I'm working on a 16 bits RISC cpu optimized for S3/V4
> and I was thinking of nanoblaze ... gotta find some other name
> now ...

If it is going to be open source, how about NanoFire ?

-jg

G�ran Bilski wrote:

> If the interesting part is to create this solution without any time 
> limits than you should create most from scratch.

Yes, this is what I'm planning.

I have another idea for a CPU, very RISC like. The bits of an instructions
are something like micro-instructions:

There are two internal 16 bit registers, r1 and r2, on which the core can
perform operations and 6 "normal" 16 bit registers. The first 2 bits of an
instructions defines the meaning of the rest:

2 bits: operation:
  00 load internal register 1
  01 load internal register 2
  10 execute operation
  11 store internal register 1

I think it is a good idea to use 8 bits for one instruction instead of
using non-byte-aligned instructions, so we have 6 bits for the operation.
Some useful operations:

6 bits: execute operation:
  r1 = r1 and r2
  r1 = r1 or r2
  r1 = r1 xor r2
  cmp(r1, r2)
  r1 = r1 + r2
  r1 = r1 - r2
  pc = r1
  pc = r1, if c=0
  pc = r1, if c=1
  pc = r1, if z=0
  pc = r1, if z=1

For the load and store micro instructions, we have 6 bits for encoding the
place on which the load and store acts:

6 bits place:
  1 bit: transfer width (0=8, 1=16 bits)
  2 bits source/destination:
    00: register:
      3 bits: register index
    01: immediate:
      1 bit: width of immediate value (0=8, 1=16 bits)
        next 1 or 2 bytes: immediate number (8/16 bits)
    10: memory address in register
      3 bits: register index
    11: address
      1 bit: width of address (0=8, 1=16 bits)
        next 1 or 2 bytes: address (8/16 bits)

The transfer width and the value need not to be the same. E.g. 1010xx
means, that the next byte is loaded into the internal register and the
upper 8 bits are set to 0.

But for this reduced instruction set a compiler would be a good idea. Or
different layers of assembler. I'll try to translate my first CPU design,
which needed 40 bytes:

; 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

With my new instruction set it could be written like this (the normal
registers 0 and 1 are constant 0 and 1) :

	load r1 immediate with 5
	store r1 to register 2
	load r1 immediate with 11
	store r1 to register 3
loop:	load r1 from memory address in register 2
	load r2 from memory address in register 3
	store r1 to memory address in register 3
	store r2 to memory address in register 2
	load r1 from register 3
	load r2 from register 1
	operation r1 = r1 - r2
	store r1 in register 3
	load r1 in register 2
	operation r1 = r1 - r2
	store r1 in register 2
	operation pc = loop if c=0

This is 20 bytes long. As you can see, there are micro optimizations
possible, like for the last two register decrements, where the subtrahend
needs to be loaded only once.

I think this instruction set could be implemented with very few gates,
compared to other instruction sets, and the memory usage is low, too.
Another advantage: 64 different instructions are possible and orthogonal
higher levels are easy to implement with it, because the load and store
operations work on all possible places. Speed would be not the fastest, but
this is no problem for my application.

The only problem is that you need a C compiler or something like this,
because writing assembler with this reduced instruction set looks like it
will be no fun.

Instead of 16 bits, 32 bits and more is easy to implement with generic
parameters for this core.

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

Jim Granville wrote:

> Sylvain Munaut wrote:
> > Antti wrote:
> >
> >>Dave Pollum schrieb:
> >>
> >>
> >>>Antti wrote:
> >>>
> >>>>Peter Alfke schrieb:
> >>>>
> >>>>
> >>>>>Why not use PicoBlaze, which is freely available ?
> >>>>>Or MicroBlaze if you need more speed?
> >>>>>Peter Alfke, from home.
> >>>>>
> >>
> >>[]
> >>
> >>>Then perhaps there should be a "NanoBlaze"? ;)
> >>>(micro, nano, pico)
> >>
> >>>-Dave Pollum
> >>
> >>Dave,
> >>
> >>NanoBlaze is already (R) registered trademark of Xilinx Inc.
> >>
> >>Antti
> >>
> >
> >
> > Damn, I'm working on a 16 bits RISC cpu optimized for S3/V4
> > and I was thinking of nanoblaze ... gotta find some other name
> > now ...
>
> If it is going to be open source, how about NanoFire ?
>
> -jg

sounds good, i do wonder if micron is trademark too, any other good
names??

Minon is a possibility, but it may end up being called indi.

maybe a thread should just list un occupied namespace :-)

cheers

Frank Buss wrote:
<snip>
> The only problem is that you need a C compiler or something like this,
> because writing assembler with this reduced instruction set looks like it
> will be no fun.

  Since this is a very specifica application, do you have a handle on 
the code size yet ?

  Another angle to this, would be to choose the smallest CPU for which a 
C compiler exists.

Here, Freescale's new RS08 could be a reasonable candidate ?

  Or chose another more complex core and then scan the compiled output,
to check the Opcode usages, and subset that.

-jg

Jim Granville wrote:

> Frank Buss wrote:
> <snip>
> > The only problem is that you need a C compiler or something like this,
> > because writing assembler with this reduced instruction set looks like it
> > will be no fun.
>

just got quartus II after 1/2 hr seems ok, after setting top level!!

i wonder if the avalon sopc includes usb?

not sure if c compilier for it.

well at least i have a vhdl compilier now which looks good.

must start on the micron design soon.

Frank Buss wrote:
> G�ran Bilski wrote:
> 
> 
>>If the interesting part is to create this solution without any time 
>>limits than you should create most from scratch.
> 
> 
> Yes, this is what I'm planning.
> 
> I have another idea for a CPU, very RISC like. The bits of an instructions
> are something like micro-instructions:
> 
> There are two internal 16 bit registers, r1 and r2, on which the core can
> perform operations and 6 "normal" 16 bit registers. The first 2 bits of an
> instructions defines the meaning of the rest:
> 
> 2 bits: operation:
>   00 load internal register 1
>   01 load internal register 2
>   10 execute operation
>   11 store internal register 1
> 
> I think it is a good idea to use 8 bits for one instruction instead of
> using non-byte-aligned instructions, so we have 6 bits for the operation.
> Some useful operations:
> 
> 6 bits: execute operation:
>   r1 = r1 and r2
>   r1 = r1 or r2
>   r1 = r1 xor r2
>   cmp(r1, r2)
>   r1 = r1 + r2
>   r1 = r1 - r2
>   pc = r1
>   pc = r1, if c=0
>   pc = r1, if c=1
>   pc = r1, if z=0
>   pc = r1, if z=1
> 
> For the load and store micro instructions, we have 6 bits for encoding the
> place on which the load and store acts:
> 
> 6 bits place:
>   1 bit: transfer width (0=8, 1=16 bits)
>   2 bits source/destination:
>     00: register:
>       3 bits: register index
>     01: immediate:
>       1 bit: width of immediate value (0=8, 1=16 bits)
>         next 1 or 2 bytes: immediate number (8/16 bits)
>     10: memory address in register
>       3 bits: register index
>     11: address
>       1 bit: width of address (0=8, 1=16 bits)
>         next 1 or 2 bytes: address (8/16 bits)
> 
> The transfer width and the value need not to be the same. E.g. 1010xx
> means, that the next byte is loaded into the internal register and the
> upper 8 bits are set to 0.
> 
> But for this reduced instruction set a compiler would be a good idea. Or
> different layers of assembler. I'll try to translate my first CPU design,
> which needed 40 bytes:
> 
> ; 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
> 
> With my new instruction set it could be written like this (the normal
> registers 0 and 1 are constant 0 and 1) :
> 
> 	load r1 immediate with 5
> 	store r1 to register 2
> 	load r1 immediate with 11
> 	store r1 to register 3
> loop:	load r1 from memory address in register 2
> 	load r2 from memory address in register 3
> 	store r1 to memory address in register 3
> 	store r2 to memory address in register 2
> 	load r1 from register 3
> 	load r2 from register 1
> 	operation r1 = r1 - r2
> 	store r1 in register 3
> 	load r1 in register 2
> 	operation r1 = r1 - r2
> 	store r1 in register 2
> 	operation pc = loop if c=0
> 
> This is 20 bytes long. As you can see, there are micro optimizations
> possible, like for the last two register decrements, where the subtrahend
> needs to be loaded only once.
> 
> I think this instruction set could be implemented with very few gates,
> compared to other instruction sets, and the memory usage is low, too.
> Another advantage: 64 different instructions are possible and orthogonal
> higher levels are easy to implement with it, because the load and store
> operations work on all possible places. Speed would be not the fastest, but
> this is no problem for my application.
> 
> The only problem is that you need a C compiler or something like this,
> because writing assembler with this reduced instruction set looks like it
> will be no fun.
> 
> Instead of 16 bits, 32 bits and more is easy to implement with generic
> parameters for this core.
> 

Things to keep in mind is to handle larger arithmetic than 16 bits.
That will usually introduce some kind of carry bits (stored where?).
You seems to have a c,z bits somewhere but you will need two versions of 
each instruction, one which uses the carry and one which doesn't

Running more than just simple programs in real-time applications 
requires interrupt support which messes things up considerable in the 
control part of the processor.

Do you consider using only absolute branching or also doing relative 
branching?

If you really are wanting to have a processor which is code efficient, 
you might want to look at a stack machine.
If I was to create a tiny tiny processor with little area and code 
efficient I would do a stack machine.
But they are much nastier to program but they can be implemented very 
efficiently.


G�ran