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

On Mar 13, 3:56=A0pm, 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 registe=
rs
> > 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.

I don't follow your reasoning at all.  The control logic does get
slightly more complex going from N bits to 1, but the data path logic
gets N times smaller.  Even the last step of going from 2 bits to 1
bit data path only adds 1 more bit to the control registers so the
balance is determined by which has more registers.  Of course the
logic is another matter.  But you can't just talk about which is more
complex.  The only way to compare is to build and measure.  The data
path can be analyzed, the control logic requires an understanding of
the details of the machine.


Rick

On 14 Mar, 00:36, Walter Banks <wal...@bytecraft.com> wrote:
> 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 Limitedhttp://www.bytecraft.com

Hi Walter,

your comments are always nice, right there are many uses ;)
and some are not so obvious for people with only academic
backgrounds.

I published SD card init code for CoreABC, also the
settings what options are enabled in the soft-core

http://groups.google.com/group/antti-brain/browse_thread/thread/470711dbeb2c7d5d?hl=en

when implemented in ProAsic where program rom is done from 3 input
luts the design
uses 620 tiles (each tile is either 3 input logic OR one flip flop)
and one blockram (for 6 bytes scratch)

I bet the same function (SD card init) could be implemented with far
less resources when doing
the statemachine in pure HDL, but the soft-core approuch is more
flexible, we can add more
functions by more code and relativly less extra resources, when doing
it as one big statemachine
at some point it gets too complex to maintain

CoreABC is good example of specialized core, it is really good for the
case that there is no
initialized RAM (that is rom is made from logic) and flip flops are
sparse as well. the smallest
version of CoreABC would only include APB WRT and HALT instructions,
and would be used
to just initialize APB bus peripherals. But for more complex programs
additional features
can be enabled as needed

Antti

rickman wrote:

> > http://www.bitlib.de/pub/mproz/mproz3_e.pdf (with nternal RAM)
> > http://www.bitlib.de/pub/mproz/mproz2a.pdf  (with external RAM)
 
> Are you saying that this processor can't be made smaller?

As long as I don't see it, I don't believe it.

> Registers
> can be stored in memory rather than FFs.  

There are no registers at all (beside the 15 bit program counter and
the 2 bit status register). It is a two (mproz2) or three (mproz3)
address machine with only memory operands.

> By processing the registers
> serially the logic can be greatly reduced at the expense of more
> control logic. 

You have two operands and one result but there is only one data 
path to the serial memory. This means, you at least need one 
registers to temporary hold one of the operands and an address
register to hold the address of the second operand. Mproz
also only needs two temporary registers. But the control logic 
for a serial design becomes much more complex. Mproz only has 
8 states, so the state machine can be implemented with only three 
flip-flop's (actual it's done as a one-hot machine with 8 
flip-flop's because this reduces the logic count).

> 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

As far as I remember, mproz uses about 250 two-input gates, that 
should fit well with 65 flip-flop's.

It looks to me that mproz is a memory to memory architecture with 3
instructions.

On Mar 14, 5:50=A0pm, Jacko <jackokr...@gmail.com> wrote:
> It looks to me that mproz is a memory to memory architecture with 3
> instructions.

really?

;)

Antti

> > 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.
>
> I don't follow your reasoning at all.  The control logic does get
> slightly more complex going from N bits to 1, but the data path logic
> gets N times smaller.  Even the last step of going from 2 bits to 1
> bit data path only adds 1 more bit to the control registers so the
> balance is determined by which has more registers.  Of course the
> logic is another matter.  But you can't just talk about which is more
> complex.  The only way to compare is to build and measure.  The data
> path can be analyzed, the control logic requires an understanding of
> the details of the machine.

Feel free to make a BSD 1 bit version of nibz. It may be smaller, but
will take 16 times as long to execute any code, yet will be bigger
than 1/16th the size. Therefore the computational use density
(instructions per cycle per area (m^2.s)^-1) will decrease. If
resources are really tight to maintain budget, and the lower execution
speed is not relevant for the task, then maybe the power efficiency
implications of computational use density (CUD) are not important
either.

This was a major factor in nibz design, and is why pre/post dec/inc
was included even though the area increases. The program area
decreases. I would be interested in any figures on processor CUD
bennchmarking or any suggested code examples.

