Designing CPU

Antti,

> now a bit-serialized CPU to the above spec can be done.
> it would use less than 100 slices.

As you make a design more and more serial, you will often find
yourself forced to add some extra registers. So a totally serial
implementation is not necessarily the smallest one. In some of my own
experiements, four bits proved to be the optimial size (though I was
also taking performance into account when doing the evaluations).

-- Jecel

On Mar 17, 11:27=A0am, Jecel <je...@merlintec.com> wrote:
> Antti,
>
> > now a bit-serialized CPU to the above spec can be done.
> > it would use less than 100 slices.
>
> As you make a design more and more serial, you will often find
> yourself forced to add some extra registers. So a totally serial
> implementation is not necessarily the smallest one. In some of my own
> experiements, four bits proved to be the optimial size (though I was
> also taking performance into account when doing the evaluations).
>
> -- Jecel

But in the Xilinx fabric, for instance, shift registers are very
inexpensive.  Antti's divider back on 22 Mar 2005 "divide by 2^n,
n=3D21..37 =3D=3D> 3 Virtex Slices !!" was an excellent example of serial
going very small.

http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/1bfa9e3a2577=
1282

Serial logic in FPGAs has some very strong advantages over parallel
implementations for speed versus density metrics, allowing the fabric
to often run at maximum FPGA clock speeds.

It's great stuff!

- John_H

Jecel wrote:
> Antti,
> 
> 
>>now a bit-serialized CPU to the above spec can be done.
>>it would use less than 100 slices.
> 
> 
> As you make a design more and more serial, you will often find
> yourself forced to add some extra registers. So a totally serial
> implementation is not necessarily the smallest one. In some of my own
> experiements, four bits proved to be the optimial size (though I was
> also taking performance into account when doing the evaluations).

Do you mean a 4 bit CPU, or a nibble-serial design of a larger
16/20/24/28/32 bit CPU ?

(There are 4 bit CPUs with tool chains, the Atmel MARC4, and
the Atom from CoreRiver )
http://www.coreriver.co.kr/product-lines/CORERIVERmcu_linkATOM.html

-jg

Antti wrote:
> * 32 bit registers, say block of 16 (use 32 LUTRAM == 16 LUT/LC)
> * serialized can run from spi flash up to 320MBit with
>   http://www.winbond.com/NR/rdonlyres/4C63AD62-967C-4B72-AF85-1F5984E8B199/0/W25Q80.pdf
> * can address large code space
> * can run at high fabric clocks (due to lack of parallel buses and
> parallel ALUs)
> 
> now a bit-serialized CPU to the above spec can be done.
> it would use less than 100 slices.
> 
> if anyone is willing to desing this CPU, I may have funds for it,
> really please...

Did you mean you have someome to fund this, or that you could do it
if someone funds you ?

> 
> hm at 320MB/sec spi streaming, we get byte reads at 40Mhz from serial
> flash!

and you can add a second SPI chip, if you want to double the
bandwidth to 80MB/Sec.
Of course, the jump latency does not improve, but a matched core design 
would minimise jumps.
Short-Skip opcodes are an obvious cadidate.

-jg

Jim Granville wrote:
> Jecel wrote:
> > [4 bits is optimal]
>
> Do you mean a 4 bit CPU, or a nibble-serial design of a larger
> 16/20/24/28/32 bit CPU ?

In my case it was a nibble-serial implementation of a 16 bit
processor. Antti is asking for large addresses, so the software should
probably see 24 to 32 bits.

John_H wrote about shift registers in Xilinx FPGAs. I agree and have
created some a really tiny design for a waveform generator using this.
The problem I mentioned was that you need parallel addresses, however,
and the shifts won't help you there. With a serial external memory you
never need the whole address at once and might be able to avoid some
registers. The instruction register might also have to be parallel,
but by being smart when designing the instruction format you can avoid
needing all the bits all the time.

-- Jecel

On 17 Mrz., 23:07, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Antti wrote:
> > * 32 bit registers, say block of 16 (use 32 LUTRAM == 16 LUT/LC)
> > * serialized can run from spi flash up to 320MBit with
> >  http://www.winbond.com/NR/rdonlyres/4C63AD62-967C-4B72-AF85-1F5984E8B...
> > * can address large code space
> > * can run at high fabric clocks (due to lack of parallel buses and
> > parallel ALUs)
>
> > now a bit-serialized CPU to the above spec can be done.
> > it would use less than 100 slices.
>
> > if anyone is willing to desing this CPU, I may have funds for it,
> > really please...
>
> Did you mean you have someome to fund this, or that you could do it
> if someone funds you ?
>

http://code.google.com/p/serial-processor/wiki/ProjectFunding

current funding...

>
> > hm at 320MB/sec spi streaming, we get byte reads at 40Mhz from serial
> > flash!
>
> and you can add a second SPI chip, if you want to double the
> bandwidth to 80MB/Sec.
> Of course, the jump latency does not improve, but a matched core design
> would minimise jumps.
> Short-Skip opcodes are an obvious cadidate.
>
> -jg

> It's probably not very good place for asking such, but there're should
> be at least those who knows starting points.
> We need to design our own CPU which can be very slow. It can execute
> each instruction, let's say, up to 50 cycles. We don't care about
> speed, and we are also don't care about memory size for microcode, but
> we're really care about CPU unit size.

Slow CPUs are usually also not very size efficient.

> Where to read about CPU designing techniques, which are about shifting
> all possible to microcode from CPU unit? Extreme case will be probably
> Turing machine, but it's not practical. CPU registers and instructions
> in our case should be looks like ARM9 processor, maybe.

Maybe this is of interest, it recently found a new home:

http://www.opencores.org/projects.cgi/web/mcpu/overview

referringto@googlemail.com wrote:

> Maybe this is of interest, it recently found a new home:
> 
> http://www.opencores.org/projects.cgi/web/mcpu/overview

Nice small instruction set, but maybe too limitd, because even implementing
a shift operation (e.g. for implementing multiplication) would need
multiple instructions. And 64 bytes of data/code memory doesn't look very
useful.

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

On Mar 21, 5:00 pm, Frank Buss <f...@frank-buss.de> wrote:
> referrin...@googlemail.com wrote:
> > Maybe this is of interest, it recently found a new home:
>
> >http://www.opencores.org/projects.cgi/web/mcpu/overview
>
> Nice small instruction set, but maybe too limitd, because even implementing
> a shift operation (e.g. for implementing multiplication) would need
> multiple instructions. And 64 bytes of data/code memory doesn't look very
> useful.

Well, it obviously is not meant for real world applications.

climber.tim@gmail.com wrote:
> Hi.
> It's probably not very good place for asking such, but there're should
> be at least those who knows starting points.
> We need to design our own CPU which can be very slow. It can execute
> each instruction, let's say, up to 50 cycles. We don't care about
> speed, and we are also don't care about memory size for microcode, but
> we're really care about CPU unit size.
> Where to read about CPU designing techniques, which are about shifting
> all possible to microcode from CPU unit? Extreme case will be probably
> Turing machine, but it's not practical. CPU registers and instructions
> in our case should be looks like ARM9 processor, maybe.

This entire thread has been very interesting in how to "design and 
build" a CPU from an FPGA.

Even the subject line states this.

However, the OP of this thread was not looking for an education, he was 
looking for a complete project with little or no work on his part.

This is obvious by his posting from a gmail account.

Everyone who has added to this thread must have assumed that the OP was 
interested in the "design" of such a device.

I for one thank all those who added to this interesting discussion, I 
may have learned something myself.

donald