Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A

Hi,

It looks like this group has been slumbering for a bit. This seems to
be the ideal place to have my discussion, but I'm not sure if there
will be anyone listening? I see that there are lots of members of
this group, but not many postings.

I am returning to my project to implement a small CPU in an FPGA. I
had looked at some of Jan Gray's work back in 2002 or so. I don't see
where he has done anything on those CPUs since then. The gr0040 looks
to be very interesting, but it appears that he has not released the
tools he developed.

I also found a tiny8 on opencores.org that looks interesting. Many of
the projects there are very incomplete, some even have never produced
a single document of any sort. Only a few have produced a working
processor complete with tools.

What small CPUs have people used in FGPAs? What do you use for tools?
Has anyone found a usable CPU with tools that uses less than 500 LUTs?

Rick
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

----- Original Message -----
From: "Rick Collins"
To:
Sent: Thursday, July 31, 2008 3:18 PM
Subject: [fpga-cpu] Small CPUs in FPGAs
> Hi,
>
> It looks like this group has been slumbering for a bit. This seems to
> be the ideal place to have my discussion, but I'm not sure if there
> will be anyone listening? I see that there are lots of members of
> this group, but not many postings.
>
> I am returning to my project to implement a small CPU in an FPGA. I
> had looked at some of Jan Gray's work back in 2002 or so. I don't see
> where he has done anything on those CPUs since then. The gr0040 looks
> to be very interesting, but it appears that he has not released the
> tools he developed.
>
> I also found a tiny8 on opencores.org that looks interesting. Many of
> the projects there are very incomplete, some even have never produced
> a single document of any sort. Only a few have produced a working
> processor complete with tools.
>
> What small CPUs have people used in FGPAs? What do you use for tools?
> Has anyone found a usable CPU with tools that uses less than 500 LUTs?

The Tiny8 does look interesting; I like the resemblance to the TI 9900
architecture. I worked with a 9995 many years ago and wrote a
cross-assembler for it using Microsoft Macro80 macros, because we couldn't
afford the TI tools. I've got an Altera Flex 10K10 board I designed some
years ago, I could put it on that, although it would be more useful on my
Spartan 3 board.

Leon
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Hi Rick,

On Thu, 2008-07-31 at 14:18 +0000, Rick Collins wrote:

> It looks like this group has been slumbering for a bit. This seems to
> be the ideal place to have my discussion, but I'm not sure if there
> will be anyone listening?

I am... ;-)

> I am returning to my project to implement a small CPU in an FPGA. I
> had looked at some of Jan Gray's work back in 2002 or so. I don't see
> where he has done anything on those CPUs since then. The gr0040 looks
> to be very interesting, but it appears that he has not released the
> tools he developed.
>
> I also found a tiny8 on opencores.org that looks interesting. Many of
> the projects there are very incomplete, some even have never produced
> a single document of any sort. Only a few have produced a working
> processor complete with tools.
>
> What small CPUs have people used in FGPAs? What do you use for tools?
> Has anyone found a usable CPU with tools that uses less than 500
> LUTs?

I developed my own 32 bit CPU "ECO32" together with a set of tools.
However, I'm not sure if that counts as 'small'... :-)

Briefly, the specs are:
MIPS-like instruction set, but without floating-point
hardware shift/multiply/divide unit
32 32-bit registers
32 bit virtual addressing
MMU with TLB support (32 entries, fully associative)
two CPU modes (kernel/user)
16 exceptions + 16 interrupts
occupies around 30% of a Spartan-3 XC3S1000 FPGA
runs at 50 MHz on an XESS XSA-3S1000 board
this board has 32 MByte SDRAM and 2 MByte Flash-ROM
Peripherals:
32-bit synchronous bus
Flash-ROM controller
SDRAM controller
(I used the one provided by Dave Vanden Bout from XESS)
timer
memory-mapped character display
keyboard
two serial lines
IDE disk
(the latter two interfaces provided by an extender
board XST-3, which also has ethernet and USB support
on it, but are not used by ECO32 yet)
Software:
assembler/linker
C compiler (LCC with ECO32 back-end)
machine monitor (running from Flash-ROM)

Furthermore, I have written a simulator for the whole system,
so that developing the software is a lot easier (in fact, I
started the project with the simulator; at that time I didn't
realize that it could eventually be built in hardware). We
use the simulator in compiler and operating system courses.

Right now I am porting an operating system (UNIX V7/32V) to
my machine. I am planning to have it finished next spring.
In fact this is my second attempt to do this - it's a lot
more work than I first anticipated.

The hole project including all tools is open source and can
be downloaded from

http://homepages.fh-giessen.de/~hg53/eco32/

(simulator, assembler/linker, FPGA implementation) and

http://homepages.fh-giessen.de/~hg53/eos32/

(C compiler, many ROMs with test programs, machine monitor).

Please feel free to ask any questions about the system; the
documentation is in a horrible state, I must confess...

Hellwig
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

It's a just a coincidence that the "The littlest CPU" thread on comp.arch.fpga touches on this very issue and offers an interesting candidate just under 500 LUT?

I know nothing of zpu, but I quote Henri:

Maybe something worth checking:

http://www.zylin.com/zpu.htm

From the above website:

1. The ZPU is now open source. See ZPU mailing list for more details.
2. BSD license for HDL implementations--no hiccups when using in
proprietary commercial products. Under the open source royalty free
license, there are no limits on what type of technology (FPGA,
anti-fuse, or ASIC) in which the ZPU can be implemented.
3. GPL license for architecture, documentation and tools
4. Completely FPGA brand and type neutral implementation
5. 298 LUT @ 125 MHz after P&R with 16 bit datapath and 4kBytes BRAM
6. 442 LUT @ 95 MHz after P&R with 32 bit datapath and 32kBytes BRAM
7. Codesize 80% of ARM thumb
8. Configurable 16/32 bit datapath
9. GCC toolchain(GDB, newlib, libstdc++)
10. Debugging via simulator or GDB stubs
11. HDL simulation feedback to simulator for powerful profiling
capabilities
12. Eclipse ZPU plug-in
13. eCos embedded operating system support.

Henri
--- On Thu, 7/31/08, Rick Collins wrote:

> From: Rick Collins
> Subject: [fpga-cpu] Small CPUs in FPGAs
> To: f...@yahoogroups.com
> Date: Thursday, July 31, 2008, 7:18 AM
> Hi,
>
> It looks like this group has been slumbering for a bit.
> This seems to
> be the ideal place to have my discussion, but I'm not
> sure if there
> will be anyone listening? I see that there are lots of
> members of
> this group, but not many postings.
>
> I am returning to my project to implement a small CPU in an
> FPGA. I
> had looked at some of Jan Gray's work back in 2002 or
> so. I don't see
> where he has done anything on those CPUs since then. The
> gr0040 looks
> to be very interesting, but it appears that he has not
> released the
> tools he developed.
>
> I also found a tiny8 on opencores.org that looks
> interesting. Many of
> the projects there are very incomplete, some even have
> never produced
> a single document of any sort. Only a few have produced a
> working
> processor complete with tools.
>
> What small CPUs have people used in FGPAs? What do you use
> for tools?
> Has anyone found a usable CPU with tools that uses less
> than 500 LUTs?
>
> Rick
> ------------------------------------
>
> To post a message, send it to: f...@yahoogroups.com
> To unsubscribe, send a blank message to:
> f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Something that came out of this group for me. It put me in contact with Martin and prompt to continue work on YARI, used in this research: http://www.vmars.tuwien.ac.at/php/pserver/extern/docdetail.php?DID=2431&viewmode=paper&year=2008

