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

On Mar 13, 12:18=A0am, Walter Banks <wal...@bytecraft.com> wrote:
> -jg wrote:
> > On Mar 13, 8:12 am, Walter Banks <wal...@bytecraft.com> wrote:
> > > Jim
>
> > > You beat me to the comment on serial processors.
>
> > > A long time ago I designed a number of bit serial processors
> > > they can be very hardware efficient. There are a number of
> > > very clever math algorithms that take advantage of bit serial.
>
> > The obvious next question, is do you have compilers
> > & maths libraries for such an animal ? ;)
>
> We did do a COP8 compiler where some of the features was
> a software / hardware solution.
>
> There were a lot of papers on this stuff at one point. Most I
> would expect if there are on the net will be available in image
> only.
>
> The COP8 is one of the well known bit serial processors. Many
> of the early 8051's were bit serial. Go back far enough and there is
> the PDP8S the S was jokingly referred to as slow. The IBM 1620
> was a serial nybble processor. The 1620 had one of the known
> serial processor advantages that of variable length numbers.
>
> All of which could be implemented with a SD card and some logic.
>
> Regards,
>
> --
> Walter Banks
> Byte Craft Limitedhttp://www.bytecraft.com

for execute in place for SD possible 4 bit cpu would be best
as sd fetches 4 bit per clock

eh, there is 4 bit 8051 !!
Atom

i wonder if that would be very small in FPGA or not
didnt deep enough to see how much of 8051 is there
and what is made 4 bit wide


Antti

On Mar 12, 6:31=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 12, 8:57=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > I seem to recall that you were trying to find a bit serial CPU that
> > would be the smallest possible in an FPGA. =A0Did you ever find one you
> > liked? =A0Personally, I think that is a goal with a very low target
> > application size. =A0But certainly there are some apps where this could
> > be useful.
>
> Bit-serial (like Cop8) only makes size-sense to simplify bus routing.
> - but that's almost free in a FPGA, so other needs better drive Bit-
> Serial.

I don't agree with that.  An ALU can be serial and a register file can
be a single bit wide with random access to any bit of any register.  A
single LUT4 can hold two 8 bit registers so a CPU with four 8 bit
registers can hold them in two LUT4s.  The main memory likewise can be
implemented with a single bit data path.  So the data path of a small
CPU can be as little as half a dozen LUTs.  Of course there is a trade
off in complexity of the control logic, but still the CPU can be made
very small compared to even a PICO blaze.  With a little innovation,
the data size can be arbitrarily wide as well as independent of the
data path.

A stack machine can use a block ram as both the data and return stacks
with a bit of address work.  I am doing that with a 16 bit wide
machine and I expect the same architecture can be used with a 1 bit
data path to greatly reduce the amount of resources used.


> Bit-serial Multiply/divide can save resource, but that's less a core
> than
> an algortihm =A0trade-off, and Mul/Div are rare in the smallest cores
> anyway.

You can all any of the data path sizings are "algorithm" trade-offs,
but they can still be very efficient in resource usage.


> One plus that appeals to me, is Execute from Serial FLASH, (and now
> Serial RAM)
> [does a nibble fetch from 4 bit SPI still count as Bit-serial ? ]
> =A0as resource space. Saves MANY pins, and PCB space, but I'm not sure
> the
> core will be _smaller_ as a result - more likely slightly larger ?

The control logic is likely larger.  If you can't figure out how to
make the data path structure smaller by reducing the data path width,
you need to go back to school!

Rick