cheers jacko

p.s. this is a CUD sell argument! ;-)

On Mar 14, 12:52=A0pm, Jacko <jackokr...@gmail.com> wrote:
> > > 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.
>
> > I don't follow your reasoning at all. =A0The control logic does get
> > slightly more complex going from N bits to 1, but the data path logic
> > gets N times smaller. =A0Even the last step of going from 2 bits to 1
> > bit data path only adds 1 more bit to the control registers so the
> > balance is determined by which has more registers. =A0Of course the
> > logic is another matter. =A0But you can't just talk about which is more
> > complex. =A0The only way to compare is to build and measure. =A0The dat=
a
> > path can be analyzed, the control logic requires an understanding of
> > the details of the machine.
>
> Feel free to make a BSD 1 bit version of nibz. It may be smaller, but
> will take 16 times as long to execute any code, yet will be bigger
> than 1/16th the size. Therefore the computational use density
> (instructions per cycle per area (m^2.s)^-1) will decrease. If
> resources are really tight to maintain budget, and the lower execution
> speed is not relevant for the task, then maybe the power efficiency
> implications of computational use density (CUD) are not important
> either.
>
> This was a major factor in nibz design, and is why pre/post dec/inc
> was included even though the area increases. The program area
> decreases. I would be interested in any figures on processor CUD
> bennchmarking or any suggested code examples.
>
> cheers jacko
>
> p.s. this is a CUD sell argument! ;-)

Your metric of CUD is not very useful when evaluating a processor for
a given application.  Although a higher CUD would be better if all the
other requirements are met, a processor with an optimal CUD may not be
the best choice for an application.  I have no apps that require
minimization of the CPU at all costs while needing a very low
processing speed.  But I can see where there might be a need for that
in some apps.

In general, the optimal CUD would come from matching the size of the
processor data to the size of the data in the application.  No need to
use a 16 bit data path when you are only processing bytes.  Widening a
data path to 32 bits to process 32 bit data will produce a higher CUD
than using a 16 bit machine for the same data.  But that does not mean
I will be using an 8 bit machine for 8 bit data or a 32 bit machine
for 32 bit data.  There is an overriding principle in engineering
called "good enough".  At some point optimizations are counter
productive as they impose other constraints.  All requirements need to
be considered in an appropriate weight.

Rick

On Mar 14, 11:11=A0am, Herbert Kleebauer <k...@unibwm.de> wrote:
> rickman wrote:
> > >http://www.bitlib.de/pub/mproz/mproz3_e.pdf(with nternal RAM)
> > >http://www.bitlib.de/pub/mproz/mproz2a.pdf=A0(with external RAM)
> > Are you saying that this processor can't be made smaller?
>
> As long as I don't see it, I don't believe it.

Ok, I guess that pretty much limits the discussion.


> > Registers
> > can be stored in memory rather than FFs. =A0
>
> There are no registers at all (beside the 15 bit program counter and
> the 2 bit status register). It is a two (mproz2) or three (mproz3)
> address machine with only memory operands.

Yes, I read the description and I did not figure it out completely.
This is a bizarre machine that has no practical value that I can see.
You are defining it as a "minimal" machine because of its FF count.
But it is just trading off FF based registers and LUT logic for memory
usage.  I don't see how that is "minimal" in any real way.  Three
words of memory to perform an ADD???  That's not minimal.


> > By processing the registers
> > serially the logic can be greatly reduced at the expense of more
> > control logic.
>
> You have two operands and one result but there is only one data
> path to the serial memory. This means, you at least need one
> registers to temporary hold one of the operands and an address
> register to hold the address of the second operand. Mproz
> also only needs two temporary registers. But the control logic
> for a serial design becomes much more complex. Mproz only has
> 8 states, so the state machine can be implemented with only three
> flip-flop's (actual it's done as a one-hot machine with 8
> flip-flop's because this reduces the logic count).

Why do you need temporary registers?  If the memory is serial, each
bit can be fetched as needed.  You are imposing a word access method
on this.