YARI (http://thorn.ws/yari) is a MIPS implementation (thus with a very mature GNU tool-chain) with very decent performance. Lots of effort has gone into avoiding pipeline stalls, including
# a 4-way associative instruction cache (default 8 KiB)
# a 4-way associative data cache (default 16 KiB)
# a store buffer

Fmax has only been a secondary goal to pipeline efficiency, but it does reach 80 MHz in a Altera Cyclone EP1C12C6. Size has been a non-concern, so the 5,500 - 7,000 LE for SoC puts it outside the realm of "small" I guess. (Well, it's very small compared to others projects of mine).

Released under GPL, so take a look. I'd appreciate all comments.

Cheers
Tommy

--- On Thu, 7/31/08, Rick Collins wrote:

> From: Rick Collins
> Subject: [fpga-cpu] Small CPUs in FPGAs
> To: f...@yahoogroups.com
> Date: Thursday, July 31, 2008, 7:18 AM
> Hi,
>
> It looks like this group has been slumbering for a bit.
> This seems to
> be the ideal place to have my discussion, but I'm not
> sure if there
> will be anyone listening? I see that there are lots of
> members of
> this group, but not many postings.
>
> I am returning to my project to implement a small CPU in an
> FPGA. I
> had looked at some of Jan Gray's work back in 2002 or
> so. I don't see
> where he has done anything on those CPUs since then. The
> gr0040 looks
> to be very interesting, but it appears that he has not
> released the
> tools he developed.
>
> I also found a tiny8 on opencores.org that looks
> interesting. Many of
> the projects there are very incomplete, some even have
> never produced
> a single document of any sort. Only a few have produced a
> working
> processor complete with tools.
>
> What small CPUs have people used in FGPAs? What do you use
> for tools?
> Has anyone found a usable CPU with tools that uses less
> than 500 LUTs?
>
> Rick
> ------------------------------------
>
> To post a message, send it to: f...@yahoogroups.com
> To unsubscribe, send a blank message to:
> f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, Hellwig Geisse
wrote:
>
> Hi Rick,
>
> On Thu, 2008-07-31 at 14:18 +0000, Rick Collins wrote:
>
> > It looks like this group has been slumbering for a bit. This seems to
> > be the ideal place to have my discussion, but I'm not sure if there
> > will be anyone listening?
>
> I am... ;-)
>
> > I am returning to my project to implement a small CPU in an FPGA. I
> > had looked at some of Jan Gray's work back in 2002 or so. I don't see
> > where he has done anything on those CPUs since then. The gr0040 looks
> > to be very interesting, but it appears that he has not released the
> > tools he developed.
> >
> > I also found a tiny8 on opencores.org that looks interesting. Many of
> > the projects there are very incomplete, some even have never produced
> > a single document of any sort. Only a few have produced a working
> > processor complete with tools.
> >
> > What small CPUs have people used in FGPAs? What do you use for tools?
> > Has anyone found a usable CPU with tools that uses less than 500
> > LUTs?
>
> I developed my own 32 bit CPU "ECO32" together with a set of tools.
> However, I'm not sure if that counts as 'small'... :-)
>
> Briefly, the specs are:
> MIPS-like instruction set, but without floating-point
> hardware shift/multiply/divide unit
> 32 32-bit registers
> 32 bit virtual addressing
> MMU with TLB support (32 entries, fully associative)
> two CPU modes (kernel/user)
> 16 exceptions + 16 interrupts
> occupies around 30% of a Spartan-3 XC3S1000 FPGA
> runs at 50 MHz on an XESS XSA-3S1000 board
> this board has 32 MByte SDRAM and 2 MByte Flash-ROM
> Peripherals:
> 32-bit synchronous bus
> Flash-ROM controller
> SDRAM controller
> (I used the one provided by Dave Vanden Bout from XESS)
> timer
> memory-mapped character display
> keyboard
> two serial lines
> IDE disk
> (the latter two interfaces provided by an extender
> board XST-3, which also has ethernet and USB support
> on it, but are not used by ECO32 yet)
> Software:
> assembler/linker
> C compiler (LCC with ECO32 back-end)
> machine monitor (running from Flash-ROM)
>
> Furthermore, I have written a simulator for the whole system,
> so that developing the software is a lot easier (in fact, I
> started the project with the simulator; at that time I didn't
> realize that it could eventually be built in hardware). We
> use the simulator in compiler and operating system courses.
>
> Right now I am porting an operating system (UNIX V7/32V) to
> my machine. I am planning to have it finished next spring.
> In fact this is my second attempt to do this - it's a lot
> more work than I first anticipated.
>
> The hole project including all tools is open source and can
> be downloaded from
>
> http://homepages.fh-giessen.de/~hg53/eco32/
>
> (simulator, assembler/linker, FPGA implementation) and
>
> http://homepages.fh-giessen.de/~hg53/eos32/
>
> (C compiler, many ROMs with test programs, machine monitor).
>
> Please feel free to ask any questions about the system; the
> documentation is in a horrible state, I must confess...

Thanks for the reply. This sounds like a pretty nice CPU. It is a
bit large for my needs since it is about 50% larger than the FPGA I
have to put it in... 8^*

But it does appear that you have done a lot with it. The
documentation is always the part that is left to the end and so gets
the short shrift.

If I ever need a more powerful processor in an FPGA, I'll know where
to look.

Thanks,
Rick
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Rick Collins wrote:
> Hi,
>
> It looks like this group has been slumbering for a bit. This seems to
> be the ideal place to have my discussion, but I'm not sure if there
> will be anyone listening? I see that there are lots of members of
> this group, but not many postings.
>
> I am returning to my project to implement a small CPU in an FPGA. I
> had looked at some of Jan Gray's work back in 2002 or so. I don't see
> where he has done anything on those CPUs since then. The gr0040 looks
> to be very interesting, but it appears that he has not released the
> tools he developed.
>
> I also found a tiny8 on opencores.org that looks interesting. Many of
> the projects there are very incomplete, some even have never produced
> a single document of any sort. Only a few have produced a working
> processor complete with tools.
>
> What small CPUs have people used in FGPAs? What do you use for tools?
> Has anyone found a usable CPU with tools that uses less than 500 LUTs?
>
> Rick
>
>
Well define small ... a PDP 8 is a small computer but I suspect
it is harder to fit than a RISC machine using the features of
modern FPGA's. Right now I am designing a 12/24 bit, bit slice computer
using 2901's , 512x8 proms and lots of LS chips. This is slowly
turing in to a PC clone - 1 meg of memory, XT connectors and
a bit faster. Since I don't have any way to program proms I am
having a 64 cell CPLD replace my proms. I plan to stick to TTL
& CPLD's since I don't need a serial configuration prom on boot
up.
Ben alias woodelf

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, Tommy Thorn wrote:
>
> It's a just a coincidence that the "The littlest CPU" thread on
comp.arch.fpga touches on this very issue and offers an interesting
candidate just under 500 LUT?

No coincidence. I am the OP of that thread. The ZPU looks good in
many ways, but it is very short of documentation. The Zylin web site
has virtually no info on it and directs you to the opencores.org site.
The project there has very little documentation and is hard to navigate.

I really like the <300 LUT implementation for the 16 bit data path
version. That would be very useful. I think the addressable program
space is a bit on the small side, but that might be expanded a bit (or
two).

I had started to look outside of the nearly hundred CPU projects on
opencores.org (most of which are not beyond the planning/alpha stage)
and thought I would ask here. There was an interesting lead at
fpgacpu.org, (gr0040), but that turned out to have a restrictive
license. I have sent an email asking about commercial use. We'll see
what comes back. He also has not released the tools for this
particular processor even though he made an LCC port.

Rick

> I know nothing of zpu, but I quote Henri:
>
> Maybe something worth checking:
>
> http://www.zylin.com/zpu.htm
>
> From the above website:
>
> 1. The ZPU is now open source. See ZPU mailing list for more
details.
> 2. BSD license for HDL implementations--no hiccups when using in
> proprietary commercial products. Under the open source royalty free
> license, there are no limits on what type of technology (FPGA,
> anti-fuse, or ASIC) in which the ZPU can be implemented.
> 3. GPL license for architecture, documentation and tools
> 4. Completely FPGA brand and type neutral implementation
> 5. 298 LUT @ 125 MHz after P&R with 16 bit datapath and 4kBytes BRAM
> 6. 442 LUT @ 95 MHz after P&R with 32 bit datapath and 32kBytes BRAM
> 7. Codesize 80% of ARM thumb
> 8. Configurable 16/32 bit datapath
> 9. GCC toolchain(GDB, newlib, libstdc++)
> 10. Debugging via simulator or GDB stubs
> 11. HDL simulation feedback to simulator for powerful profiling
> capabilities
> 12. Eclipse ZPU plug-in
> 13. eCos embedded operating system support.
>
> Henri

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Rick,

what exactly are your requirements/design goals
for that small CPU?

IMHO, this is the most important question. It is
not very difficult to design a small CPU and to
write the necessary tools, but only after it is
well understood what shall be achieved.

Hellwig
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Rick,

How you looked at Xilinx's implementation of a cpu in FPGA. ?

Yash

--- On Thu, 7/31/08, Rick Collins wrote:
From: Rick Collins
Subject: [fpga-cpu] Small CPUs in FPGAs
To: f...@yahoogroups.com
Date: Thursday, July 31, 2008, 7:18 AM

Hi,

It looks like this group has been slumbering for a bit. This seems to

be the ideal place to have my discussion, but I'm not sure if there

will be anyone listening? I see that there are lots of members of

this group, but not many postings.

I am returning to my project to implement a small CPU in an FPGA. I

had looked at some of Jan Gray's work back in 2002 or so. I don't see

where he has done anything on those CPUs since then. The gr0040 looks

to be very interesting, but it appears that he has not released the

tools he developed.

I also found a tiny8 on opencores.org that looks interesting. Many of

the projects there are very incomplete, some even have never produced

a single document of any sort. Only a few have produced a working

processor complete with tools.

What small CPUs have people used in FGPAs? What do you use for tools?

Has anyone found a usable CPU with tools that uses less than 500 LUTs?

Rick

[Non-text portions of this message have been removed]
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, Hellwig Geisse
wrote:
>
> Rick,
>
> what exactly are your requirements/design goals
> for that small CPU?
>
> IMHO, this is the most important question. It is
> not very difficult to design a small CPU and to
> write the necessary tools, but only after it is
> well understood what shall be achieved.

I am not asking anyone to design a CPU. I am asking what is currently
available.

My goal is for a CPU that occupies a small footprint in a modern FPGA.
The processor does not need to be 32 bits or even 16 bits. It should
be able to address a few kB of program storage and it would be nice if
it could utilize a similar data space, but I expect only 256 bytes
would actually be required. None of this should be hard as it does
not place many demands on the design other than the small footprint.

But the main difficulty I have found with available designs (including
my own) is the lack of supporting software and/or documentation. It
is fun to do the initial 10% of the work required to create a useful
CPU design. But the remaining 90% is hard work. If I knew that my
CPU was actually better than others available, I would work to
complete the software side of it. That is one reason why I am doing
this survey. I don't want to spend a lot of time creating yet another
soft CPU that the world doesn't need.

Rick
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, "Rick Collins" wrote:
>
> Hi,
>
> It looks like this group has been slumbering for a bit. This seems to
> be the ideal place to have my discussion, but I'm not sure if there
> will be anyone listening? I see that there are lots of members of
> this group, but not many postings.
>
> I am returning to my project to implement a small CPU in an FPGA. I
> had looked at some of Jan Gray's work back in 2002 or so. I don't see
> where he has done anything on those CPUs since then. The gr0040 looks
> to be very interesting, but it appears that he has not released the
> tools he developed.
>
> I also found a tiny8 on opencores.org that looks interesting. Many of
> the projects there are very incomplete, some even have never produced
> a single document of any sort. Only a few have produced a working
> processor complete with tools.
>
> What small CPUs have people used in FGPAs? What do you use for tools?
> Has anyone found a usable CPU with tools that uses less than 500
LUTs?
>
> Rick
>

The T80 core are opencores is a Z80 and there is a TON of
documentation and software for Z80's. I took that core, added a pair
of CF devices and implemented CP/M 2.2 with 16 logical 8 MB drives and
64K of RAM.

I don't know if it meets your size constraint - probably not. But it
does have a macro assembler, C, PL/I and Fortran as well as Turbo
Pascal and WordStar. The software is out there on the Internet and
writing the BIOS is straightforward. I used the pseudoSam debugger
software to bring the system up. It works very well and runs at 12
MHz because I was too lazy to try to figure out how fast it could
really go. I suspect it will run 25 MHz with no problem.

If you expect a C compiler to exist then you are stuck with fairly
high end processors. If you can get by with a macro assembler then
'gas' will work.

There are a lot of interesting, if obsolete, processors described in
"Computer Architecture" by Foster. The machine BLUE is about as
simple as it gets and could be implemented in a very small FPGA. It
has 16 instructions and addresses 4k of 16 bit words.

John Kent described a small processor on this forum a couple of months
ago. It seems pretty interesting.

John Kent also has a 6809 project on opencores named System09.

The MCPU project seems complete and will fit on a CPLD.

But fully documented, complete with software, processors that are
arbitrarily small are going to be a problem to find. You don't tend
to write C compilers for machines that don't have stacks and registers.

Richard

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, "rtstofer" wrote:
>
> The T80 core are opencores is a Z80 and there is a TON of
> documentation and software for Z80's. I took that core, added a pair
> of CF devices and implemented CP/M 2.2 with 16 logical 8 MB drives and
> 64K of RAM.
>
> I don't know if it meets your size constraint - probably not. But it
> does have a macro assembler, C, PL/I and Fortran as well as Turbo
> Pascal and WordStar. The software is out there on the Internet and
> writing the BIOS is straightforward. I used the pseudoSam debugger
> software to bring the system up. It works very well and runs at 12
> MHz because I was too lazy to try to figure out how fast it could
> really go. I suspect it will run 25 MHz with no problem.

I think I looked at this one. If it has the size listed, it was too
large. But many opencores projects don't discuss the size in the
FPGA. But a Z80 would be a good CPU to imbed in an FPGA. I think it
is just too complex to fit in a small space.
> If you expect a C compiler to exist then you are stuck with fairly
> high end processors. If you can get by with a macro assembler then
> 'gas' will work.

Who said anything about "C"??? C would be fine, but I actually prefer
Forth. If I find a CPU design that is otherwise suited to the
purpose, I will work on Forth for it.
> There are a lot of interesting, if obsolete, processors described in
> "Computer Architecture" by Foster. The machine BLUE is about as
> simple as it gets and could be implemented in a very small FPGA. It
> has 16 instructions and addresses 4k of 16 bit words.
>
> John Kent described a small processor on this forum a couple of months
> ago. It seems pretty interesting.

I didn't see that. I'll try searching the archives.
> John Kent also has a 6809 project on opencores named System09.

I saw that and it filled a Spartan 3S200! That is an order of
magnitude too large.
> The MCPU project seems complete and will fit on a CPLD.

I looked at that. But it is not really a CPU. It is more of a state
machine. I actually worked on one of those once. They used to make
microprogram sequencer chips that would execute a program, but you had
to add the ALU yourself. I was programming a DMA board that had a
hand full of counters and the sequencer would keep it all running at
top speed. That was the old days and this now would be a portion of
the DMA section of an MCU that costs $2.

> But fully documented, complete with software, processors that are
> arbitrarily small are going to be a problem to find. You don't tend
> to write C compilers for machines that don't have stacks and registers.

There are six that come close. Xilinx, Altera and Lattice all provide
two CPUs for their chips. One is a bit too large, but is supported
with compilers. The other is small, but no compiler. They are all
well documented.

There are OC projects that are small, but few are documented much and
even fewer have compilers. I did find a gr0040 by Jan Gray. It looks
like a very good design and it had a compiler written for it... but
Jan seems to have never made the tools public. Also, it may not be
suited for modern FPGAs and is only licensed for non-commercial use... :^(

I know that there are a lot of different CPUs out there. I know that
there won't be many that meet my requirements. But I won't know for
sure unless I look, eh? Before I spend a lot of time on a CPU
project, I wanted to do a thorough survey of the landscape.

Rick
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

> Who said anything about "C"??? C would be fine, but I actually prefer
> Forth. If I find a CPU design that is otherwise suited to the
> purpose, I will work on Forth for it.

If you want Forth, why not design a processor that handles it
directly? This would tend to be a stack machine and may not need any
registers other than a program counter. I have never implemented
Forth so I don't know if the processor would need sophisticated
operand addressing hardware (array elements?).

I played around with a processor to run the P-code from Wirth's
original P4 Pascal compiler. I got it running to the extent that the
next step was implementing the system calls and then put it on hold
for a while (think multiple years).

Richard

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Not my thing, but if you like Forth, you should check out b16 (http://www.jwdt.com/~paysan/b16.html) Very elegant and impressive IMO.

About 600 LCs in an Altera Flex10K30E, I wonder if that number has improved with a more recent FPGA and better synthesis tools.

Tommy

--- On Sat, 8/2/08, rtstofer wrote:

> From: rtstofer
> Subject: [fpga-cpu] Re: Small CPUs in FPGAs
> To: f...@yahoogroups.com
> Date: Saturday, August 2, 2008, 4:23 PM
> > Who said anything about "C"??? C would be
> fine, but I actually prefer
> > Forth. If I find a CPU design that is otherwise
> suited to the
> > purpose, I will work on Forth for it.
>
> If you want Forth, why not design a processor that handles
> it
> directly? This would tend to be a stack machine and may
> not need any
> registers other than a program counter. I have never
> implemented
> Forth so I don't know if the processor would need
> sophisticated
> operand addressing hardware (array elements?).
>
> I played around with a processor to run the P-code from
> Wirth's
> original P4 Pascal compiler. I got it running to the
> extent that the
> next step was implementing the system calls and then put it
> on hold
> for a while (think multiple years).
>
> Richard
>
> ------------------------------------
>
> To post a message, send it to: f...@yahoogroups.com
> To unsubscribe, send a blank message to:
> f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

On Thu, 31 Jul 2008 14:18:37 -0000, you wrote:

>I also found a tiny8 on opencores.org that looks interesting. Many of
>the projects there are very incomplete, some even have never produced
>a single document of any sort. Only a few have produced a working
>processor complete with tools.

The one recollection that sprung immediately to mind was the 6502
core. I recall working for a short time on a Seiko "message watch"
that required absolute miminum power requirements (watch battery
should last a couple of years) and that was pressed hard enough by the
fact that the watch's receiver drew power, when active, as well. So
they went to Western Digital for the ASIC. That was many years back,
but it suggests that experience and practice shows the 6502 can be
done with low resources.

A quick search turns up:
http://www.opencores.org/projects.cgi/web/cpu6502_true_cycle/overview
http://www.opencores.org/projects.cgi/web/t65/overview
http://www.opencores.org/people.cgi/info/jesus

The T65 one has been used in this webserver project:
http://www.fpgacircuit.com/pdf/webserver_manual.pdf

Also, the compiler toolset is at:
http://www.cc65.org/

Just a thought.

Jon

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, "rtstofer" wrote:
>
> > Who said anything about "C"??? C would be fine, but I actually prefer
> > Forth. If I find a CPU design that is otherwise suited to the
> > purpose, I will work on Forth for it.
>
> If you want Forth, why not design a processor that handles it
> directly? This would tend to be a stack machine and may not need any
> registers other than a program counter. I have never implemented
> Forth so I don't know if the processor would need sophisticated
> operand addressing hardware (array elements?).

I did, about four years ago. I thought I had mentioned that here. I
got it to a point where it ran and I used it in a small project. But
it takes a lot of work to develop the software to properly support it.
Even though it is built to run Forth, you still need a development
system.
> I played around with a processor to run the P-code from Wirth's
> original P4 Pascal compiler. I got it running to the extent that the
> next step was implementing the system calls and then put it on hold
> for a while (think multiple years).

I thought there was a CPU to run P-code directly. It was based on the
LSI-11 and used different microcode. That machine had a board or
maybe two boards for a CPU and the microcode was a custom 40 pin chip.
I seem to recall that one of the later versions of a PDP or LSI-11
used a writable control store for the microcode. Those were expensive
machines back then. I paid $3000 for the Heathkit version of the
LSI-11 computer. Then I paid another $1000 to add a pair of floppy
disks to it... 8" floppy disks.

Anyway, a CPU for internal use in an FPGA is a very different matter.
To Tommy Thorn,

I have looked at the B16. In fact, I learned quite a bit from that
which I used when designing my own CPU. But 600 LUTs is not all that
small. That is what my CPU was without optimization. The smaller
CPUs from the FPGA vendors push down to 250 or so LUTs. I don't know
how well they will run Forth, but I will be taking a harder look.

On the other hand, I don't have a problem using C either. I just am
looking to see what is available and it would be nice to have as much
existing support as possible.

Rick
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Hi Rick,

Rick Collins wrote:
>
>> John Kent also has a 6809 project on opencores named System09.
>>
>
> I saw that and it filled a Spartan 3S200! That is an order of
> magnitude too large.
>
That includes VDU, UART, PS2 Keyboard etc as well as the CPU.
The 6809 runs the Flex disk operating system out of Compact Flash,
and there are plenty of tools for it that will run on the processor it's
self.

I have a couple of small Microprocessors on my web site.
There is the Micro8 and Micro8a and there is the Micro16 and Micro16b

Micro8 does not have a stack, so does not have subroutine calls.
Micro8a does have a 256 byte stack, but only for return addresses.
Micro16 has a 8 level hardware stack.
Micro16b has a 256 byte software stack, again primarily for return
addresses.

I had planned to turn the Micro16b into a micro DSP by including a
multiply instruction. The idea was to use an array of Micro16b cores
as a processing array.

I used Doug Jones SMAL32 macro assembler to assemble code.
It's pretty rough and ready I must admit.

Micro16 and Micro16b are here:
http://members.optusnet.com.au/jekent/Micro16/index.html

Micro8 is here:
http://members.optusnet.com.au/jekent/Micro8/Micro8.html

Micro8a is here:
http://members.optusnet.com.au/jekent/Micro8/Micro8a.html

The other processors you might consider are:
PIC16F84 core - on opencores.org - Giving the privative instruction set
of the PIC, the core can't be that big.

68HC05 core - I was working on System05, but I never finished it.
I noticed someone else has completed a a HC05 core as well as a HC08 core.
The HC05 is much along the lines of the 6800, but only has an 8 bit
accumulator and 8 bit index register so is much smaller than te 6800/6809.
You can buy development systems including C for these processors.

System68 - the 6800/6801 core is about half the size of the 6809
and can Run Flex2 in theory, but still may be too big for you application.

PicoBlaze - Xilinx's offering. - I'm not sure what tools are available
for it
but I assume Xilinx are at least offering an assembler

A Forth processor is probably the way to go
Other than the Forth CPU's already mentioned, there is the K Ring
Technologies indi16
http://indi.hpsdr.com/

Hope that helps.

John.

--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Rick,

Just a further aside on the Micro16b. The Micro16 has a scalable address
bus. It should also be possible to scale the data bus width.

All instructions are only 1 word long. The opcode field is 4 bits wide,
3 bits for the opcode and 1 bit for indirect addressing. This leaves 12
bits on a 16 bit wide processor for direct addressing (ie 4K words)
however using indirect addressing you can addressing you can access 64
KWords.

In theory you could reduce the data width down to 8 bits, but that would
only give you 4 bits or 16 bytes / page of memory and would only address
256 bytes of memory. I'm not sure if code executes over page boundaries
but it might. Direct jumps are within the current program page I think.
The design could probably do with some page registers so you can access
data in different pages to the program code. Also the CPU needs to be
square. i.e. the address bus must be equal to or less than the data bus
width so that addresses can fit in one word of memory.

In my current design, I think my stack is restricted to the bottom 256
words of memory, but perhaps that should be located in the second page
(page 1) of memory leaving the bottom page (page 0) for direct and
indirect data words.

A more practical arrangement to reduce the size of the CPU would be to
use a 12 bit data bus, akin to the PDP-8. In that way you would have 16
x 256 word pages of memory, and would use 3 x 16Kbit block RAMs
configured as 4K x 4 bits. Certainly an 8 bit data bus is possible, but
the design might need modification to handle the limited amount of memory.

John.

John Kent wrote:
> Hi Rick,
>
>
> Micro16 and Micro16b are here:
> http://members.optusnet.com.au/jekent/Micro16/index.html
>

--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

John Kent wrote:
> A Forth processor is probably the way to go
> Other than the Forth CPU's already mentioned, there is the K Ring
> Technologies indi16
> http://indi.hpsdr.com/
>
>
Don't forget the The Ultimate RISC here:
http://www.cs.uiowa.edu/~jones/arch/risc/
and of course the Minimal CISC
http://www.cs.uiowa.edu/~jones/arch/cisc/
I suspect this is good definition of a small cpu.
> Hope that helps.
>
> John.
>
>
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

> I have looked at the B16. In fact, I learned quite a bit
> from that which I used when designing my own CPU. But 600 LUTs is
> not all that small. That is what my CPU was without optimization. The
> smaller CPUs from the FPGA vendors push down to 250 or so LUTs. I
> don't know how well they will run Forth, but I will be taking a harder
> look.

Again, I don't share this obsession, but note for the record that b16-small is half the size.

IMO life is too short for a core that my existing body of C code can't be trivially recompiled for. I need a 32-bit core without random limits.

Tommy

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Tommy Thorn wrote:
>> I have looked at the B16. In fact, I learned quite a bit
>> from that which I used when designing my own CPU. But 600 LUTs is
>> not all that small. That is what my CPU was without optimization. The
>> smaller CPUs from the FPGA vendors push down to 250 or so LUTs. I
>> don't know how well they will run Forth, but I will be taking a harder
>> look.
>>
>
> Again, I don't share this obsession, but note for the record that b16-small is half the size.
>
> IMO life is too short for a core that my existing body of C code can't be trivially recompiled for. I need a 32-bit core without random limits.
>
>
Well it is too bad that you seem to need 32+ megabyte of memory nowdays
just to
compile C code. Well you get what you pay for as I expect two thirds of
the LUT's
will be data path, and the rest for control of any cpu. You want 32 bit
cpu expect a good
chunk of LUTS.
> Tommy
>
>
>
>
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Ben Franchuk wrote:
>> You want 32 bit cpu expect a good chunk of LUTS.

Using the GR0040/GR1040 (same basic design but w/ instruction-register
pipeline register after ifetch), the 32-bits versions (GR0050/1050) were
<500 LUTs, if I recall correctly, and were designed to be a C compiler
target.

Cheers.
Jan Gray

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, "Jan Gray" wrote:
>
> Ben Franchuk wrote:
> >> You want 32 bit cpu expect a good chunk of LUTS.
>
> Using the GR0040/GR1040 (same basic design but w/ instruction-register
> pipeline register after ifetch), the 32-bits versions (GR0050/1050) were
> <500 LUTs, if I recall correctly, and were designed to be a C compiler
> target.

Hi Jan,

I am interested in the gr0040 and the the others, but there are two
issues. One is that the license does not allow commercial use. The
other is that except for the gr0040 I can't find info on them. The
gr0040 doesn't have the assembler available. I think your web site
says you developed one, but it isn't posted.

I would be interested in testing out a 32 bit processor that only uses
500 LUTs. But is this measured while using T-bufs which are no longer
supported in FPGAs? I think the info on the xr16 indicates the use of
T-bufs, but I don't recall details on the gr0040 and no info on the
others.

Rick
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Jan Gray wrote:
> Ben Franchuk wrote:
>
>>> You want 32 bit cpu expect a good chunk of LUTS.
>>>
>
> Using the GR0040/GR1040 (same basic design but w/ instruction-register
> pipeline register after ifetch), the 32-bits versions (GR0050/1050) were
> <500 LUTs, if I recall correctly, and were designed to be a C compiler
> target.
>
>
How ever I differ with your view point of just what a LUT is.
With out the 16x1 block ram ( and fast ripple carry ) just how
large would a RISC machine be. For using the hardware
your designs can't be beat, but I always tend to be with the
OTHER guy FPGA's. Right now I tend to favor CPLD's
as they seem to be hobbiest friendly, rather than everything
in unmanagable packinging or requiring $$$ for Verlog or VHTL
compilers.
> Cheers.
> Jan Gray
>
>
PS. I am also not a fan of using internal block ram
as main memory ... It kind of defeats the purpose of
having a general purpose CPU any more.
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

> Right now I tend to favor CPLD's
> as they seem to be hobbiest friendly, rather than everything
> in unmanagable packinging or requiring $$$ for Verlog or VHTL
> compilers.

Both Altera and Xilinx provide FREE Verilog and VHDL development
environments. Sure, they lack some of the high end features of the
retail versions but, for a fact, the Xilinx package works well.

> PS. I am also not a fan of using internal block ram
> as main memory ... It kind of defeats the purpose of
> having a general purpose CPU any more.
>

If the BlockRAM is large enough, why not use it? I have a 16 bit
minicomputer (retro) that uses 16k words of BlockRAM for central
memory as well as VGA memory for a 80x25 text display.

Richard

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

I'm not sure what Rick's requirements are, but the discussion prompted
me to revisit my minimal Micro16 design.

The design resembles in many ways the PDP-8, with a 3 bit op code and an
indirect bit, but I have extended the design to include a multiply, a
skip on condition with 16 conditional tests and a jump instruction
rather than two conditional jumps. I also extended the ALU to include 12
shift and complement operators on the Accumulator in addition to the 4
exiting NOR, ADD, MUL and STA operations and added push and pull
instructions as well as software interrupts.

I also made the data width of the design scalable, from 8 bits to 32
bits. The design is essentially square with the address bus width being
the same as the data bus width although you can shortened the address
bus by a couple of bits if desired.

I did a few synthesis's of the CPU design with Xilinx ISE 7.1 for a
XC3S200 with different address and data width sizes to see what the
resource utilization was like. I tested the design for 8 bit, 12 bit, 16
bit, 24 bit and 32bit address and data busses. I got an average overhead
of about 5,000 gates with 200 gates / bit. This implies about 44% fixed
overhead for a 32 bit CPU.

When I looked at the LUTs and Slice Flip Flops I got an over head of
138.5 (4 input) LUTS and 32.5 Slice Flip flops and per bit I got 21.125
LUTs and 5.625 Slice FFs. This implies only a 20% overhead for a 32 bit
CPU, so I'm not too sure what to make of the ISE report figures, but on
average it's probably not far from what bfranchuk (woodelf?) was saying
about 2/3 data path and 1/3 control.

John.

--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

> How ever I differ with your view point of just what a LUT is.

Well, these are Virtex-era LUTs, not XC4000-era LUTs. No H-LUTs are assumed
or harmed. We do use all the carry-logic, MULT_ANDs, etc. that we can, esp.
to build functions like

MUX(A,B+C)
or
MUX4(A+B,A-B,A&B,A^B)

in one column of LUTs (1 LUT per bit).

No TBUFs (alas).

I'm sorry I'm about to be away from the computer for two days but have fun
with the discussion thread.

Jan.

-----Original Message-----
From: f...@yahoogroups.com [mailto:f...@yahoogroups.com] On Behalf
Of b...@jetnet.ab.ca
Sent: Sunday, August 03, 2008 11:52 PM
To: f...@yahoogroups.com
Subject: Re: [fpga-cpu] Re: Small CPUs in FPGAs

Jan Gray wrote:
> Ben Franchuk wrote:
>
>>> You want 32 bit cpu expect a good chunk of LUTS.
>>>
>
> Using the GR0040/GR1040 (same basic design but w/ instruction-register
> pipeline register after ifetch), the 32-bits versions (GR0050/1050) were
> <500 LUTs, if I recall correctly, and were designed to be a C compiler
> target.
>
>
With out the 16x1 block ram ( and fast ripple carry ) just how
large would a RISC machine be. For using the hardware
your designs can't be beat, but I always tend to be with the
OTHER guy FPGA's. Right now I tend to favor CPLD's
as they seem to be hobbiest friendly, rather than everything
in unmanagable packinging or requiring $$$ for Verlog or VHTL
compilers.
> Cheers.
> Jan Gray
>
>
PS. I am also not a fan of using internal block ram
as main memory ... It kind of defeats the purpose of
having a general purpose CPU any more.
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to:
f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, "rtstofer" wrote:
> > Right now I tend to favor CPLD's
> > as they seem to be hobbiest friendly, rather than everything
> > in unmanagable packinging or requiring $$$ for Verlog or VHTL
> > compilers.
>
> Both Altera and Xilinx provide FREE Verilog and VHDL development
> environments. Sure, they lack some of the high end features of the
> retail versions but, for a fact, the Xilinx package works well.

The synthesis may work ok, but the Xilinx simulator is not very good
these days. It was a long time ago that Xilinx decided to roll their
own synthesis and they have had a chance to tune it pretty well for
their chips. But the simulator is still rather new and full of
"issues", not to mention rather slow. Interesting that the speed
crippled versions of other tools run about the same speed or faster
than the Xilinx in-house tool.
> > PS. I am also not a fan of using internal block ram
> > as main memory ... It kind of defeats the purpose of
> > having a general purpose CPU any more.
> > If the BlockRAM is large enough, why not use it? I have a 16 bit
> minicomputer (retro) that uses 16k words of BlockRAM for central
> memory as well as VGA memory for a 80x25 text display.

I think bfranchuk was saying that he wants a full CPU will plenty of
external memory. That does not fit my needs at all since I am trying
to fit this into existing designs using only internal resources.

Rick
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, John Kent wrote:
>
> I'm not sure what Rick's requirements are, but the discussion prompted
> me to revisit my minimal Micro16 design.

Earlier I mentioned designs that used only 250 or so LUTs. I also
said that a design with 1000's of LUTs is too large. I have rolled my
own 16 bit CPU that uses around 600 LUTs. So far the really small
CPUs are *very* limited and are only supported with an assembler. To
get HLL support the designs get over 1000 LUTs.
> The design resembles in many ways the PDP-8, with a 3 bit op code
and an
> indirect bit, but I have extended the design to include a multiply, a
> skip on condition with 16 conditional tests and a jump instruction
> rather than two conditional jumps. I also extended the ALU to
include 12
> shift and complement operators on the Accumulator in addition to the 4
> exiting NOR, ADD, MUL and STA operations and added push and pull
> instructions as well as software interrupts.
>
> I also made the data width of the design scalable, from 8 bits to 32
> bits. The design is essentially square with the address bus width being
> the same as the data bus width although you can shortened the address
> bus by a couple of bits if desired.
>
> I did a few synthesis's of the CPU design with Xilinx ISE 7.1 for a
> XC3S200 with different address and data width sizes to see what the
> resource utilization was like. I tested the design for 8 bit, 12
bit, 16
> bit, 24 bit and 32bit address and data busses. I got an average
overhead
> of about 5,000 gates with 200 gates / bit. This implies about 44% fixed
> overhead for a 32 bit CPU.

I have no understanding of how you measured gates or how that would be
used to evaluate a design. The only common denominator for use in
FPGAs is the 4 input LUT. Register usage is typically much less than
LUTs so for the most part it is not important to consider registers.
> When I looked at the LUTs and Slice Flip Flops I got an over head of
> 138.5 (4 input) LUTS and 32.5 Slice Flip flops and per bit I got 21.125
> LUTs and 5.625 Slice FFs. This implies only a 20% overhead for a 32 bit
> CPU, so I'm not too sure what to make of the ISE report figures, but on
> average it's probably not far from what bfranchuk (woodelf?) was saying
> about 2/3 data path and 1/3 control.

It sounds like you are using Xilinx devices. When you count LUTs, are
you counting *all* LUTs or just the ones reported by Xilinx tools as 4
input LUTs? For whatever reason, they break LUTs into separate counts
of 4 input LUTs, 3 input LUTs and several types of LUT based RAM. The
true count of LUTs is the sum of all these.

If I understand your numbers, a 16 bit design uses 168.5 LUTs and a 32
bit design uses 1,178.5 LUTS. I assume the fractional LUT counts were
obtained by generating two designs and projecting a straight line
through them. Have you tried this a third number of bits, say 8, 16
and 32 bits? I would be interested in seeing how the size ranges and
if it still fits the projection.

Rick
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, "Jan Gray" wrote:
>
> > How ever I differ with your view point of just what a LUT is.
>
> Well, these are Virtex-era LUTs, not XC4000-era LUTs. No H-LUTs are
assumed
> or harmed. We do use all the carry-logic, MULT_ANDs, etc. that we
can, esp.
> to build functions like
>
> MUX(A,B+C)
> or
> MUX4(A+B,A-B,A&B,A^B)
>
> in one column of LUTs (1 LUT per bit).
>
> No TBUFs (alas).
>
> I'm sorry I'm about to be away from the computer for two days but
have fun
> with the discussion thread.

Yes, today's FPGAs no longer include T-bufs so multiplexers have to be
used increasing the LUT count.

Jan, are you willing to release these designs for use in commercial
apps? I have tried to contact you here and I did not get a reply.
Except for the use of T-bufs, your designs appear to be the best
available in terms of performance for a small size. I would like to
know more, but my application is commercial. Should I stop
considering your designs or will I be able to get permission to use them?

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Rick,

This is the device utilization summary for Webpack ISE 7.1 for different
size address and data bus widths of my CPU. It only mentions slices and
4 input LUTs. It's probably not that different from what you have rolled
yourself already.

8 Bit Address and Data:

Device utilization summary:
---------------------------

Selected Device : 3s200ft256-4

Number of Slices: 178 out of 1920 9%
Number of Slice Flip Flops: 74 out of 3840 1%
Number of 4 input LUTs: 328 out of 3840 8%
Number of bonded IOBs: 33 out of 173 19%
Number of MULT18X18s: 1 out of 12 8%
Number of GCLKs: 1 out of 8 12%

12 Bit Address and Data

Device utilization summary:
---------------------------

Selected Device : 3s200ft256-4

Number of Slices: 217 out of 1920 11%
Number of Slice Flip Flops: 99 out of 3840 2%
Number of 4 input LUTs: 402 out of 3840 10%
Number of bonded IOBs: 45 out of 173 26%
Number of MULT18X18s: 1 out of 12 8%
Number of GCLKs: 1 out of 8 12%

16 Bit Address and Data bus

Device utilization summary:
---------------------------

Selected Device : 3s200ft256-4

Number of Slices: 255 out of 1920 13%
Number of Slice Flip Flops: 124 out of 3840 3%
Number of 4 input LUTs: 475 out of 3840 12%
Number of bonded IOBs: 57 out of 173 32%
Number of MULT18X18s: 1 out of 12 8%
Number of GCLKs: 1 out of 8 12%

24 Bit Address and Data

Device utilization summary:
---------------------------

Selected Device : 3s200ft256-4

Number of Slices: 368 out of 1920 19%
Number of Slice Flip Flops: 160 out of 3840 4%
Number of 4 input LUTs: 672 out of 3840 17%
Number of bonded IOBs: 81 out of 173 46%
Number of MULT18X18s: 1 out of 12 8%
Number of GCLKs: 1 out of 8 12%

32 Bit Address and Data

Device utilization summary:
---------------------------

Selected Device : 3s200ft256-4

Number of Slices: 484 out of 1920 25%
Number of Slice Flip Flops: 208 out of 3840 5%
Number of 4 input LUTs: 887 out of 3840 23%
Number of bonded IOBs: 105 out of 173 60%
Number of MULT18X18s: 1 out of 12 8%
Number of GCLKs: 1 out of 8 12%
Rick Collins wrote:
> --- In f...@yahoogroups.com, John Kent wrote:
>
> Earlier I mentioned designs that used only 250 or so LUTs. I also
> said that a design with 1000's of LUTs is too large. I have rolled my
> own 16 bit CPU that uses around 600 LUTs. So far the really small
> CPUs are *very* limited and are only supported with an assembler. To
> get HLL support the designs get over 1000 LUTs.
>
>
I guess that is the trade off you have to make then. What I have done is
use Douglas Jones Smal32 macro assembler and simply generated the
instructions in 32 bit words shifted up by the appropriate data bus
width. I need to write a Block RAM generator that can split the 32 bit
Smal32 file into nibbles or bytes. Obviously there is no high level
support. The easiest approach to software development would be to write
a virtual machine for Forth or P Code. I remember back in the dim dark
ages of implementing FIG Forth on the 6800. The virtual machine was only
1 KByte in size, so using a VM approach allows you to lever off a lot of
development work.

> I have no understanding of how you measured gates or how that would be
> used to evaluate a design. The only common denominator for use in
> FPGAs is the 4 input LUT. Register usage is typically much less than
> LUTs so for the most part it is not important to consider registers.
>
>
It was just taken from the Synthesis report that ISE spat out. The
report also gave a estimate of gate count.

>
>> When I looked at the LUTs and Slice Flip Flops I got an over head of
>> 138.5 (4 input) LUTS and 32.5 Slice Flip flops and per bit I got 21.125
>> LUTs and 5.625 Slice FFs. This implies only a 20% overhead for a 32 bit
>> CPU, so I'm not too sure what to make of the ISE report figures, but on
>> average it's probably not far from what bfranchuk (woodelf?) was saying
>> about 2/3 data path and 1/3 control.
>>
>
> It sounds like you are using Xilinx devices. When you count LUTs, are
> you counting *all* LUTs or just the ones reported by Xilinx tools as 4
> input LUTs? For whatever reason, they break LUTs into separate counts
> of 4 input LUTs, 3 input LUTs and several types of LUT based RAM. The
> true count of LUTs is the sum of all these.
>
>
OK ... I'm not sure how Xilinx reports the use of 3 input LUTs and RAM
LUTs. I've just included a summary of the utilization above ...that
might not be enough.

> If I understand your numbers, a 16 bit design uses 168.5 LUTs and a 32
> bit design uses 1,178.5 LUTS. I assume the fractional LUT counts were
> obtained by generating two designs and projecting a straight line
> through them. Have you tried this a third number of bits, say 8, 16
> and 32 bits? I would be interested in seeing how the size ranges and
> if it still fits the projection.
>
>
I'm not sure how you get those figures:
138.5 LUTs + (21.125 * No. of Bits)

16 bits => 476.5 LUTs
32 bits => 814.5 LUTs

The fractional counts resulted from average the the 5 versions of the
design - 8 bit, 12 bit, 16 bit, 24 bit and 32 bit.
I worked out the difference in the number of slices and divided that by
the difference in the number of bits to get a Slices per bit count.
Interpolating that you can work out the fixed overhead of the design.

Anyway ... I've spent enough time on this project ... I'll leave you to
sort out you problems. My design is not really a commercial design in
that it has not undergone rigorous testing. I was essentially verifying
Woodelf's assertion of 2/3 utilization for data path and 1/3 for
control, but it depends very much on the design and the number of bits.

John.

--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent

[Non-text portions of this message have been removed]
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Rick,

Do you really think there is a market for a cross platform processor
core ? I have not looked at the JOP, Java Oriented Processor, but if
that can support C as well as Java, that might be the way to go. I'm not
sure how scalable that design is or what software has been developed for
it. I was looking at a stack based design. It's probably not as
efficient in speed as a pipelined register based general RISC
architecture, but it might be more efficient from an FPGA resource point
of view.

John.

--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

> Do you really think there is a market for a cross platform processor
> core ? I have not looked at the JOP, Java Oriented Processor, but if
> that can support C as well as Java, that might be the way to go. I'm not

JOP executes Java bytecodes only, not C. There have been projects
that try to compile C to Java bytecode, but I don't know how
effective this is.

> sure how scalable that design is or what software has been developed for

What do you mean by scalable? With respect to SW: there are a few
industrial applications written for JOP and in use. Nothing big,
very control oriented.

> it. I was looking at a stack based design. It's probably not as
> efficient in speed as a pipelined register based general RISC
> architecture, but it might be more efficient from an FPGA resource point
> of view.

The stack based drawbacks are well known. The main benefit of a stack
with two explicite TOS and NOS registers is that you can merge EX and
WB into a single pipeline stage. You need no forwarding at all :-)

Martin

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Rick Collins wrote
>Earlier I mentioned designs that used only 250 or so LUTs. I also
>said that a design with 1000's of LUTs is too large. I have rolled my
>own 16 bit CPU that uses around 600 LUTs. So far the really small
>CPUs are *very* limited and are only supported with an assembler. To
>get HLL support the designs get over 1000 LUTs.

Thanks for the gauntlet :-)

Well, I went for a dig in my deep archive and found the following.
Not available for commercial use (sorry Rick), but another example
of what can be done.

The Risc4005 is now 17 years old. It was designed prior to the first
commercial release of the Xilinx XC4000 family, and fitted into the
first product the XC4005. A 14 by 14 array of CLBs, each with 2 4-luts,
2 FFs, 2 TBUFs, and 2 bits of carry chain.

Here is the PPR report:

Partitioned Design Utilization Using Part 4005PG156-5
No. Used Max Available % Used
---------------------------- ------- ------------- ------
Occupied CLBs 155 196 79%
Packed CLBs 130 196 66%
---------------------------- ------- ------------- ------
Bonded I/O Pins: 81 112 72%
F and G Function Generators: 261 392 66%
H Function Generators: 27 196 13%
CLB Flip Flops: 196 392 50%
IOB Input Flip Flops: 4 112 3%
IOB Output Flip Flops: 48 112 42%
Memory Write Controls: 16 196 8%
3-State Buffers: 144 448 32%
3-State Half Longlines: 32 56 57%
Edge Decode Inputs: 12 168 7%
Edge Decode Half Longlines: 2 32 6%
Software for the Risc4005 included a cross assembled with very fancy
macro capability, and a C compiler, which was a port of LCC. The
compiler port took me about 2 or 3 days. What was missing was a
relocateable binary format, and a linker/librarian. That didn't stop me
from compiling and running C programs. Linking was done at compile time
with #includes of source files. Not pretty, but it worked.
>From 2001, I wrote the following (with a few edits):
===================
For those of you who don't know,
the RISC4005 was designed in 1991, and fitted into about 140
CLBs in the original 4005 (no dual port RAM or Sync RAM write
in those days). So, about 260 LUTs/FFs. Ran at 20MHz in 1991
vintage technology. I would expect that it would run at 200+ MHz
in current technology (16 bit ALU, 4 deep pipeline, reg forwarding,
2 delay slots on branch, 1 on mem read).

Jan and I have become very good friends, and it started when
he worked on the precursor to the XR16. The similarities between
the architecture that he developed and the RISC4005 were
extensive, and allowed for significant transfer of info in both
directions.

But, Jan took his design far further than I did. He fleshed out the
C compiler, and added a nice simulator. His articles in Circuit Cellar
INK, and the forming of this news group, together with his web site
demonstrate an energy and enthusiasm far beyond my burnt out
condition on this subject. While I might have the stripes for the
first CPU implemented in an FPGA, Jan's work is I believe far more
significant. Thanks for keeping the flame burning Jan.

I was going to write a paragraph or two on microblaze, but I came
to my senses.
===================
And to my surprise, my design got mentioned in the August 2008
issue of Circuit Cellar magazine, in an article by Tom Cantrell :-)
(I bet I now owe him a dinner and a beer)
Cheers,
Philip
=================
Philip Freidin
p...@fliptronics.com

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, Philip Freidin wrote:
> Thanks for the gauntlet :-)
>
> Well, I went for a dig in my deep archive and found the following.
> Not available for commercial use (sorry Rick), but another example
> of what can be done.
>
> The Risc4005 is now 17 years old. It was designed prior to the first
> commercial release of the Xilinx XC4000 family, and fitted into the
> first product the XC4005. A 14 by 14 array of CLBs, each with 2 4-luts,
> 2 FFs, 2 TBUFs, and 2 bits of carry chain.
>
> Here is the PPR report:
>
> Partitioned Design Utilization Using Part 4005PG156-5
> No. Used Max Available % Used
> ---------------------------- ------- ------------- ------
> Occupied CLBs 155 196 79%
> Packed CLBs 130 196 66%
> ---------------------------- ------- ------------- ------
> Bonded I/O Pins: 81 112 72%
> F and G Function Generators: 261 392 66%
> H Function Generators: 27 196 13%
> CLB Flip Flops: 196 392 50%
> IOB Input Flip Flops: 4 112 3%
> IOB Output Flip Flops: 48 112 42%
> Memory Write Controls: 16 196 8%
> 3-State Buffers: 144 448 32%
> 3-State Half Longlines: 32 56 57%
> Edge Decode Inputs: 12 168 7%
> Edge Decode Half Longlines: 2 32 6%
> Software for the Risc4005 included a cross assembled with very fancy
> macro capability, and a C compiler, which was a port of LCC. The
> compiler port took me about 2 or 3 days. What was missing was a
> relocateable binary format, and a linker/librarian. That didn't stop me
> from compiling and running C programs. Linking was done at compile time
> with #includes of source files. Not pretty, but it worked.
> From 2001, I wrote the following (with a few edits):
> ===================
> For those of you who don't know,
> the RISC4005 was designed in 1991, and fitted into about 140
> CLBs in the original 4005 (no dual port RAM or Sync RAM write
> in those days). So, about 260 LUTs/FFs. Ran at 20MHz in 1991
> vintage technology. I would expect that it would run at 200+ MHz
> in current technology (16 bit ALU, 4 deep pipeline, reg forwarding,
> 2 delay slots on branch, 1 on mem read).
>
> Jan and I have become very good friends, and it started when
> he worked on the precursor to the XR16. The similarities between
> the architecture that he developed and the RISC4005 were
> extensive, and allowed for significant transfer of info in both
> directions.
>
> But, Jan took his design far further than I did. He fleshed out the
> C compiler, and added a nice simulator. His articles in Circuit Cellar
> INK, and the forming of this news group, together with his web site
> demonstrate an energy and enthusiasm far beyond my burnt out
> condition on this subject. While I might have the stripes for the
> first CPU implemented in an FPGA, Jan's work is I believe far more
> significant. Thanks for keeping the flame burning Jan.
>
> I was going to write a paragraph or two on microblaze, but I came
> to my senses.
> ===================
> And to my surprise, my design got mentioned in the August 2008
> issue of Circuit Cellar magazine, in an article by Tom Cantrell :-)
> (I bet I now owe him a dinner and a beer)
> Cheers,
> Philip
> =================
> Philip Freidin
> philip@...
>

