Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz

On 12 Mar, 21:44, rickman <gnu...@gmail.com> wrote:
> On Mar 12, 1:30 pm, Jacko <jackokr...@gmail.com> wrote:
>
> > hi
>
> > 292 LEs fully stripped, no ROM, no RAM no IO pins, 16 bit address, 16
> > bit data Bus. Expected 20-30MHz, (36 pins plus power), About 10 MIPS
> > at 20MHz.
>
> > cheers jacko
>
> What's a MIPS?  Native instructions?  Or something that can be
> compared to other processors?

Native instructions. Fetch/execute, and Fetch/execute/execute (SUm
instruction).

> I have yet found a good way to compare these small, FPGA CPUs.  The
> ZPU is pretty small, but the originator seems to still think in terms
> of Dhrystones.  I can't begin to measure my processor in Dhrystones.

I do not yet have any C compilier so drystones are not measurable.

> The original imnplementation was about 600 LUTs, 50 MHz, 50 MIPS in an
> Altera ACEX 1K part (very old and pretty slow).  I am working to
> update it for a more current FPGA.

A re-implementation of the ALU is possible to improve clock rate, but
the area does increase as it is a 16 bit ALU, with 4 operations. So 4
ops * 4way multiplex. The reason for using a carry chain is that the
alu shrinks as some of the multiplex is merged with the alu operations
(not much more complicated than just add in luts). I understand from
altera support that the two lut3 arithmetic mode is not really used,
and so fast carry propagation is not done, and it is the critical
path, hence the extra cycle inserted.

A harvard architecture is not used. Code density is reasonably high
using threaded subroutines, as no jump opcode has to prefix the jump
address. In full ASIC custom logic such carry propergation issues are
not as dominant .So considering each instruction is 16 bit data in
width, the processor is quite impressivly small. If only the carry
chain was used effectively in lut4 mode.

Of course all optimization was for area, and not speed, with no
retiming. Just the register duplication (2 LEs) for increased
routability. Yes lack of high level software tools is a real pain for
product design. But I'm slowly working on that. I do not have a major
development team. I am just me, and this is not paid work.

I think my offer of 1 free core per chip, for just a logo print, and
documentation copyright recognition and URL is very good. Especially
as this offer unlike the still standing BSD offer allows derived
products without revealing the derived source.

Cheers jacko

On 13 Mar, 05:22, Jacko <jackokr...@gmail.com> wrote:
> On 12 Mar, 21:44, rickman <gnu...@gmail.com> wrote:
>
> > On Mar 12, 1:30 pm, Jacko <jackokr...@gmail.com> wrote:
>
> > > hi
>
> > > 292 LEs fully stripped, no ROM, no RAM no IO pins, 16 bit address, 16
> > > bit data Bus. Expected 20-30MHz, (36 pins plus power), About 10 MIPS
> > > at 20MHz.
>
> > > cheers jacko
>
> > What's a MIPS? =A0Native instructions? =A0Or something that can be
> > compared to other processors?
>
> Native instructions. Fetch/execute, and Fetch/execute/execute (SUm
> instruction).
>
> > I have yet found a good way to compare these small, FPGA CPUs. =A0The
> > ZPU is pretty small, but the originator seems to still think in terms
> > of Dhrystones. =A0I can't begin to measure my processor in Dhrystones.
>
> I do not yet have any C compilier so drystones are not measurable.
>
> > The original imnplementation was about 600 LUTs, 50 MHz, 50 MIPS in an
> > Altera ACEX 1K part (very old and pretty slow). =A0I am working to
> > update it for a more current FPGA.
>
> A re-implementation of the ALU is possible to improve clock rate, but
> the area does increase as it is a 16 bit ALU, with 4 operations. So 4
> ops * 4way multiplex. The reason for using a carry chain is that the
> alu shrinks as some of the multiplex is merged with the alu operations
> (not much more complicated than just add in luts). I understand from
> altera support that the two lut3 arithmetic mode is not really used,
> and so fast carry propagation is not done, and it is the critical
> path, hence the extra cycle inserted.
>
> A harvard architecture is not used. Code density is reasonably high
> using threaded subroutines, as no jump opcode has to prefix the jump
> address. In full ASIC custom logic such carry propergation issues are
> not as dominant .So considering each instruction is 16 bit data in
> width, the processor is quite impressivly small. If only the carry
> chain was used effectively in lut4 mode.
>
> Of course all optimization was for area, and not speed, with no
> retiming. Just the register duplication (2 LEs) for increased
> routability. Yes lack of high level software tools is a real pain for
> product design. But I'm slowly working on that. I do not have a major
> development team. I am just me, and this is not paid work.
>
> I think my offer of 1 free core per chip, for just a logo print, and
> documentation copyright recognition and URL is very good. Especially
> as this offer unlike the still standing BSD offer allows derived
> products without revealing the derived source.
>
> Cheers jacko

Jacko

what you think as "good" is not the same what others think.

you !=3D others;