On Mar 12, 2:56=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 12, 12:31=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
>
>
>
> > On Mar 12, 8:57=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > > I seem to recall that you were trying to find a bit serial CPU that
> > > would be the smallest possible in an FPGA. =A0Did you ever find one y=
ou
> > > liked? =A0Personally, I think that is a goal with a very low target
> > > application size. =A0But certainly there are some apps where this cou=
ld
> > > be useful.
>
> > Bit-serial (like Cop8) only makes size-sense to simplify bus routing.
> > - but that's almost free in a FPGA, so other needs better drive Bit-
> > Serial.
>
> > Bit-serial Multiply/divide can save resource, but that's less a core
> > than
> > an algortihm =A0trade-off, and Mul/Div are rare in the smallest cores
> > anyway.
>
> > One plus that appeals to me, is Execute from Serial FLASH, (and now
> > Serial RAM)
> > [does a nibble fetch from 4 bit SPI still count as Bit-serial ? ]
> > =A0as resource space. Saves MANY pins, and PCB space, but I'm not sure
> > the
> > core will be _smaller_ as a result - more likely slightly larger ?
>
> > -jg
>
> Jim,
>
> this almost the old discussion ;)
>
> yes, a bit serial processor that executes in place either from spi
> flash or SD card
> and uses say the dual 512 data buffers of atmel dataflash as ram could
> be
> very low resources
>
> say for lowest cost Xilinx FPGA S3A-50 resources are pretty tight, so
> if
> a soft core can execute from the same spi flash that is used for
> config
> using the flash as code memory and flash buffers as ram, it would
> retain almost all the rest of the FPGA resources for user application
>
> should be doable in <100 Xilinx s3a slices i think
>
> Antti

If you really mean 100 ***slices*** then you are not beating the
parallel processors.  The pico blaze and the Micro8 are both about 200
LUTs, IIRC.  I don't measure slices because only Xilinx and Lattice
have slices.  Most FPGAs have LUT4s (except for Actel and Atmel, but
nobody uses Atmel and not many use Actel).

Rick

On Mar 12, 1:30=A0pm, 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?

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

Rick

On Mar 12, 1:44=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 12, 7:30=A0pm, 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
>
> without any io/ram/rom its kinda useless?
> and such small soft cores can usually run 200mhz+ in decent FPGA's ;)
> (150mhz in low cost FPGA's)
>
> ok, 292 or <570LE, it's ir-relevant as long as there are no tools to
> program it,
> and your forth-xxx whatever isnt useable yet?
>
> there are zillions of stack soft-cpu's but i fail to see nice and easy
> tools
> todo anything with them.. no compilers
> some forth xxx things that requires some xxx to be installed on your
> PC
> and then do something very awkward and some more to get some code
> actually executing...
>
> and yes I have programmed in Forth many decades ago, think used
> something called GraphForth for msdos
>
> =3D=3D
>
> compile_my_forth_to_bin.exe hello.forth > hello.bin
>
> if that creates a ready to use bin file to run with your nibz
> and you have tons of tested libraries.. someone may get interested..
>
> if you have something totally untested, not ready no demos
> no reference design ?
>
> =3D=3D
>
> ok ZPU (a stack machine also) has GCC toolchain kind of, but it isnt
> that small anymore the core despite being advertized as smallest 32
> bit core with GCC support
>
> Antti

The author claims one incarnation is around 400 LUTs.  I have not seen
any of the four versions actually in a form that can be compiled to
run a program of your choice without some work.  I did a block diagram
of the ZPU small and estimated around 600 LUTs.  They are all saying
it is a bit slow with a clock speed of under 50 MHz, sometimes very
far below 50 MHz, IIRC and under 10, maybe under 1 DMIPS, I can't
remember exactly.  The effort is poorly organized and I found it hard
to contribute anything useful other than my block diagram drawing
which I'm not sure anyone cared about.  Most of the participants are
hard core software guys who don't seem to understand how to optimize
an FPGA CPU for resources, speed and code density.  Code density is a
primary consideration which is one I share.  But the instruction set
is designed for "efficient" C coding which means the author doesn't
want to put too much effort into the compiler to produce instructions
that are easier to put in the FPGA.  He optimized the compiler back
end and now that tail is wagging the ZPU dog.

Still, it is a very interesting effort and I am watching the mailing
list and occasionally make a post.

Rick

On Mar 12, 11:38=A0pm, rickman <gnu...@gmail.com> wrote:
> On Mar 12, 2:56=A0pm, "Antti.Luk...@googlemail.com"
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On Mar 12, 12:31=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
>
> > > On Mar 12, 8:57=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > > > I seem to recall that you were trying to find a bit serial CPU that
> > > > would be the smallest possible in an FPGA. =A0Did you ever find one=
 you
> > > > liked? =A0Personally, I think that is a goal with a very low target
> > > > application size. =A0But certainly there are some apps where this c=
ould
> > > > be useful.
>
> > > Bit-serial (like Cop8) only makes size-sense to simplify bus routing.
> > > - but that's almost free in a FPGA, so other needs better drive Bit-
> > > Serial.
>
> > > Bit-serial Multiply/divide can save resource, but that's less a core
> > > than
> > > an algortihm =A0trade-off, and Mul/Div are rare in the smallest cores
> > > anyway.
>
> > > One plus that appeals to me, is Execute from Serial FLASH, (and now
> > > Serial RAM)
> > > [does a nibble fetch from 4 bit SPI still count as Bit-serial ? ]
> > > =A0as resource space. Saves MANY pins, and PCB space, but I'm not sur=
e
> > > the
> > > core will be _smaller_ as a result - more likely slightly larger ?
>
> > > -jg
>
> > Jim,
>
> > this almost the old discussion ;)
>
> > yes, a bit serial processor that executes in place either from spi
> > flash or SD card
> > and uses say the dual 512 data buffers of atmel dataflash as ram could
> > be
> > very low resources
>
> > say for lowest cost Xilinx FPGA S3A-50 resources are pretty tight, so
> > if
> > a soft core can execute from the same spi flash that is used for
> > config
> > using the flash as code memory and flash buffers as ram, it would
> > retain almost all the rest of the FPGA resources for user application
>
> > should be doable in <100 Xilinx s3a slices i think
>
> > Antti
>
> If you really mean 100 ***slices*** then you are not beating the
> parallel processors. =A0The pico blaze and the Micro8 are both about 200
> LUTs, IIRC. =A0I don't measure slices because only Xilinx and Lattice
> have slices. =A0Most FPGAs have LUT4s (except for Actel and Atmel, but
> nobody uses Atmel and not many use Actel).
>
> Rick