Philip,

I wandered around your web site this morning looking for the RISC4005
project but didn't see it. Is there a link?

Richard

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Hi Martin,

Martin Schoeberl wrote:
> What do you mean by scalable? With respect to SW: there are a few
> industrial applications written for JOP and in use. Nothing big,
> very control oriented.
>
>
I was wondering how a stack oriented machine would handle multitasking ...
Saving the context of the machine and restoring it.
I'm inclined to think you'd need a supervisory state like the 68000 to
support the swapping of TOS, NOS, FP, SP and so on.
> The stack based drawbacks are well known. The main benefit of a stack
> with two explicite TOS and NOS registers is that you can merge EX and
> WB into a single pipeline stage. You need no forwarding at all :-)
>
> Martin
I was thinking of using the argument and local variable stack for
working space, but using the same stack for work space would preclude
the allocation of new local variables, which may be needed in languages
like C++. Pascal scoping rules mean that all variables are effectively
created on the stack, (there is the concept of a heap in Pacal too isn't
there ?). I assume Java is the same. C and C++ have global or static
variable space as well as arguments and local variables, which are
normally referenced above or below a frame pointer.

HP and TI calculators had a 4 level stack. Is it possible to entirely
evaluate an expression with only 4 stack entries ? I would suspect not,
but if it was possible, then you could possibly implement a hardware
working stack as well as have a common pointer and stack and frame
pointer for global and local variables.