if you use BSD license you can not attach it to the FIRST
instance of the core inside and asic or fpga, meaning
the user is free to use ANY number of copies of the
core, your restriction is not valid...

as of the logo print, sorry if you do not understand it,
even if the core and other copyright restrictions by
you may be ok for the legal department of large scale
corporation, the logo print will not be... for sure
not with that low quality bitmap, and also not when
you make better artwork also very unlikely

so what you are asking and what you think is good
is actually something that will drive any potential
users (if there are any) away from using the core.

if you want some $$$ then you should offer some
commercial licensing, not try get money from
paypal donations and indirect advertizement
by the logo print of yours...

my 3 cents

Antti

rickman wrote:
 
> > I am still looking for a good small soft-core, and well it seem
> > not to exist...
> 
> I seem to recall that you were trying to find a bit serial CPU that
> would be the smallest possible in an FPGA.  

I don't think it is possible to make a serial CPU smaller than
a parallel one. Here is a 16 bit CPU with interrupt support 
built with only 65 flip-flop's. If you reduce the size to 
12 bit (3 kbyte memory space) you can even save 12 flip-flop's.

http://www.bitlib.de/pub/mproz/mproz3_e.pdf  (with internal RAM)
http://www.bitlib.de/pub/mproz/mproz2a.pdf    (with external RAM)

schematics in the zip files:

http://www.bitlib.de/pub/mproz/

> Jacko
>
> what you think as "good" is not the same what others think.
>
> you != others;

I never said others may think this is a good offer, just that I think
it is a good offer.

> if you use BSD license you can not attach it to the FIRST
> instance of the core inside and asic or fpga, meaning
> the user is free to use ANY number of copies of the
> core, your restriction is not valid...

If BSD is used then BSD it is, BSD does not prevent me from doing what
I want with MY source, and so I am able to offer OTHER licences. The 1
core per chip licence is not BSD, instead I am making another issue of
the code under my copyright, in acordance with my wishes.

You are correct with respect to the licence used for the BSD issue.
But theat issue would not allow using proprietory logic, without that
other logic also being made part of the BSD.

> as of the logo print, sorry if you do not understand it,
> even if the core and other copyright restrictions by
> you may be ok for the legal department of large scale
> corporation, the logo print will not be... for sure
> not with that low quality bitmap, and also not when
> you make better artwork also very unlikely

What's so difficult about the reproduction of a BW image, also this
non BSD licence version did in no way specify the size that the logo
had to be printed at.

> so what you are asking and what you think is good
> is actually something that will drive any potential
> users (if there are any) away from using the core.

?

> if you want some $$$ then you should offer some
> commercial licensing, not try get money from
> paypal donations and indirect advertizement
> by the logo print of yours...

I have not refused any offer of comercial licencing, although I do
think that more than 1 core per chip is a little way off.

> my 3 cents

Fair enough

cheers jacko

On 13 Mar, 13:02, Herbert Kleebauer <k...@unibwm.de> wrote:
> rickman wrote:
> > > I am still looking for a good small soft-core, and well it seem
> > > not to exist...
>
> > I seem to recall that you were trying to find a bit serial CPU that
> > would be the smallest possible in an FPGA. =A0
>
> I don't think it is possible to make a serial CPU smaller than
> a parallel one. Here is a 16 bit CPU with interrupt support
> built with only 65 flip-flop's. If you reduce the size to
> 12 bit (3 kbyte memory space) you can even save 12 flip-flop's.
>
> http://www.bitlib.de/pub/mproz/mproz3_e.pdf=A0(with internal RAM)http://w=
ww.bitlib.de/pub/mproz/mproz2a.pdf=A0 =A0(with external RAM)
>
> schematics in the zip files:
>
> http://www.bitlib.de/pub/mproz/

Interesting MISC design. Any idea what the LE count is?

Extra features offered by nibz.

-- predecrement/postincrement
-- a logic accumulator
-- faster indexing
-- subroutine support instructions
-- a parameter stack
-- a clock counter

Features not currently offered by nibz

-- interrupt support

cheers jacko

Herbert Kleebauer wrote:

> rickman wrote:
>
> > > I am still looking for a good small soft-core, and well it seem
> > > not to exist...
> >
> > I seem to recall that you were trying to find a bit serial CPU that
> > would be the smallest possible in an FPGA.
>
> I don't think it is possible to make a serial CPU smaller than
> a parallel one. Here is a 16 bit CPU with interrupt support
> built with only 65 flip-flop's. If you reduce the size to
> 12 bit (3 kbyte memory space) you can even save 12 flip-flop's.
>
> http://www.bitlib.de/pub/mproz/mproz3_e.pdf  (with internal RAM)
> http://www.bitlib.de/pub/mproz/mproz2a.pdf    (with external RAM)
>
> schematics in the zip files:
>
> http://www.bitlib.de/pub/mproz/

Serial processors only require a 1 bit alu, registers are shift registers
with a single in and out data line. The availability of large lowcost
bit serial memories like SD cards opens the possibility of creating a
small processor.

