EmbeddedRelated.com
Forums
Memfault Beyond the Launch

Small CPUs in FPGAs

Started by Rick Collins July 31, 2008
--- In f..., 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...
To unsubscribe, send a blank message to: f...
--- In f..., "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...
To unsubscribe, send a blank message to: f...
--- In f..., "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...
To unsubscribe, send a blank message to: f...
> 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...
To unsubscribe, send a blank message to: f...
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...
> 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...
> To unsubscribe, send a blank message to:
> f...
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...
To unsubscribe, send a blank message to: f...
--- In f..., "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...
To unsubscribe, send a blank message to: f...
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...
To unsubscribe, send a blank message to: f...
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...
To unsubscribe, send a blank message to: f...
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...
To unsubscribe, send a blank message to: f...

Memfault Beyond the Launch