> > BTW, I don't know why you are stating the FF count as if this were a
> > good measure of design size. =A0Most designs in FPGAs use more LUTs tha=
n
> > FFs. =A0The logic of this beast is likely =A0With 65 FFs this may well =
be
> > designed for a CPLD which has more capable logic with each FF. =A0But
>
> As far as I remember, mproz uses about 250 two-input gates, that
> should fit well with 65 flip-flop's.

How about the memory?  I expect that will be an order of magnitude
larger than the machine itself, even for a small program.

Rick

On Mar 14, 8:49=A0pm, rickman <gnu...@gmail.com> wrote:
> On Mar 14, 11:11=A0am, Herbert Kleebauer <k...@unibwm.de> wrote:
>
> > rickman wrote:
> > > >http://www.bitlib.de/pub/mproz/mproz3_e.pdf(withnternal RAM)
> > > >http://www.bitlib.de/pub/mproz/mproz2a.pdf=A0(with external RAM)
> > > Are you saying that this processor can't be made smaller?
>
> > As long as I don't see it, I don't believe it.
>
> Ok, I guess that pretty much limits the discussion.
>
> > > Registers
> > > can be stored in memory rather than FFs. =A0
>
> > There are no registers at all (beside the 15 bit program counter and
> > the 2 bit status register). It is a two (mproz2) or three (mproz3)
> > address machine with only memory operands.
>
> Yes, I read the description and I did not figure it out completely.
> This is a bizarre machine that has no practical value that I can see.
> You are defining it as a "minimal" machine because of its FF count.
> But it is just trading off FF based registers and LUT logic for memory
> usage. =A0I don't see how that is "minimal" in any real way. =A0Three
> words of memory to perform an ADD??? =A0That's not minimal.
>
> > > By processing the registers
> > > serially the logic can be greatly reduced at the expense of more
> > > control logic.
>
> > You have two operands and one result but there is only one data
> > path to the serial memory. This means, you at least need one
> > registers to temporary hold one of the operands and an address
> > register to hold the address of the second operand. Mproz
> > also only needs two temporary registers. But the control logic
> > for a serial design becomes much more complex. Mproz only has
> > 8 states, so the state machine can be implemented with only three
> > flip-flop's (actual it's done as a one-hot machine with 8
> > flip-flop's because this reduces the logic count).
>
> Why do you need temporary registers? =A0If the memory is serial, each
> bit can be fetched as needed. =A0You are imposing a word access method
> on this.
>
> > > BTW, I don't know why you are stating the FF count as if this were a
> > > good measure of design size. =A0Most designs in FPGAs use more LUTs t=
han
> > > FFs. =A0The logic of this beast is likely =A0With 65 FFs this may wel=
l be
> > > designed for a CPLD which has more capable logic with each FF. =A0But
>
> > As far as I remember, mproz uses about 250 two-input gates, that
> > should fit well with 65 flip-flop's.
>
> How about the memory? =A0I expect that will be an order of magnitude
> larger than the machine itself, even for a small program.
>
> Rick

right

mproz stands for minimal.. so it is minimal in terms of instructions
and resources
in the tradeoff of speed (8 clocks!) and program size

the machine is funny, it can do subroutine calls by patching own code
on the fly
that is self modifying code is needed, normal instructions are 6 bytes
or 8 bytes
if new immediate constant is needed. Also shift and rotate are very
clumsy i guess

so the maximum 32K memory space would only hold say about 5K
instructions !

Antti

Jacko wrote:

> Feel free to make a BSD 1 bit version of nibz. It may be smaller, but
> will take 16 times as long to execute any code, yet will be bigger
> than 1/16th the size. Therefore the computational use density
> (instructions per cycle per area (m^2.s)^-1) will decrease. If
> resources are really tight to maintain budget, and the lower execution
> speed is not relevant for the task, then maybe the power efficiency
> implications of computational use density (CUD) are not important
> either.

A very first order metric. I am not arguing for bit serial processors
but the 16 to 1 makes an assumption that the bit serial is only
implementing a 16 bit data path. A well designed bit serial instruction
set would change the metrics on both the hardware and the
performance.

You are correct that control overhead does not scale but
bit serial processors can have a bunch of viable applications
which has been my point. Low pin count to memory and I/O
for example. The SDcard gives multiple gigabytes of memory
with a few pins.

Regards,

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