There may be issues how a serial processor design will map on the current
parts but the logic is significantly simpler that an equivalent parallel
design. None of this is free. The resulting processor will be slower for
the same clock speed.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

Walter Banks wrote:
> Herbert Kleebauer wrote:

> > I don't think it is possible to make a serial CPU smaller than
> > a parallel one. Here is a 16 bit CPU with interrupt support
> > built with only 65 flip-flop's. 

> Serial processors only require a 1 bit alu, registers are shift registers
> with a single in and out data line. The availability of large lowcost
> bit serial memories like SD cards opens the possibility of creating a
> small processor.

Yes, you will save some logic if you use a 1 bit alu, but that's not
as much as you have to add for controlling the serial alu.

The goal was to make the smallest possible CPU which can at 
least address 32 kbyte RAM and supports interrupts. The first
idea was to use a serial design, but if you spend some time
thinking about it, then you will see that you never can get
it as small as a 16 bit design (also a 8 bit design is bigger
than a 16 bit design). This is at least true for the gate count,
if you also consider the routing resources then the difference
may be smaller.

On 13 Mar, 21:56, Herbert Kleebauer <k...@unibwm.de> wrote:
> Walter Banks wrote:
> > Herbert Kleebauer wrote:
> > > I don't think it is possible to make a serial CPU smaller than
> > > a parallel one. Here is a 16 bit CPU with interrupt support
> > > built with only 65 flip-flop's.
> > Serial processors only require a 1 bit alu, registers are shift registers
> > with a single in and out data line. The availability of large lowcost
> > bit serial memories like SD cards opens the possibility of creating a
> > small processor.
>
> Yes, you will save some logic if you use a 1 bit alu, but that's not
> as much as you have to add for controlling the serial alu.
>
> The goal was to make the smallest possible CPU which can at
> least address 32 kbyte RAM and supports interrupts. The first
> idea was to use a serial design, but if you spend some time
> thinking about it, then you will see that you never can get
> it as small as a 16 bit design (also a 8 bit design is bigger
> than a 16 bit design). This is at least true for the gate count,
> if you also consider the routing resources then the difference
> may be smaller.

it all depends the useage scenario

if BLOCK RAMs are available, it one concept
if not it different...

mproz executing code from serial flash would be
highly inefficient in terms of clock cycles wasted

so it different goals.

mproz uses 3 words per instruction, if code space
is 8mb or 8gb as for in place execute from sd
then it would be 12 bytes to read per instruction

a serialized design that aligns alu operations
with the speed of serially fetched instruction
bits would achive much better speed

Antti

Herbert Kleebauer wrote:

> Walter Banks wrote:
> > Herbert Kleebauer wrote:
>
> > > I don't think it is possible to make a serial CPU smaller than
> > > a parallel one. Here is a 16 bit CPU with interrupt support
> > > built with only 65 flip-flop's.
>
> > Serial processors only require a 1 bit alu, registers are shift registers
> > with a single in and out data line. The availability of large lowcost
> > bit serial memories like SD cards opens the possibility of creating a
> > small processor.
>
> Yes, you will save some logic if you use a 1 bit alu, but that's not
> as much as you have to add for controlling the serial alu.
>

Bit serial will be slow but remember that the data paths to registers
are reduced. The logic is considerably simpler.

There are other advantages as well like the ability to have variable
length data types, reducing the number of instructions to do
multi-byte math.

Bit serial is slower, to be sure. The controller needed to use a
SD card is not very much.

There are many applications that could be well suited to a bit serial
processor, for example a data logger.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

On Mar 13, 9:02 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> rickman wrote:
> > > I am still looking for a good small soft-core, and well it seem
> > > not to exist...
>
> > I seem to recall that you were trying to find a bit serial CPU that
> > would be the smallest possible in an FPGA.
>
> I don't think it is possible to make a serial CPU smaller than
> a parallel one. Here is a 16 bit CPU with interrupt support
> built with only 65 flip-flop's. If you reduce the size to
> 12 bit (3 kbyte memory space) you can even save 12 flip-flop's.
>
> http://www.bitlib.de/pub/mproz/mproz3_e.pdf (with internal RAM)http://www.bitlib.de/pub/mproz/mproz2a.pdf   (with external RAM)
>
> schematics in the zip files:
>
> http://www.bitlib.de/pub/mproz/

Are you saying that this processor can't be made smaller?  Registers
can be stored in memory rather than FFs.  By processing the registers
serially the logic can be greatly reduced at the expense of more
control logic.  I don't see how you can say that any machine can't be
reduced by replacing

BTW, I don't know why you are stating the FF count as if this were a
good measure of design size.  Most designs in FPGAs use more LUTs than
FFs.  The logic of this beast is likely  With 65 FFs this may well be
designed for a CPLD which has more capable logic with each FF.  But
few of those parts have any ram.  That means you need external ram and
I don't consider that a "simple" or small design.  Still, I have to
say, this is one goofy processor.  It does everything in memory and
only has five instructions.  Is this thing really of any use other
than academic?

Rick