I might be showing my ignorance .... sorry.

John.

--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Hi Philip,

We, well my boss, at the CSIRO used a couple of XC4005s and XC4008s in
his CLP board back in the mid 90's.
I'm not sure how much the chips were, but I recall them being in the
$1,000 price mark in Australia.

John.

Philip Freidin wrote:
>
> Thanks for the gauntlet :-)
>
> Well, I went for a dig in my deep archive and found the following.
> Not available for commercial use (sorry Rick), but another example
> of what can be done.
>
> The Risc4005 is now 17 years old. It was designed prior to the first
> commercial release of the Xilinx XC4000 family, and fitted into the
> first product the XC4005. A 14 by 14 array of CLBs, each with 2 4-luts,
> 2 FFs, 2 TBUFs, and 2 bits of carry chain.
>

--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

> I was wondering how a stack oriented machine would handle
multitasking ...
> Saving the context of the machine and restoring it.
> I'm inclined to think you'd need a supervisory state like the 68000 to
> support the swapping of TOS, NOS, FP, SP and so on.

The ARM processors have multiple stacks. One drawback is that they
are of fixed size and statically allocated at startup. An RTOS like
FreeRTOS uses fixed size task stacks.

I don't see why a memory management unit couldn't solve the whole
problem. Memory for stacks could be dynamically allocated in
relatively small chunks. There would need to be some kind of page
fault detection. Presumably the system level stacks would be large
enough to prevent faults during hardware interrupts.