hm, i did mean <200 lut and yes it is about the size of picoblaze i am
aware
of that but it if it works with LARGE memory space >=3D8GB and does not
use
FPGA ram (but the spi flash ram buffers) then i would say if it is fit
<200 lut it
would be very nice already. I did assume the lut number for some
minimal
but full functional system, not the the bare cpu only

Antti
PS I do have the Atmel FPSLIC board+dongle and some silicon samples
also Actel ProAsic/ProAsic3/Fusion boards and programmers,
but you are right, i can not say i have used the Atmel.. its just too
damn
expensive compared to features it has.

>
>The author claims one incarnation is around 400 LUTs.  I have not seen
>any of the four versions actually in a form that can be compiled to
>run a program of your choice without some work.  I did a block diagram
>of the ZPU small and estimated around 600 LUTs.  They are all saying
>it is a bit slow with a clock speed of under 50 MHz, sometimes very
>far below 50 MHz, IIRC and under 10, maybe under 1 DMIPS, I can't
>remember exactly.  The effort is poorly organized and I found it hard
>to contribute anything useful other than my block diagram drawing
>which I'm not sure anyone cared about.  Most of the participants are
>hard core software guys who don't seem to understand how to optimize
>an FPGA CPU for resources, speed and code density.  Code density is a
>primary consideration which is one I share.  But the instruction set
>is designed for "efficient" C coding which means the author doesn't
>want to put too much effort into the compiler to produce instructions
>that are easier to put in the FPGA.  He optimized the compiler back
>end and now that tail is wagging the ZPU dog.
>
>Still, it is a very interesting effort and I am watching the mailing
>list and occasionally make a post.

If the clock speed gets that slow, I'd consider making a
simple clean CPU and emulating the ZPU instruction set.  It
would need ROM for the microcode and somebody would have to
write the microcode.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

-jg wrote:

> On Mar 13, 8:12 am, Walter Banks <wal...@bytecraft.com> wrote:
> > Jim
> >
> > You beat me to the comment on serial processors.
> >
> > A long time ago I designed a number of bit serial processors
> > they can be very hardware efficient. There are a number of
> > very clever math algorithms that take advantage of bit serial.
>
> The obvious next question, is do you have compilers
> & maths libraries for such an animal ? ;)

We did do a COP8 compiler where some of the features was
a software / hardware solution.

There were a lot of papers on this stuff at one point. Most I
would expect if there are on the net will be available in image
only.

The COP8 is one of the well known bit serial processors. Many
of the early 8051's were bit serial. Go back far enough and there is
the PDP8S the S was jokingly referred to as slow. The IBM 1620
was a serial nybble processor. The 1620 had one of the known
serial processor advantages that of variable length numbers.

All of which could be implemented with a SD card and some logic.

Regards,

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

On Mar 13, 10:32=A0am, "Antti.Luk...@googlemail.com" > for execute in
place for SD possible 4 bit cpu would be best
> as sd fetches 4 bit per clock
>
> eh, there is 4 bit 8051 !!
> Atom
>
> i wonder if that would be very small in FPGA or not
> didnt deep enough to see how much of 8051 is there
> and what is made 4 bit wide

Atom (4 bit '80C51') Data is here

http://www.coreriver.co.kr/data/manual/BM-ATOM1.1-V1.0.pdf

Atom moves to 4 bits, drops all registers,
Opcodes are 1 byte, 2 for calls
Direct memory index of 4 bits is supported.(no offset index?)
An 8 bit memory-index pointer exists
Calls are 12 bits
Some Boolean opcodes remain
Does have PUSH A, POP A, & and 8 bit Stack Pointer
No MUL/DIV, and no RETI

So not that well suited to FPGA morph, & too large for CPLDs
- FPGA's better suit 18 bit opcodes, and the dual-port ram, means
register-cores
map better.

Width is almost free inside a FPGA, & a 36 bit fetch (9 clocks) from
nibble SPI, would fit two 18b opcodes - and move you into SoftCPU
space.

-jg

On Mar 12, 6:08 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >The author claims one incarnation is around 400 LUTs.  I have not seen
> >any of the four versions actually in a form that can be compiled to
> >run a program of your choice without some work.  I did a block diagram
> >of the ZPU small and estimated around 600 LUTs.  They are all saying
> >it is a bit slow with a clock speed of under 50 MHz, sometimes very
> >far below 50 MHz, IIRC and under 10, maybe under 1 DMIPS, I can't
> >remember exactly.  The effort is poorly organized and I found it hard
> >to contribute anything useful other than my block diagram drawing
> >which I'm not sure anyone cared about.  Most of the participants are
> >hard core software guys who don't seem to understand how to optimize
> >an FPGA CPU for resources, speed and code density.  Code density is a
> >primary consideration which is one I share.  But the instruction set
> >is designed for "efficient" C coding which means the author doesn't
> >want to put too much effort into the compiler to produce instructions
> >that are easier to put in the FPGA.  He optimized the compiler back
> >end and now that tail is wagging the ZPU dog.
>
> >Still, it is a very interesting effort and I am watching the mailing
> >list and occasionally make a post.
>
> If the clock speed gets that slow, I'd consider making a
> simple clean CPU and emulating the ZPU instruction set.  It
> would need ROM for the microcode and somebody would have to
> write the microcode.

I don't think the clock speed is all that slow.  It just doesn't do a
lot in each clock cycle I believe.  It is stack based, but the stack
is in memory, not inside the CPU.  I don't know all the details.  I
looked at the code a bit, but that is a poor way to learn the
architecture... or at least a painful way to learn it.  I did draw a
diagram of the data paths.  It is surprisingly straightforward, but
each part of the CPU process is a separate clock cycle,
Fetch, Decode, and multiple Execute steps.  As a hardware designer it
is not anything like what I would have designed, but they did keep it
fairly small at 600 LUTs ballpark.  The idea is to have other
implementations that run identical code but much faster.

Like I said, it is interesting and I'll keep watching it.

Rick