How did Burroughs handle stacks in their Algol machines such as the
B5000? http://en.wikipedia.org/wiki/Burroughs_large_systems

> I was thinking of using the argument and local variable stack for
> working space, but using the same stack for work space would preclude
> the allocation of new local variables, which may be needed in languages
> like C++. Pascal scoping rules mean that all variables are effectively
> created on the stack, (there is the concept of a heap in Pacal too
isn't
> there ?)

Yes, there is a heap with all the usual complications of allocation,
release and cleanup. For security, some portion of the system needs
to clear the heap chunks as they are allocated.

> I assume Java is the same. C and C++ have global or static
> variable space as well as arguments and local variables, which are
> normally referenced above or below a frame pointer.
>
> HP and TI calculators had a 4 level stack. Is it possible to entirely
> evaluate an expression with only 4 stack entries ? I would suspect not,

Given that the expression could be rewritten in postfix notation, I
think it could. I believe the stack on the HP48GX is not limited
other than by the size of memory.

> but if it was possible, then you could possibly implement a hardware
> working stack as well as have a common pointer and stack and frame
> pointer for global and local variables.
>
> I might be showing my ignorance .... sorry.
>
> John.

I don't believe I have spent enough time admiring the B5000. This was
a very clever design!

Richard

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Richard

> The ARM processors have multiple stacks.
>
The ARMs have operating modes with register sets each. The software
usually has a stack assigned to each mode.
> One drawback is that they are of fixed size and statically allocated
> at startup.
>
The ARM does not imply anything on the size and allocation of a stack.
An OS might though.
> I don't see why a memory management unit couldn't solve the whole
> problem. Memory for stacks could be dynamically allocated in
> relatively small chunks. There would need to be some kind of page
> fault detection. Presumably the system level stacks would be large
> enough to prevent faults during hardware interrupts.
>
The ARM memory manager works in 1K, 4K or 64K (IIRC) chunks depending
on how it is set up and how much space one wants to use for paging
tables. Some OSes allocate an initial page for a task stack and use
the page faulting as you suggest. It works well enough for regular
tasks but not so well on realtime tasks and as you point out, the
supervisor stack should be fixed. One side issue here is what happens
in the exception handling if you use page faults for resizing a stack
if the exception handler uses the stack.

Veronica

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, Veronica Merryfield
wrote:
>
> Richard
>
> > The ARM processors have multiple stacks.
> >
> The ARMs have operating modes with register sets each. The software
> usually has a stack assigned to each mode.
> > One drawback is that they are of fixed size and statically allocated
> > at startup.
> >
> The ARM does not imply anything on the size and allocation of a stack.
> An OS might though.
> > I don't see why a memory management unit couldn't solve the whole
> > problem. Memory for stacks could be dynamically allocated in
> > relatively small chunks. There would need to be some kind of page
> > fault detection. Presumably the system level stacks would be large
> > enough to prevent faults during hardware interrupts.
> >
> The ARM memory manager works in 1K, 4K or 64K (IIRC) chunks depending
> on how it is set up and how much space one wants to use for paging
> tables. Some OSes allocate an initial page for a task stack and use
> the page faulting as you suggest. It works well enough for regular
> tasks but not so well on realtime tasks and as you point out, the
> supervisor stack should be fixed. One side issue here is what happens
> in the exception handling if you use page faults for resizing a stack
> if the exception handler uses the stack.
>
> Veronica
>

I guess I was thinking about the ARM7TDMI devices - microcontrollers
really. Certainly the larger devices with MMUs have much more
capability but, other than at the Linux user level, I haven't spent
much time considering the hardware.

I would imagine that the exception handler on these larger ARMs would
use one of the system stacks. I don't know that for sure but even the
ARM7s have separate stacks for undefined instruction trap, abort
interrupt, FIQ (fast interrupts), IRQ (normal interrupts), supervisor
and user.

Richard

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Hi Richard,

rtstofer wrote:
> The ARM processors have multiple stacks. One drawback is that they
> are of fixed size and statically allocated at startup. An RTOS like
> FreeRTOS uses fixed size task stacks.
>
>
A fixed stack is not a problem. I am trying to design a processor with
single byte instructions. 4 bits for the Opcode and 4 bits for
addressing or opcode extensions. This allows the instruction word to be
lengthened from 8 bits to 32 bits, which is what I was referring to as a
scalable design. Also keeping the instruction word simple means that you
are reducing control overhead. Using stack based operators means that
you don't have to use up opcode field bits for specifying the register.

> I don't see why a memory management unit couldn't solve the whole
> problem. Memory for stacks could be dynamically allocated in
> relatively small chunks. There would need to be some kind of page
> fault detection. Presumably the system level stacks would be large
> enough to prevent faults during hardware interrupts.
>
>
Certainly memory management came to mind. With the 8 bit instruction
approach the idea was to load and store words from the stack to either
static/global memory via a "common" pointer or to and from local stack
variables indexed via a frame pointer. Because of the fact that the
instructions are all single word, addressing must be done in segments or
pages. The global variables work up from the bottom of a segment where
as stack variables work. There is no reason why global and local
variables should not share the same segment and the MMU does not need to
allocate an entire segment of memory, as the pointers will wrap around
to use whatever memory is allocated.

On System09, I follow the simple Dynamic Address Translation system
implemented on the old SWTP Computer which allows 1 MByte of memory to
be mapped in on 4 K pages. This is simply done with a register lookup
table on the high order address bits. The CoCo3 computer I think can map
2 MBytes of RAM in 8 Kbyte pages. You might want something more advanced
than that, that can detect segment and page faults.

> How did Burroughs handle stacks in their Algol machines such as the
> B5000? http://en.wikipedia.org/wiki/Burroughs_large_systems
>
>
I'll take a closer look at the page later. I had a brief look but found
it a little difficult trying to figure out the stack arrangement from
the diagram.

> Yes, there is a heap with all the usual complications of allocation,
> release and cleanup. For security, some portion of the system needs
> to clear the heap chunks as they are allocated.
>
>
I hadn't considered cleaning the memory pages, but yes ... for the
integrity of the system, you would want to do that. I think Microsoft's
C# uses a hierarchical memory allocation system to simplify memory
allocation and release.

> Given that the expression could be rewritten in postfix notation, I
> think it could. I believe the stack on the HP48GX is not limited
> other than by the size of memory.
>
Would the expression analyzer need to be rewritten for GCC or LCC ?
That's the big question.

> I don't believe I have spent enough time admiring the B5000. This was
> a very clever design!
>
> Richard
>
Yes, the Wikipedia page said it used all the latest approaches to
hardware and software design, circa 1961 :-) Processor design has been
shrunk courtesy of silicon integration, but I don't know that the
architectures have developed much. I mean not software wise. Obviously
there is a lot of work gone into pipelining and branch prediction, FPUs,
caching and so on, but from a point of memory allocation with frame
pointers and so on, I could be wrong, but I'm inclined to think that if
any thing, things have been simplified.

The idea of processors in FPGAs should really be to try and keep the
overhead of control to a minimum so that you are focusing on parallelism
of the design. To implement a Von Neuman processor on an FPGA seems like
a horrible waste of resources. You don't get the advantage of speed of a
custom ASIC and you don't get the benefit of the parallel logic.

Is Reiner Hartenstein monitoring the list ? :-) I noticed he had a few
papers on the "Von Neuman Syndrome".

John.

--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Is it possible to design a scalable search processor that performs
parallel searches in data ....
It would certainly make use of the parallel capacity of FPGA hardware.
What sort of features would such a processor have ?
What sort of searches would it perform ?
What sort of applications would it have ?

John.

--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent
------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Did you look up CAMs? (Content addressable memories)

Essentially it depends on the type of operations that you want to perform
and what data structures support that operations.
It also depends on the size of the data you are processing.

In each cycle you can access one word per register, one word per
distributed RAM,
one (or two) words per BRAM, a fraction of one address per external RAM port.

For data that fits in registers there is a very nice architecture for
systolic priority queues.
This means that you can sort small data sets as fast as you can input
data, which means
that you can find finimum, maximum, median, etc.

Also, you can search an arbitrarily large string for a pattern that
fits into your FPGA as
fast as you can input the string. (Smith-Waterman-Algorithm) You can
even find the
optimal non-exact match for rather complex metrics.

Kolja Sulimma

2008/8/8 John Kent :
> Is it possible to design a scalable search processor that performs
> parallel searches in data ....
> It would certainly make use of the parallel capacity of FPGA hardware.
> What sort of features would such a processor have ?
> What sort of searches would it perform ?
> What sort of applications would it have ?
>
> John.
>
> --
> http://www.johnkent.com.au
> http://members.optushome.com.au/jekent

--
cronologic ohg Frankfurt am Main
HRA 42869 beim Amtsgericht Frankfurt
Telefon 069 38 09 78 254

------------------------------------

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Hi Kolja,
Kolja Sulimma wrote:
> Did you look up CAMs? (Content addressable memories)
>
> Essentially it depends on the type of operations that you want to perform
> and what data structures support that operations.
> It also depends on the size of the data you are processing.
>
> In each cycle you can access one word per register, one word per
> distributed RAM,
> one (or two) words per BRAM, a fraction of one address per external RAM port.
>
> For data that fits in registers there is a very nice architecture for