Sign in

Search fpga-cpu

Subscribe to fpga-cpu

fpga-cpu by Keywords

Sponsor

controlSUITE™ software
Comprehensive.
Intuitive.
Optimized.
Real-world software for real-time control. Details Here!

Discussion Groups

Discussion Groups | FPGA-CPU | Small CPUs in FPGAs

This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).

Small CPUs in FPGAs - Rick Collins - Jul 31 10:18:48 2008

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

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

Re: Small CPUs in FPGAs - Leon - Jul 31 11:47:10 2008
----- 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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - Hellwig Geisse - Jul 31 12:06:30 2008
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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - Tommy Thorn - Jul 31 12:19:52 2008
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 )
YARI was: Small CPUs in FPGAs - Tommy Thorn - Jul 31 12:45:23 2008
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 )
Re: Small CPUs in FPGAs - Rick Collins - Jul 31 12:54:36 2008
--- 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 )
Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Jul 31 13:03:11 2008
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 )
Re: Small CPUs in FPGAs - Rick Collins - Jul 31 13:04:29 2008
--- 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 )
Re: Small CPUs in FPGAs - Hellwig Geisse - Aug 2 3:52:06 2008
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 )
Re: Small CPUs in FPGAs - Yashwant Shitoot - Aug 2 5:11:52 2008
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 )
Re: Small CPUs in FPGAs - Rick Collins - Aug 2 8:57:11 2008
--- 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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - rtstofer - Aug 2 16:55:53 2008
--- 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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - Rick Collins - Aug 2 17:28:22 2008
--- 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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - rtstofer - Aug 2 19:24:51 2008
> 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 )
Re: Re: Small CPUs in FPGAs - Tommy Thorn - Aug 2 19:36:11 2008
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 )
Re: Small CPUs in FPGAs - Jon Kirwan - Aug 2 20:57:39 2008
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 )
Re: Small CPUs in FPGAs - Rick Collins - Aug 2 21:26:57 2008
--- 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 )
Re: Re: Small CPUs in FPGAs - John Kent - Aug 2 23:10:54 2008
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 )
Re: Re: Small CPUs in FPGAs - John Kent - Aug 3 0:09:25 2008
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 )
Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 3 0:30:49 2008
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 )
Re: Re: Small CPUs in FPGAs - Tommy Thorn - Aug 3 1:54:54 2008
> 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 )
Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 3 12:55:55 2008
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 )
RE: Re: Small CPUs in FPGAs - Jan Gray - Aug 3 23:06:53 2008
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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - Rick Collins - Aug 3 23:27:00 2008
--- 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 )
Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 3 23:52:25 2008
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 )
Re: Small CPUs in FPGAs - rtstofer - Aug 4 0:43:28 2008

> 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 )
Re: Re: Small CPUs in FPGAs - John Kent - Aug 4 0:58:28 2008
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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: Small CPUs in FPGAs - Jan Gray - Aug 4 7:55:02 2008
> 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 )
Re: Small CPUs in FPGAs - Rick Collins - Aug 4 10:05:05 2008
--- 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 )
Re: Small CPUs in FPGAs - Rick Collins - Aug 4 11:47:06 2008
--- 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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - Rick Collins - Aug 4 12:29:33 2008
--- 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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: Small CPUs in FPGAs - John Kent - Aug 4 20:12:18 2008
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 )
Re: Re: Small CPUs in FPGAs - John Kent - Aug 6 2:33:02 2008
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 )
Re: Re: Small CPUs in FPGAs - Martin Schoeberl - Aug 6 5:15:11 2008
> 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 )
Re: Small CPUs in FPGAs - Philip Freidin - Aug 6 7:47:29 2008

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 )
Re: Small CPUs in FPGAs - rtstofer - Aug 6 11:22:47 2008
--- 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 )
Re: Re: Small CPUs in FPGAs - John Kent - Aug 7 7:57:03 2008
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 )
Re: Re: Small CPUs in FPGAs - John Kent - Aug 7 8:04:16 2008
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 )
Re: Small CPUs in FPGAs - rtstofer - Aug 7 10:21:46 2008
> 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 )
Re: Re: Small CPUs in FPGAs - Veronica Merryfield - Aug 7 12:45:45 2008
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 )
Re: Small CPUs in FPGAs - rtstofer - Aug 7 13:47:46 2008
--- 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 )
Re: Re: Small CPUs in FPGAs - John Kent - Aug 8 0:30:57 2008
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 )
Parallel Search Processor. - John Kent - Aug 8 7:02:43 2008
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 )
Re: Parallel Search Processor. - Kolja Sulimma - Aug 8 8:31:20 2008
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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Parallel Search Processor. - John Kent - Aug 8 23:48:28 2008
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
> 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.
>
>
Back in the 1990s I was working on video median filters. I came up with
a scheme that used an array of magnitude comparators connected to a
parallel shift register array. There was a bus for inserting pixels and
a bus for deleting pixels from the shift register. The delete pixel was
delayed by a delay shift register the length of the sorting shift
register. The idea was that a pixel was inserted into or deleted from
the shift register where there was a change in the magnitude being
greater to being less than or equal. Only the pixels between the insert
point and delete point were shifted up or down. I thought I was rather
clever coming up with the design until I discovered that Arce and Warter
et al. had come up with an almost identical design 10 years earlier,
which goes to show how difficult it is to come up with a truly original
design.

> 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.
>
>
I notice in Donald Knuth's book on sorting and searching algorithms that
the Batcher sorting network is about the most efficient method of
performing a parallel sort. I would imagine for non exact matches you
could use a binary correlator. i.e. XOR the bits with the pattern being
searched for and sum the bits. You then use a min / max filter to
determine the best correlation. I see no reason why that would not work
on text as well as other data, although on text, you might want to weigh
some of the terms.
> Kolja Sulimma
>
I was pondering the nature of problems that people solve. Systolic
arrays are good for sorting and searching or for Fourier transforms and
so on but that class of regular geometric processing does not really
pervade conventional personal computing. (A bold unjustifiable statement
perhaps.) I notice that the iMX31 ARM chip has a built in MPEG encoder,
so with multimedia applications becoming more prevalent, there does
appear to be a move to integrate dedicated signal processing hardware
into the CPU designs.

For a CPU to really be able to handle sparse data, the data must be
distilled down, using some criteria such as sorting, matching,
transformation or min/max etc, to a condensed form where by you can make
an evaluation and decision on it, usually in the human domain. In the
case of a display card, the information is expanded up from condensed
information to sparse information for display in human readable form
using some sort of geometric transformation.

So I guess, if a transformation is used often enough, it gets integrated
into hardware.

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 )
Re: Small CPUs in FPGAs - Brian Davis - Aug 9 0:23:26 2008
Philip Freidin wrote:
>
> And to my surprise, my design got mentioned in the August 2008
> issue of Circuit Cellar magazine, in an article by Tom Cantrell
>

The picture therein demonstrating the R16 to have the
crowning element needed to qualify as a "real" computer:

A front panel with switches and blinkenlights !!!

Brian

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

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 9 0:35:41 2008
Brian Davis wrote:
> The picture therein demonstrating the R16 to have the
> crowning element needed to qualify as a "real" computer:
>
> A front panel with switches and blinkenlights !!!
>
>
I'm working on that .... (but not R16)
But alas switches and blinking lights use a lot of I/O pins.
> Brian
>
Who at the moment is trying to decide to build 12/24 bit cpu
or 8/16/32 bit cpu both with 256Kb of memory. Note the 12 bit
is a nicer design but everything is 8 bit bytes today.

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

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - Brian Davis - Aug 9 0:38:11 2008
Rick Collins wrote:
>
> today's FPGAs no longer include T-bufs so multiplexers
> have to be used increasing the LUT count.
>
My 4005e processor attempt weighed in at about 200 LUTs
and 180 TBUFs in 16 bit mode, including tiny RAM, ROM, and I/O:

http://www.fpga-faq.com/archives/49250.html#49263
http://members.aol.com/fpgastuff/early_y1.tif

I've never managed the time to get the documentation and
compiler finished, or the VHDL code tidied up enough to
release. The simple absolute assembler worked well enough
for writing instruction set test cases and small examples.

I finally got the code synthesizing again last Christmas
holiday (worked in ISE 6.3, but not in ISE 7 & 8 & 9 due
to #$%!@#!! XST alias bugs ), the 32 bit core is now about
800 LUTs in a Spartan3

The unfinished improvements involved adding a SP/FP stack
addressing mode, manual push/pop of the hardware return
stack, cleaner long immediates, and other sundry updates.

see also:
http://tech.groups.yahoo.com/group/fpga-cpu/message/106
http://tech.groups.yahoo.com/group/fpga-cpu/message/118
http://tech.groups.yahoo.com/group/fpga-cpu/message/332
http://tech.groups.yahoo.com/group/fpga-cpu/message/666
Brian

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

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 )
Re: Re: Small CPUs in FPGAs - Martin Schoeberl - Aug 9 5:07:51 2008
Hi John,

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

In JOP I have some 'special' instructions that can access the stack
cache directly. On the thread switch the stack is exchanged - it is
the machine state.

> 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

why? There is no reason to not allocate data (in C with alloca) on
the stack. In Java stack allocation is not possible.

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

In Java there is also global/static data, but only primitives. All
objects and arrays are allocated on the heap.

Cheers,
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 )
Re: Re: Small CPUs in FPGAs - John Kent - Aug 9 10:46:48 2008
Hi Martin,
Martin Schoeberl wrote:
> In JOP I have some 'special' instructions that can access the stack
> cache directly. On the thread switch the stack is exchanged - it is
> the machine state.
>
>
I guess it depends on how large the stack is. I would have though it
would be easier to save the frame and stack pointers, CCs, PC and TOS on
the supervisor stack. Presumably you still have a frame pointer and
stack pointer. Moving an entire stack would make a context switch pretty
time consuming. On the other hand if you save the stack pointer, you
need a supervisor stack to save it on.
>> 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
>>
>
> why? There is no reason to not allocate data (in C with alloca) on
> the stack. In Java stack allocation is not possible.
>
>
well ... in a procedure call, arguments are pushed on the stack, then
the return address then the frame pointer and the frame pointer is
loaded with the stack pointer. Local variables are then allocated on the
stack. Local variables are indexed with a negative offset from the frame
pointer, while the arguments are indexed with a positive offset, taking
into account the space taken up by the return address and frame pointer.
If the stack below the local variables is used for working space for
evaluating expressions, then it becomes hard to re-allocate space for
any new local variables. It depends if there are any working variables
on the stack when a new variable is declared at the start of a block.

> In Java there is also global/static data, but only primitives. All
> objects and arrays are allocated on the heap.
>
>
OK
> Cheers,
> Martin
>
Bed time.
Cheers

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 )
Re: Small CPUs in FPGAs - rtstofer - Aug 9 10:58:37 2008
--- In f...@yahoogroups.com, "bfranchuk@..." wrote:
>
> Brian Davis wrote:
> > The picture therein demonstrating the R16 to have the
> > crowning element needed to qualify as a "real" computer:
> >
> > A front panel with switches and blinkenlights !!!
> >
> >
> I'm working on that .... (but not R16)
> But alas switches and blinking lights use a lot of I/O pins.

In terms of lights and switches vs IO lines, it isn't really important
that the LEDs be EXACTLY the same as the driving signals. The human
eye can't see them anyway if the duty cycle is low.

My approach is to use one of those SPI LED driver chips (actually, any
of the bidirectional IO ports) and just shift out the value at the
time the shift register is loaded. We're talking about clocking SPI
at multiple megahertz so the sampling frequency is quite high.

There are bi-color driver chips as well and matrix LED displays
(including dual-color)
http://www.sparkfun.com/commerce/product_info.php?products_id=682.

If the CPU is stopped, the LEDs will be correct within a millisecond -
far faster than the eye can process.

I use the same idea for switch inputs: any of the bidirectional IO
expanders will work.

I really like SPI. It is trivial to implement.

> >
> Who at the moment is trying to decide to build 12/24 bit cpu
> or 8/16/32 bit cpu both with 256Kb of memory. Note the 12 bit
> is a nicer design but everything is 8 bit bytes today.
>

I am not looking for a design but if something catches my attention, I
might implement it just for the fun of it.

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 )
Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 9 12:56:08 2008
rtstofer wrote:
> If the CPU is stopped, the LEDs will be correct within a millisecond -
> far faster than the eye can process.
>
> I use the same idea for switch inputs: any of the bidirectional IO
> expanders will work.
>
> I really like SPI. It is trivial to implement.
>
>
If you use a FPGA that is easy. Right now I am trying to stick
to Thu the hole parts and they sound surface mount.
>>>
>>>
>> Who at the moment is trying to decide to build 12/24 bit cpu
>> or 8/16/32 bit cpu both with 256Kb of memory. Note the 12 bit
>> is a nicer design but everything is 8 bit bytes today.
>>
>>
>
> I am not looking for a design but if something catches my attention, I
> might implement it just for the fun of it.
>
The 16/32 bit design I am looking at is
Byte:mode:op:ac:ix:# #:#:#:#:#:# where all are octal digits
except the leading one where it is 0 or 1
The advantage here is you have 512Kb of direct addressing
rather than 16 bits. The only downside like the 68000 is that
byte # takes up a full word.

> 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 )
Re: Small CPUs in FPGAs - Brian Davis - Aug 9 15:17:10 2008
Richard wrote:
>
> In terms of lights and switches vs IO lines, it isn't
> really important that the LEDs be EXACTLY the same as
> the driving signals. The human eye can't see them
> anyway if the duty cycle is low.
>
> My approach is to use one of those SPI LED driver chips
> (actually, any of the bidirectional IO ports) and just
> shift out the value at the time the shift register is
> loaded. We're talking about clocking SPI at multiple
> megahertz so the sampling frequency is quite high.
>

I'd envisoned something similar: a JTAG front panel
for homebrew CPU projects.

The on-chip CPU JTAG debug register set could have
address/data bus snooping registers that keep a
4 to 8 bit duty cycle for each bus bit, which would
allow for realistic pattern-dependent LED intensities.

I was worried about sampling artifacts with the
once-in-a-while bus snapshot; e.g. if you're in a
loop whose execution time is a factor of the front
panel update period, you'll get a static display.

I never built one though, so that approach might
work just fine in practice ( you could also randomize
the update period )

A basic switch/LED card with 8|9 bit width could
then be chained to work for 16/32 or 18/36 bit CPUs

The CPU debug interface could then be used with a
debugger and JTAG cable, or you could plug in the
old school hardware instead.

If ever I find time to build one, I can but hope that
it looks half as nice as this:
http://www.sparetimegizmos.com/Hardware/SBC6120_Front_Panel.htm

Brian

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

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 )
Re: Small CPUs in FPGAs - rtstofer - Aug 9 16:27:00 2008
--- In f...@yahoogroups.com, "bfranchuk@..." wrote:
>
> rtstofer wrote:
> > If the CPU is stopped, the LEDs will be correct within a millisecond -
> > far faster than the eye can process.
> >
> > I use the same idea for switch inputs: any of the bidirectional IO
> > expanders will work.
> >
> > I really like SPI. It is trivial to implement.
> >
> >
> If you use a FPGA that is easy. Right now I am trying to stick
> to Thu the hole parts and they sound surface mount.

Not really. There are a number of these devices in PDIP. In fact, I
built a 16 hex digit display (4 16-bit registers or 2 32 bit registers
depending on the project) and it uses a 40 pin PDIP MAX 6954APL. At
the time I wasn't doing SMD. Now I rarely use thru-hole components.

> The 16/32 bit design I am looking at is
> Byte:mode:op:ac:ix:# #:#:#:#:#:# where all are octal digits
> except the leading one where it is 0 or 1
> The advantage here is you have 512Kb of direct addressing
> rather than 16 bits. The only downside like the 68000 is that
> byte # takes up a full word.
>
The ARM7's can't load a 32 bit immediate constant either using one
word per instruction. The compiler puts such constants in a nearby
literal pool, if necessary. Sometimes it forms constants by loading
portions of the constant in registers and adding them together. Weird...

Then too, the 60 bit CDC computers had as many as (4) 15 bit
instructions in each word. Totally dependent on the instruction
sequence. Instructions did not overlap word boundaries IIRC.

Richard
Richard

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

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - Philip Freidin - Aug 9 23:38:34 2008
>Posted by: "rtstofer" r...@pacbell.net rtstofer
>Philip,
>
>I wandered around your web site this morning looking for the RISC4005
>project but didn't see it. Is there a link?
>Richard

There is no online documentation on the Risc4005 or its cousin the R16.

Jan Gray's design is extremely similar and has great documentation,
so reviewing his docs would be my recomendation.
>Posted by: "John Kent" j...@optushome.com.au
>
>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.

That's probably right. With each new generation of FPGA, the biggest
devices are often over $1000 each in small quantities. I think that
when the Virtex line first came out, the biggest chips were over $5000
each. You can get them on eBay these days as surplus for far less :-)
>Posted by: "Brian Davis" b...@aol.com brimdavis
>
>Philip Freidin wrote:
>>
>> And to my surprise, my design got mentioned in the August 2008
>> issue of Circuit Cellar magazine, in an article by Tom Cantrell
>>The picture therein demonstrating the R16 to have the
>crowning element needed to qualify as a "real" computer:
>
> A front panel with switches and blinkenlights !!!
>
>Brian

The Risc4005 XC4005 and its 32K words of memory and 8 channel DAC
are on the board on top. It is self contained and can run stand alone.

The front panel box contains a power supply, and 4 XC3020 FPGAs.
Each is a 4 bit slice of the front panel logic, containing a few
display registers (PC, AC, Bus, Q). The right 8 switches and LEDs
have 1 more XC3020 that does single stepping, Run/Halt, Examine
and Deposit, and also repeated Examine/Deposit for quick wiping
of memory or searching for some pattern.

I really can't understand how we have let computers evolve without
front panels. Very sad :-)
>Posted by: "b...@jetnet.ab.ca" b...@jetnet.ab.ca woodelf1
>
>Brian Davis wrote:
>> A front panel with switches and blinkenlights !!!
>
>I'm working on that .... (but not R16)
>But alas switches and blinking lights use a lot of I/O pins.

Maybe a min pin count serial interface to get the registers
out of the FPGA ? Maybe a multiplexed display controller inside
the FPGA, to use up all the left over CLBs.
=================
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 )
Re: Big CPUs in Small FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 3:33:46 2008
Philip Freidin wrote:
> The front panel box contains a power supply, and 4 XC3020 FPGAs.
> Each is a 4 bit slice of the front panel logic, containing a few
> display registers (PC, AC, Bus, Q). The right 8 switches and LEDs
> have 1 more XC3020 that does single stepping, Run/Halt, Examine
> and Deposit, and also repeated Examine/Deposit for quick wiping
> of memory or searching for some pattern.
>
> I really can't understand how we have let computers evolve without
> front panels. Very sad :-)
>

Even with out front panels, here is some food for thought
for a nice machine that is begging to be re-implimented again
in hardware.

-------------------
Those with an interest in the ETH Lilith Modula-2 should point their FTP
clients to
ftp://jdreesen.dyndns.org/ftp/lilith

where they will find plenty of data concerning that machine.

Most important is a binary image of the Lilith Systemdisk, and a
directory containing all files ( more then 700..) of that systemdisk.

Among these files are :

Medos binaries and source code.
Modula-2 compiler binaries with source code.
Lilith system utilities with source code.
Bootfiles and system files.
Microcode sources and assembler
Manual
Also available are hardware docu and some screenshots.

Enjoy ,

Jos Dreesen

Server is on a basic DSL line, so download speeds will vary....
---------------
------------------------------------

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 )
Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 3:37:58 2008
Brian Davis wrote:
> If ever I find time to build one, I can but hope that
> it looks half as nice as this:
> http://www.sparetimegizmos.com/Hardware/SBC6120_Front_Panel.htm
>
I got the switches and PCB for that, but I decided to try my hand
at a homebrew cpu instead.
> Brian
>
That reminds me, I need to update the HD for SBC6120
with the lastest game out .... ADVENTURE Ver 2.0

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

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Big CPUs in Small FPGAs - John Kent - Aug 10 4:01:56 2008
I was given some PDP-8 design files by Hans Pufal a number of years ago.
The approach he took was to implement the front panel on a VGA display.
He used the numeric keypad section of a PS/2 keyboard for setting the
registers in octal. I have seen numeric key pads in fliers from a local
electronics disposal store so you should be able to get them. The
construction of the display image was done on the fly, using comparators
on the row and column counters but another way would be to have a
separate micro and display controller with pre-initialized block RAM.
You can get disposal LCD display panels for about $50 rather than
allocating a new monitor to the task. Anyway ... that's one way you can
do it. You can even emulate the colour scheme of the original computer
if you are clever.

John.

b...@jetnet.ab.ca wrote:
> Philip Freidin wrote:
>
>> The front panel box contains a power supply, and 4 XC3020 FPGAs.
>> Each is a 4 bit slice of the front panel logic, containing a few
>> display registers (PC, AC, Bus, Q). The right 8 switches and LEDs
>> have 1 more XC3020 that does single stepping, Run/Halt, Examine
>> and Deposit, and also repeated Examine/Deposit for quick wiping
>> of memory or searching for some pattern.
>>
>> I really can't understand how we have let computers evolve without
>> front panels. Very sad :-)
>>
>>
>
> Even with out front panels, here is some food for thought
> for a nice machine that is begging to be re-implimented again
> in hardware.
>
Snip

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Big CPUs in Small FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 4:14:43 2008
John Kent wrote:
> I was given some PDP-8 design files by Hans Pufal a number of years ago.
> The approach he took was to implement the front panel on a VGA display.
> He used the numeric keypad section of a PS/2 keyboard for setting the
> registers in octal. I have seen numeric key pads in fliers from a local
> electronics disposal store so you should be able to get them. The
> construction of the display image was done on the fly, using comparators
> on the row and column counters but another way would be to have a
> separate micro and display controller with pre-initialized block RAM.
> You can get disposal LCD display panels for about $50 rather than
> allocating a new monitor to the task. Anyway ... that's one way you can
> do it. You can even emulate the colour scheme of the original computer
> if you are clever.
>
>
I think I want to get the hardware first designed, then worry about the
display logic.
> John.
>
> b...@jetnet.ab.ca wrote:
>
>>
>> Even with out front panels, here is some food for thought
>> for a nice machine that is begging to be re-implimented again
>> in hardware.
>>
>>
> Snip
>
Check out the Lilith machine... too bad it never made the market place.
I guess nobody wanted a machine with a 'windows' display and mouse
in 1981.

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

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 )
Re: Big CPUs in Small FPGAs - John Kent - Aug 10 4:20:08 2008
An alternative to using a keypad for the toggle switches would also be
to use a mouse to toggle the switches on the VGA display.

I note the FP6120. The problem with the Intersil (?) 6120 chip was that
my friends wanted to emulate the Digital buses for the PDP-8 (Posibus
and so on) so they could interface old hardware and the 6120 did not
generate the correct bus signals. I have not heard from the guys in
quite a while, so I'm not sure what they did in the end. I was
originally approached by Henk Gooijens, who runs the www.pdp-11.nl web
site who wanted a faster 6809 to run his PDP-8 emulator on. The emulator
was actually originally written by a good friend, Frank Wilson, who I
know from the Flex User Group mailing list. I suggested Henk could
emulate the entire PDP-8 processor in an FPGA, and Hans Pufal was kind
enough to offer us his PDP-8 design.

John.
John Kent wrote:
> I was given some PDP-8 design files by Hans Pufal a number of years ago.
> The approach he took was to implement the front panel on a VGA display.
> He used the numeric keypad section of a PS/2 keyboard for setting the
> registers in octal. I have seen numeric key pads in fliers from a local
> electronics disposal store so you should be able to get them. The
> construction of the display image was done on the fly, using comparators
> on the row and column counters but another way would be to have a
> separate micro and display controller with pre-initialized block RAM.
> You can get disposal LCD display panels for about $50 rather than
> allocating a new monitor to the task. Anyway ... that's one way you can
> do it. You can even emulate the colour scheme of the original computer
> if you are clever.
>
> 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 )
Re: Big CPUs in Small FPGAs - John Kent - Aug 10 4:23:04 2008
No problems.
Henk was rather good at milling front panels and so on, but not me.

JK.

b...@jetnet.ab.ca wrote:
>
> I think I want to get the hardware first designed, then worry about the
> display logic.
>
>

--
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 )
Re: Small CPUs in FPGAs - e2kcpu - Aug 10 8:01:30 2008
--- In f...@yahoogroups.com, "Rick Collins" wrote:
>
> 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.

What were you missing ?
IIRC, I found everything I needed in the zip file from J.Gray Webpage.
(I looked at it quite a while ago)

Cheers

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

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 )
Re: Small CPUs in FPGAs - e2kcpu - Aug 10 8:04:22 2008
--- In f...@yahoogroups.com, Hellwig Geisse
wrote:
> 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

What are the major differences to e "real" MIPS I ?

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

Twice the same link ?
>
> (C compiler, many ROMs with test programs, machine monitor).

> the documentation is in a horrible state, I must confess...

;-)

Any plan to rewrite it to VHDL ?
(Amazed to find something written in Verilog on a german FH/UNI web
page ;-))

Cheers
------------------------------------

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 )
Re: Big CPUs in Small FPGAs - e2kcpu - Aug 10 8:22:20 2008
--- In f...@yahoogroups.com, "bfranchuk@..." wrote:

> Even with out front panels, here is some food for thought
> for a nice machine that is begging to be re-implimented again
> in hardware.
> [lilith ...]

I thought you have already boards with 2901/2903 in CPLDs ?

Cheers
------------------------------------

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 )
Re: Re: Small CPUs in FPGAs - Hellwig Geisse - Aug 10 8:55:36 2008
On Sun, 2008-08-10 at 12:04 +0000, e2kcpu wrote:

> What are the major differences to e "real" MIPS I ?

Different instruction encoding, different special registers.
Generally an independent design, following the example in
Patterson/Hennessy. The instruction set is RISC-compatible
(in the sense that it can efficiently be run on a pipeline),
but my implementation isn't yet (it's a multicycle CPU,
but it is my intention to do a pipelined design next, as
soon as I have an operating system running on it).

> > http://homepages.fh-giessen.de/~hg53/eco32/
> > http://homepages.fh-giessen.de/~hg53/eos32/
>
> Twice the same link ?

No.

> Any plan to rewrite it to VHDL ?
> (Amazed to find something written in Verilog on a german FH/UNI web
> page ;-))

Well, I had to decide the language question when I started
teaching a course on "Hardware for Embedded Systems". I designed
a set of assignments and worked out solutions in both Verilog and
VHDL. IMO, the biggest difficulty for CS students is the fact that
these languages describe (parallel) hardware and not (sequential)
software. The difference in syntax then is a rather small matter.

Eventually I discovered this 12 year old contest:

http://www.cl.cam.ac.uk/~mjcg/Verilog/Cooley-VHDL-Verilog.html

and I decided in favour of Verilog... ;-)
Best regards,
Hellwig
------------------------------------

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - e2kcpu - Aug 10 10:04:50 2008
--- In f...@yahoogroups.com, Hellwig Geisse
wrote:
>
> On Sun, 2008-08-10 at 12:04 +0000, e2kcpu wrote:
>
> > What are the major differences to e "real" MIPS I ?
>
> Different instruction encoding, different special registers.
> Generally an independent design, following the example in
> Patterson/Hennessy. The instruction set is RISC-compatible
> (in the sense that it can efficiently be run on a pipeline),
> but my implementation isn't yet (it's a multicycle CPU,
> but it is my intention to do a pipelined design next, as
> soon as I have an operating system running on it).

OK. You only ported LCC to it ?
I didn't see any GNU Tools there ...
Ever took a look at PCC ? Produces much better code ...

> > > http://homepages.fh-giessen.de/~hg53/eco32/
> > > http://homepages.fh-giessen.de/~hg53/eos32/
> >
> > Twice the same link ?
>
> No.

Sorry, that's what I get for replying to email before coffee ;-)

> > Any plan to rewrite it to VHDL ?
> Eventually I discovered this 12 year old contest:
>
> http://www.cl.cam.ac.uk/~mjcg/Verilog/Cooley-VHDL-Verilog.html
>
> and I decided in favour of Verilog... ;-)

VERY fun reading for a Sunday morning,
thanks !

Cheers
------------------------------------

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: Small CPUs in FPGAs - Hellwig Geisse - Aug 10 10:53:15 2008
On Sun, 2008-08-10 at 14:04 +0000, e2kcpu wrote:

> OK. You only ported LCC to it ?

Yes. This was in fact very easy.

> Ever took a look at PCC ? Produces much better code ...

No, I didn't. I'm surprised to see that it now understands
ANSI-C. Very interesting, thanks.

Hellwig

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

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - Rick Collins - Aug 10 11:57:12 2008
--- In f...@yahoogroups.com, "e2kcpu" wrote:
>
> --- In f...@yahoogroups.com, "Rick Collins" wrote:
> >
> > 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.
>
> What were you missing ?
> IIRC, I found everything I needed in the zip file from J.Gray Webpage.
> (I looked at it quite a while ago)

Perhaps you are thinking of the xr16? That was completely published
and an LCC port was provided. The gr0040 was not fully documented and
the web site even says the compiler was ported, but not provided.

The significance of the gr0040 and related designs seems to be the low
LUT count. But I believe this was using TBUFs for multiplexers and
they are no longer used in FPGAs. Now you have to use LUTs to created
muxes and it can be rather expensive. When I created my ALU,
recognizing this, I used the adder/logic unit to mux the TOS and NOS
into the TOS input mux. This saved one block of LUTs. Still, at
around 100 LUTs that input mux was the largest structure in the entire
CPU. Otherwise the design was pretty small.

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 )
Re: Small CPUs in FPGAs - e2kcpu - Aug 10 12:35:34 2008
--- In f...@yahoogroups.com, "Rick Collins" wrote:
>
> --- In f...@yahoogroups.com, "e2kcpu" wrote:

> > What were you missing ?
> > IIRC, I found everything I needed in the zip file from J.Gray Webpage.
> > (I looked at it quite a while ago)
>
> Perhaps you are thinking of the xr16? That was completely published
> and an LCC port was provided. The gr0040 was not fully documented and
> the web site even says the compiler was ported, but not provided.

Yup, I just checked, and you are right. I mixed it up, sorry.
But the gr0040 is still available, and just run it through P&R ...

> The significance of the gr0040 and related designs seems to be the low
> LUT count. But I believe this was using TBUFs for multiplexers and
> they are no longer used in FPGAs. Now you have to use LUTs to created
> muxes and it can be rather expensive. When I created my ALU,
> recognizing this, I used the adder/logic unit to mux the TOS and NOS
> into the TOS input mux. This saved one block of LUTs. Still, at
> around 100 LUTs that input mux was the largest structure in the entire
> CPU. Otherwise the design was pretty small.

But that's something we have to deal now with, as all the newer FPGAs
are having the same structure :(

Cheers
------------------------------------

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Big CPUs in Small FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 12:49:43 2008
John Kent wrote:
> An alternative to using a keypad for the toggle switches would also be
> to use a mouse to toggle the switches on the VGA display.
>
> I note the FP6120. The problem with the Intersil (?) 6120 chip was that
> my friends wanted to emulate the Digital buses for the PDP-8 (Posibus
> and so on) so they could interface old hardware and the 6120 did not
> generate the correct bus signals. I have not heard from the guys in
> quite a while, so I'm not sure what they did in the end. I was
> originally approached by Henk Gooijens, who runs the www.pdp-11.nl web
> site who wanted a faster 6809 to run his PDP-8 emulator on. The emulator
> was actually originally written by a good friend, Frank Wilson, who I
> know from the Flex User Group mailing list. I suggested Henk could
> emulate the entire PDP-8 processor in an FPGA, and Hans Pufal was kind
> enough to offer us his PDP-8 design.
>
>
Well I like CPLD's rather than FPGA's since you don't need a boot
prom for the CPLD's. The maintance manuals for the PDP's are on-line
http://bitsavers.trailing-edge.com/ I suspect that is where to start
as well as looking at Simh for emulation as the hardware for the old
machines had a lot of gota ya's design features based on qurks of the
hardware used. A simple PDP8 with 4K of memory is easy ...
A full featured one with hardware floating point, 32K of memory
and timeshareing hardware is very tricky make right.
> 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 )
Re: Small CPUs in FPGAs - e2kcpu - Aug 10 12:51:14 2008
--- In f...@yahoogroups.com, Hellwig Geisse
wrote:
> On Sun, 2008-08-10 at 14:04 +0000, e2kcpu wrote:
> > OK. You only ported LCC to it ?
> Yes. This was in fact very easy.

I know. It usually takes just few days to get working result from it.
Did it once for an SIMD machine. But all the progress is going to the
x86 platform, so I don't care anymore about it.

> > Ever took a look at PCC ? Produces much better code ...
>
> No, I didn't. I'm surprised to see that it now understands
> ANSI-C. Very interesting, thanks.

The optimizer is nice ...

And MUCH simpler than GNU ;-)

But probably GNU is still doable for you, as you "seem" to be close to
MIPS ...

Cheers
------------------------------------

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 )
Re: Big CPUs in Small FPGAs - Rick Collins - Aug 10 12:54:09 2008
--- In f...@yahoogroups.com, "bfranchuk@..." wrote:
>
> Well I like CPLD's rather than FPGA's since you don't need a boot
> prom for the CPLD's.

You don't have to use a boot prom. There are a number of flash based
FPGAs from Lattice and Altera makes some parts that are more FPGA than
CPLD and are flash based. Check out the Lattice XP and XP2 devices.
No boot prom required. They have both SRAM and Flash, so you can run
the FPGA from SRAM while updating the Flash without disruption.
> The maintance manuals for the PDP's are on-line
> http://bitsavers.trailing-edge.com/ I suspect that is where to start
> as well as looking at Simh for emulation as the hardware for the old
> machines had a lot of gota ya's design features based on qurks of the
> hardware used. A simple PDP8 with 4K of memory is easy ...
> A full featured one with hardware floating point, 32K of memory
> and timeshareing hardware is very tricky make right.

Any idea how many LUTs a PDP8 would be?

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 )
Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 12:55:16 2008
Hellwig Geisse wrote:
> On Sun, 2008-08-10 at 14:04 +0000, e2kcpu wrote:
>
>
>> OK. You only ported LCC to it ?
>>
>
> Yes. This was in fact very easy.
>
>
>> Ever took a look at PCC ? Produces much better code ...
>>
>
> No, I didn't. I'm surprised to see that it now understands
> ANSI-C. Very interesting, thanks.
>
I may how ever, as I planning a 16/32 bit CPU
but limited to only 20 bits of addressing.
(My PC clone ):)
Tiny C 1.0
I can get to comple but not version # 2 as the logic
is too hacked for peephole optimization.
------------------------------------

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 )
Re: Big CPUs in Small FPGAs - e2kcpu - Aug 10 12:56:40 2008
--- In f...@yahoogroups.com, "bfranchuk@..." wrote:
> Well I like CPLD's rather than FPGA's since you don't need a boot
> prom for the CPLD's.

But there is also an upside to it. Since the newer FPGAs can also boot
from standard SPI flash, and this is usually much bigger than you need
it, you can use the remaining flash for you uCode. Boot your FPGA, and
shift the uCode into your uCode SRAM. Very nice ...

Cheers
------------------------------------

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 )
Re: Re: Big CPUs in Small FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 12:59:23 2008
e2kcpu wrote:
> I thought you have already boards with 2901/2903 in CPLDs ?
>
>
The real ones are cheap! This was a PROM, 2901 design
but I am using a CPLD rather than 512x8 proms since
I have the CPLD development kit here.
I know that 2901's can be synthesized but I don't have
a VHDL or VERLOG compiler.
> Cheers
>
------------------------------------

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 )
Re: Re: Big CPUs in Small FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 13:03:35 2008
Rick Collins wrote:
> --- In f...@yahoogroups.com, "bfranchuk@..." wrote:
>
>> Well I like CPLD's rather than FPGA's since you don't need a boot
>> prom for the CPLD's.
>>
>
> You don't have to use a boot prom. There are a number of flash based
> FPGAs from Lattice and Altera makes some parts that are more FPGA than
> CPLD and are flash based. Check out the Lattice XP and XP2 devices.
> No boot prom required. They have both SRAM and Flash, so you can run
> the FPGA from SRAM while updating the Flash without disruption.
>
I have not looked at the newer stuff in about 5 years.
That was when I got CPLD deveopment kit.

>> The maintance manuals for the PDP's are on-line
>> http://bitsavers.trailing-edge.com/ I suspect that is where to start
>> as well as looking at Simh for emulation as the hardware for the old
>> machines had a lot of gota ya's design features based on qurks of the
>> hardware used. A simple PDP8 with 4K of memory is easy ...
>> A full featured one with hardware floating point, 32K of memory
>> and timeshareing hardware is very tricky make right.
>>
>
> Any idea how many LUTs a PDP8 would be?
>
>
Lots because of the random control logic and complex registers.
Some body has done a FPGA version on the web so look there.
> 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 )
Re: Re: Big CPUs in Small FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 13:12:34 2008
b...@jetnet.ab.ca wrote:
>>>
>>>
>> Any idea how many LUTs a PDP8 would be?
>>
>>
>>
> Lots because of the random control logic and complex registers.
> Some body has done a FPGA version on the web so look there.
>
>> Rick
>>
start here pdp8/x
http://homepage.mac.com/dgcx/pdp8x/

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

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 )
Re: Big CPUs in Small FPGAs - e2kcpu - Aug 10 13:16:07 2008
--- In f...@yahoogroups.com, "bfranchuk@..." wrote:
>
> I know that 2901's can be synthesized but I don't have
> a VHDL or VERLOG compiler.
Why ?
------------------------------------

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Small CPUs in FPGAs - e2kcpu - Aug 10 14:20:42 2008
--- In f...@yahoogroups.com, "Rick Collins" wrote:
>
> [xr16 ...] was completely published
> and an LCC port was provided. The gr0040 was not fully documented and
> the web site even says the compiler was ported, but not provided.

Did you get a response from Jan Gray, if he even thinks about
releasing the gr0040, gr0050 and tools ?
------------------------------------

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 )
Re: Big CPUs in Small FPGAs - rtstofer - Aug 10 14:50:25 2008

> Even with out front panels, here is some food for thought
> for a nice machine that is begging to be re-implimented again
> in hardware.
>
> -------------------
> Those with an interest in the ETH Lilith Modula-2 should point
their FTP
> clients to
> ftp://jdreesen.dyndns.org/ftp/lilith
>
> where they will find plenty of data concerning that machine.
>
> Most important is a binary image of the Lilith Systemdisk, and a
> directory containing all files ( more then 700..) of that
systemdisk.
>
> Among these files are :
>
> Medos binaries and source code.
> Modula-2 compiler binaries with source code.
> Lilith system utilities with source code.
> Bootfiles and system files.
> Microcode sources and assembler
> Manual
> Also available are hardware docu and some screenshots.
>
> Enjoy ,
>
> Jos Dreesen
>
> Server is on a basic DSL line, so download speeds will vary....
> ---------------
>

I have always been a huge fan of Niklaus Wirth and I have attempted
to build a similar processor for the P4 P-Code. I really liked using
UCSD Pascal in the early days until the licenses were revoked.
Bummer...

The Lilith project is VERY interesting. It will be quite easy to
increase the speed by an order of magnitude. The 64 bit memory will
be an issue when using FPGA development boards. I'll have to look
into that.

I have been banging your DSL all morning downloading everything in
sight.

The only retro projects I am excited about are those with complete
software.

I'm going to be looking very hard at this project.

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 )
Re: Big CPUs in Small FPGAs - e2kcpu - Aug 10 17:29:01 2008
--- In f...@yahoogroups.com, "rtstofer" wrote:
> The Lilith project is VERY interesting. It will be quite easy to
> increase the speed by an order of magnitude. The 64 bit memory will
> be an issue when using FPGA development boards. I'll have to look
> into that.

Most newer boards have 32 bit wide DDR RAM.
So, you wouldn't even notice, just in case you like to write the
controller for it ;-)

cheers

P.S. The other "doable" is the XILINX-DSP platform ($295). Just add 64
bit wide SRAM to it.
------------------------------------

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Big CPUs in Small FPGAs - rtstofer - Aug 10 17:55:45 2008
--- In f...@yahoogroups.com, "e2kcpu" wrote:
>
> --- In f...@yahoogroups.com, "rtstofer" wrote:
> > The Lilith project is VERY interesting. It will be quite easy to
> > increase the speed by an order of magnitude. The 64 bit memory will
> > be an issue when using FPGA development boards. I'll have to look
> > into that.
>
> Most newer boards have 32 bit wide DDR RAM.
> So, you wouldn't even notice, just in case you like to write the
> controller for it ;-)
>
> cheers
>
> P.S. The other "doable" is the XILINX-DSP platform ($295). Just add 64
> bit wide SRAM to it.
>

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

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 )
Re: Big CPUs in Small FPGAs - rtstofer - Aug 10 17:58:54 2008
--- In f...@yahoogroups.com, "e2kcpu" wrote:
>
> --- In f...@yahoogroups.com, "rtstofer" wrote:
> > The Lilith project is VERY interesting. It will be quite easy to
> > increase the speed by an order of magnitude. The 64 bit memory will
> > be an issue when using FPGA development boards. I'll have to look
> > into that.
>
> Most newer boards have 32 bit wide DDR RAM.
> So, you wouldn't even notice, just in case you like to write the
> controller for it ;-)

Something went over my head... How do I get from a 32 bit DDR RAM (or
SRAM for that matter) to 64 bit and still have one memory cycle per
access?

> P.S. The other "doable" is the XILINX-DSP platform ($295). Just add 64
> bit wide SRAM to it.

I'll go on a hunt in a few minutes. The price is not a concern (as
long as I only need one!) but I might not be able to find a
development board. If the device uses a BGA package, it would be a
show-stopper for me.

Richard

>

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

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: Big CPUs in Small FPGAs - Austin Franklin - Aug 10 18:07:49 2008
Hi Richard

> Something went over my head... How do I get from a 32 bit DDR RAM (or
> SRAM for that matter) to 64 bit and still have one memory cycle per
> access?

DDR means "Double Data Rate", so each edge of the cycle, one low to high
(rising), and one high to low (falling), gives you 32 bits...both give you
64...so:

2 edges/cycle x 32 bits/edge = 64 bits/cycle

Regards,

Austin
------------------------------------

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 )
Re: Small CPUs in FPGAs - Rick Collins - Aug 10 19:16:52 2008
--- In f...@yahoogroups.com, "e2kcpu" wrote:
>
> --- In f...@yahoogroups.com, "Rick Collins" wrote:
> >
> > [xr16 ...] was completely published
> > and an LCC port was provided. The gr0040 was not fully documented and
> > the web site even says the compiler was ported, but not provided.
>
> Did you get a response from Jan Gray, if he even thinks about
> releasing the gr0040, gr0050 and tools ?

No word. I have mentioned this in different web groups and I thought
I had sent an email, but I can't seem to find it. I guess I am just
thinking of web posts that were directed to him.

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

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Big CPUs in Small FPGAs - rtstofer - Aug 10 21:04:09 2008
--- In f...@yahoogroups.com, "Austin Franklin"
wrote:
>
> Hi Richard
>
> > Something went over my head... How do I get from a 32 bit DDR RAM (or
> > SRAM for that matter) to 64 bit and still have one memory cycle per
> > access?
>
> DDR means "Double Data Rate", so each edge of the cycle, one low to high
> (rising), and one high to low (falling), gives you 32 bits...both
give you
> 64...so:
>
> 2 edges/cycle x 32 bits/edge = 64 bits/cycle
>
> Regards,
>
> Austin
>

Ah...(slap forehead, etc)

I'll look at the Digilent offerings and see what's available.

Richard

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

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Big CPUs in Small FPGAs - e2kcpu - Aug 11 7:09:47 2008
--- In f...@yahoogroups.com, "rtstofer" wrote:
> > P.S. The other "doable" is the XILINX-DSP platform ($295). Just add 64
> > bit wide SRAM to it.
>
> I'll go on a hunt in a few minutes. The price is not a concern (as
> long as I only need one!) but I might not be able to find a
> development board. If the device uses a BGA package, it would be a
> show-stopper for me.

It uses an FPGA package. The reason I mentioned it is, the FPGA on it
is a Spartan3-DSP and has already 1.5 MBit Blockram. It should be
enough for a lot of uCode & Code ...
So not external memory needed for the start.
------------------------------------

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 )
Re: Big CPUs in Small FPGAs - rtstofer - Aug 11 10:04:52 2008
--- In f...@yahoogroups.com, "e2kcpu" wrote:
>
> --- In f...@yahoogroups.com, "rtstofer" wrote:
> > > P.S. The other "doable" is the XILINX-DSP platform ($295). Just
add 64
> > > bit wide SRAM to it.
> >
> > I'll go on a hunt in a few minutes. The price is not a concern (as
> > long as I only need one!) but I might not be able to find a
> > development board. If the device uses a BGA package, it would be a
> > show-stopper for me.
>
> It uses an FPGA package. The reason I mentioned it is, the FPGA on it
> is a Spartan3-DSP and has already 1.5 MBit Blockram. It should be
> enough for a lot of uCode & Code ...
> So not external memory needed for the start.
>

I found the Spartan 3A Starter Board on the Xilinx site. As you said,
it has everything necessary for a project like this.

Using the Avnet System ACE Module saves the design effort for creating
a Compact Flash device for the file system. $125.

The Lilith project requires 32k 64-bit quadwords so the Spartan 3A DSP
BlockRAM is not quite large enough. But it is large enough for
another project I have built where I shortchanged the RAM to avoid
using the onboard SRAM (I always intended to revisit this issue).

Assuming I can find a DDR core, there is more than enough DDR RAM on
the board so I can see where this could become my new favorite board.

I'm going to re-synthesize my old project for the new chip and see how
it comes out. It should fit easily!

Thanks for the info!

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 )
Re: Big CPUs in Small FPGAs - e2kcpu - Aug 11 10:30:49 2008
--- In f...@yahoogroups.com, "rtstofer" wrote:

> The Lilith project requires 32k 64-bit quadwords so the Spartan 3A DSP
> BlockRAM is not quite large enough. But it is large enough for
> another project I have built where I shortchanged the RAM to avoid
> using the onboard SRAM (I always intended to revisit this issue).
>
> Assuming I can find a DDR core, there is more than enough DDR RAM on
> the board so I can see where this could become my new favorite board.

That's the tough part. Nobody published a DDR2 Core yet !

> I'm going to re-synthesize my old project for the new chip and see how
> it comes out. It should fit easily!

PDP or the cpm system ?

BTW, I'm thinking of making EXP-SRAM board. 64 bit wide, and also some
C and SD-flash connectors.

Cheers
------------------------------------

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 )
Re: Big CPUs in Small FPGAs - rtstofer - Aug 11 14:56:31 2008
--- In f...@yahoogroups.com, "e2kcpu" wrote:

> > I'm going to re-synthesize my old project for the new chip and see
how
> > it comes out. It should fit easily!
>
> PDP or the cpm system ?

IBM1130 - the first computer I ever used programmed, circa 1969.

I started looking at the PDP project and coded the ALU but somehow the
project never really caught my fancy. Running Unix V6 would be a trip
but other projects got in the way.

>
> BTW, I'm thinking of making EXP-SRAM board. 64 bit wide, and also some
> C and SD-flash connectors.
>

Given the number of user IO lines (168) on the Spartan 3A DSP Starter
Board, it is probably quite easy to add SRAM. I'm not sure where to
get the mating Samtec connectors.

I guess I would build a 'bridge' board for SRAM and a Compact Flash
device.

Leaving the internal BlockRAM unused (for the most part) makes me want
to build a logic analyzer into the project. Something along the lines
of http://www.sump.org/projects/analyzer/

Richard

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

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

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Big CPUs in Small FPGAs - rtstofer - Aug 11 16:12:42 2008
--- In f...@yahoogroups.com, "e2kcpu" wrote:

> > I'm going to re-synthesize my old project for the new chip and see
how
> > it comes out. It should fit easily!
>
> PDP or the cpm system ?

IBM 1130 - the first computer I ever programmed, circa 1969.

>
> BTW, I'm thinking of making EXP-SRAM board. 64 bit wide, and also some
> C and SD-flash connectors.

If I can find the Samtec connectors, I think I will build a 'bridge'
board for SRAM and a Compact Flash socket. There are plenty of user IO
lines (168) so a 32k x 64 bit SRAM memory can be built pretty easy.

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 )
Re: Re: Big CPUs in Small FPGAs - "bfr...@jetnet.ab.ca" - Aug 11 16:38:57 2008
rtstofer wrote:
> IBM1130 - the first computer I ever used programmed, circa 1969.
>
>
I used one of them things in 1980, the PC of the day (1969)
- Dual floppy,64kb and a printer. :)
> I started looking at the PDP project and coded the ALU but somehow the
> project never really caught my fancy. Running Unix V6 would be a trip
> but other projects got in the way.
>
>
Some how after V6 everything became BLOAT-NIX.
(Looking for C compiler source that fits in 64K code and 64K data space
cause thats all I have in the CPU I'm building)
> 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 )
Re: Big CPUs in Small FPGAs - rtstofer - Aug 11 17:15:19 2008
--- In f...@yahoogroups.com, "bfranchuk@..." wrote:

> (Looking for C compiler source that fits in 64K code and 64K data
space
> cause thats all I have in the CPU I'm building)

There are decent C compilers for the 8080/Z80 platform. 64k is easily
doable. But I have never check to see if these compilers implement
the full ANSI C. Maybe not.

Heck, there's even a PL/I compiler by Digital Research.

On the IBM 1130, the Fortran compiler made 27 passes! The card images
were held in core and converted in-situ to tokens. That kind of
limited the size of the source program. Especially on machines with
limited RAM.

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 )
Re: Re: Big CPUs in Small FPGAs - Jon Kirwan - Aug 11 17:16:30 2008
On Mon, 11 Aug 2008 15:33:50 -0000, rtstofer wrote:

>IBM1130 - the first computer I ever used programmed, circa 1969.

That takes me back! I used to swap the differently colored and
labeled bezels over the light bulbs (easy to do) just to be a pain to
the system operator. Used assembly and FORTRAN II on that machine --
university "math with fortran" classes got me access.

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 )
Re: Re: Big CPUs in Small FPGAs - "bfr...@jetnet.ab.ca" - Aug 11 17:47:58 2008
rtstofer wrote:
> --- In f...@yahoogroups.com, "bfranchuk@..." wrote:
>
>
>> (Looking for C compiler source that fits in 64K code and 64K data
>>
> space
>
>> cause thats all I have in the CPU I'm building)
>>
>
> There are decent C compilers for the 8080/Z80 platform. 64k is easily
> doable. But I have never check to see if these compilers implement
> the full ANSI C. Maybe not.
>
>
Most of what I have seen is cross compilers for
the micro computers.
> Heck, there's even a PL/I compiler by Digital Research.
>
>
I'll take almost any source , other than Jim Hendrix's Small C.
I could never figure that mess out. The original small C I like.
> On the IBM 1130, the Fortran compiler made 27 passes! The card images
> were held in core and converted in-situ to tokens. That kind of
> limited the size of the source program. Especially on machines with
> limited RAM.
>
> Richard
>
>
When I am done, I just have the bare machine ...
lights and switches of and memory of course

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

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 )
Re: Big CPUs in Small FPGAs - rtstofer - Aug 11 18:30:11 2008
--- In f...@yahoogroups.com, "bfranchuk@..." wrote:

> When I am done, I just have the bare machine ...
> lights and switches of and memory of course
>

That's not unlike the very earliest days of the Altair 8800. We had
256 BYTES of RAM and could use it any way we could toggle.

Things looked up fast when Digital Research release CP/M with an
editor and assembler, followed shortly by a macro assembler and,
eventually, PL/I. But everyone really wanted PL/M.

If I were bringing up bare iron, I would probably look for a cross
assembler, preferably with macro capability. I might look at GAS.

With a macro assembler I could implement many of the control
structures of higher level languages (WHILE-DO, IF-THE-ELSE,
REPEAT-UNTIL, etc) as well as data structures.

My favorite next step was to bring up Palo Alto Tiny BASIC. Then I
had something I could work with.

If that wasn't an option, I might try to port LCC. If I wasn't smart
enough to do that, I might implement a toy language like the limited
Pascal in "Algorithms + Data Structures = Programs" or just create a
language using YACC and BISON. There are C like examples around. A
cross-compiler it would have to be until I could port it to the iron.

I bought the LCC book but haven't had a need to read it. One of these
days...

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 )
Re: Re: Big CPUs in Small FPGAs - Hellwig Geisse - Aug 11 20:21:29 2008
On Mon, 2008-08-11 at 15:33 +0000, rtstofer wrote:

> Leaving the internal BlockRAM unused (for the most part) makes me
> want
> to build a logic analyzer into the project. Something along the lines
> of http://www.sump.org/projects/analyzer/

I did something similar some time ago and published it
on [xsboard-users], a yahoo group for users of the XESS
boards, with the following announcement:

A few months ago, during the development of my 32-bit CPU,
I ran across a problem for which the solution might be of
general interest for some of you. My design had an error
which inhibited even the very first instruction fetch.
Simulations were of no help; they seemed to run without
errors. So I wished I had a logic analyzer to look into
the FPGA...

I came up with the following idea, which undoubtedly others
have employed as well: I implemented a bare-bones logic
analyzer on the FPGA itself, which samples up to 128 channels
synchronously into 4 block RAMs (which provide a depth of
512 values). The sampling process starts when a trigger signal
is received, and it is qualified with an enable signal, so that
uninteresting clock cycles can be skipped. When the sample
buffer is full, the samples are serially transmitted to a PC
where they are written to a file. I also wrote a simple viewing
program to list the sample values in hex.

This design is for sure no masterpiece in digital logic, but
it served its purpose well - I found the error almost instantly.

If you are interested, you can find my logic analyzer here:
http://homepages.fh-giessen.de/~hg53/LogiProbe
Please feel free to use it as you wish. I would be glad if
it could be of help for someone.

Best regards,
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 )
Re: Small CPUs in FPGAs - e2kcpu - Aug 17 9:20:47 2008
--- In f...@yahoogroups.com, "Rick Collins" wrote:
>
> Perhaps you are thinking of the xr16? That was completely published
> and an LCC port was provided. The gr0040 was not fully documented and
> the web site even says the compiler was ported, but not provided.
>
Why do you actually prefer the gr0040 over the xr16 ?
(license issues aside)
Personally, I like the three address instructions.
Save a lot on my codes ...

Cheers
------------------------------------

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 )
Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 17 12:41:10 2008
e2kcpu wrote:
> --- In f...@yahoogroups.com, "Rick Collins" wrote:
>
> Personally, I like the three address instructions.
> Save a lot on my codes ...
>
> Cheers
>
But do you really need general purpose 3 address instructions?
Most of the time I think of the 3'rd address used, it becomes a
software stack. It might be handy to make that a stack and save
few address bits at the cost of slighty different addressing modes.
------------------------------------

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 )
Re: Parallel Search Processor. - Tirath Ramdas - Aug 23 12:33:23 2008
I heard Prof. Ruby Lee (Princeton) speak at a conference recently,
and I think she has some things on parallel LUTs that might interest
you, e.g: http://portal.acm.org/citation.cfm?
id=1097107.1097149&coll=GUIDE&dl=GUIDE&CFID=81295850&CFTOKEN=18497411

-tirath

On 08/08/2008, at 9:02 PM, John Kent wrote:

> 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 )
Re: Parallel Search Processor. - John Kent - Aug 24 5:12:00 2008
Hi Tirath

I looked up the article on the IEEE Xplore web site. It's actually an
IEEE paper rather than ACM, but I found the citation on the ACM Portal
using the link you gave me. I'll have a read. I seems to be oriented
towards encryption, but I'm sure it can be used for other applications.
I'm sorry for the delay in responding. Your email is dated the 8th
August 2008 (08,08,08) but I did not receive it until today. 2008-08-24.

John.

Tirath Ramdas wrote:
> I heard Prof. Ruby Lee (Princeton) speak at a conference recently,
> and I think she has some things on parallel LUTs that might interest
> you, e.g: http://portal.acm.org/citation.cfm?
> id=1097107.1097149&coll=GUIDE&dl=GUIDE&CFID=81295850&CFTOKEN=18497411
>
> -tirath
>
>

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

Sign in

Search fpga-cpu

Subscribe to fpga-cpu

fpga-cpu by Keywords

Sponsor

Ads

Discussion Groups

See Also

Discussion Groups | FPGA-CPU | Small CPUs in FPGAs

Small CPUs in FPGAs - Rick Collins - Jul 31 10:18:48 2008

Re: Small CPUs in FPGAs - Leon - Jul 31 11:47:10 2008

Re: Small CPUs in FPGAs - Hellwig Geisse - Jul 31 12:06:30 2008

Re: Small CPUs in FPGAs - Tommy Thorn - Jul 31 12:19:52 2008

YARI was: Small CPUs in FPGAs - Tommy Thorn - Jul 31 12:45:23 2008

Re: Small CPUs in FPGAs - Rick Collins - Jul 31 12:54:36 2008

Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Jul 31 13:03:11 2008

Re: Small CPUs in FPGAs - Rick Collins - Jul 31 13:04:29 2008

Re: Small CPUs in FPGAs - Hellwig Geisse - Aug 2 3:52:06 2008

Re: Small CPUs in FPGAs - Yashwant Shitoot - Aug 2 5:11:52 2008

Re: Small CPUs in FPGAs - Rick Collins - Aug 2 8:57:11 2008

Re: Small CPUs in FPGAs - rtstofer - Aug 2 16:55:53 2008

Re: Small CPUs in FPGAs - Rick Collins - Aug 2 17:28:22 2008

Re: Small CPUs in FPGAs - rtstofer - Aug 2 19:24:51 2008

Re: Re: Small CPUs in FPGAs - Tommy Thorn - Aug 2 19:36:11 2008

Re: Small CPUs in FPGAs - Jon Kirwan - Aug 2 20:57:39 2008

Re: Small CPUs in FPGAs - Rick Collins - Aug 2 21:26:57 2008

Re: Re: Small CPUs in FPGAs - John Kent - Aug 2 23:10:54 2008

Re: Re: Small CPUs in FPGAs - John Kent - Aug 3 0:09:25 2008

Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 3 0:30:49 2008

Re: Re: Small CPUs in FPGAs - Tommy Thorn - Aug 3 1:54:54 2008

Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 3 12:55:55 2008

RE: Re: Small CPUs in FPGAs - Jan Gray - Aug 3 23:06:53 2008

Re: Small CPUs in FPGAs - Rick Collins - Aug 3 23:27:00 2008

Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 3 23:52:25 2008

Re: Small CPUs in FPGAs - rtstofer - Aug 4 0:43:28 2008

Re: Re: Small CPUs in FPGAs - John Kent - Aug 4 0:58:28 2008

RE: Re: Small CPUs in FPGAs - Jan Gray - Aug 4 7:55:02 2008

Re: Small CPUs in FPGAs - Rick Collins - Aug 4 10:05:05 2008

Re: Small CPUs in FPGAs - Rick Collins - Aug 4 11:47:06 2008

Re: Small CPUs in FPGAs - Rick Collins - Aug 4 12:29:33 2008

Re: Re: Small CPUs in FPGAs - John Kent - Aug 4 20:12:18 2008

Re: Re: Small CPUs in FPGAs - John Kent - Aug 6 2:33:02 2008

Re: Re: Small CPUs in FPGAs - Martin Schoeberl - Aug 6 5:15:11 2008

Re: Small CPUs in FPGAs - Philip Freidin - Aug 6 7:47:29 2008

Re: Small CPUs in FPGAs - rtstofer - Aug 6 11:22:47 2008

Re: Re: Small CPUs in FPGAs - John Kent - Aug 7 7:57:03 2008

Re: Re: Small CPUs in FPGAs - John Kent - Aug 7 8:04:16 2008

Re: Small CPUs in FPGAs - rtstofer - Aug 7 10:21:46 2008

Re: Re: Small CPUs in FPGAs - Veronica Merryfield - Aug 7 12:45:45 2008

Re: Small CPUs in FPGAs - rtstofer - Aug 7 13:47:46 2008

Re: Re: Small CPUs in FPGAs - John Kent - Aug 8 0:30:57 2008

Parallel Search Processor. - John Kent - Aug 8 7:02:43 2008

Re: Parallel Search Processor. - Kolja Sulimma - Aug 8 8:31:20 2008

Re: Parallel Search Processor. - John Kent - Aug 8 23:48:28 2008

Re: Small CPUs in FPGAs - Brian Davis - Aug 9 0:23:26 2008

Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 9 0:35:41 2008

Re: Small CPUs in FPGAs - Brian Davis - Aug 9 0:38:11 2008

Re: Re: Small CPUs in FPGAs - Martin Schoeberl - Aug 9 5:07:51 2008

Re: Re: Small CPUs in FPGAs - John Kent - Aug 9 10:46:48 2008

Re: Small CPUs in FPGAs - rtstofer - Aug 9 10:58:37 2008

Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 9 12:56:08 2008

Re: Small CPUs in FPGAs - Brian Davis - Aug 9 15:17:10 2008

Re: Small CPUs in FPGAs - rtstofer - Aug 9 16:27:00 2008

Re: Small CPUs in FPGAs - Philip Freidin - Aug 9 23:38:34 2008

Re: Big CPUs in Small FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 3:33:46 2008

Re: Re: Small CPUs in FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 3:37:58 2008

Re: Big CPUs in Small FPGAs - John Kent - Aug 10 4:01:56 2008

Re: Big CPUs in Small FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 4:14:43 2008

Re: Big CPUs in Small FPGAs - John Kent - Aug 10 4:20:08 2008

Re: Big CPUs in Small FPGAs - John Kent - Aug 10 4:23:04 2008

Re: Small CPUs in FPGAs - e2kcpu - Aug 10 8:01:30 2008

Re: Small CPUs in FPGAs - e2kcpu - Aug 10 8:04:22 2008

Re: Big CPUs in Small FPGAs - e2kcpu - Aug 10 8:22:20 2008

Re: Re: Small CPUs in FPGAs - Hellwig Geisse - Aug 10 8:55:36 2008

Re: Small CPUs in FPGAs - e2kcpu - Aug 10 10:04:50 2008

Re: Re: Small CPUs in FPGAs - Hellwig Geisse - Aug 10 10:53:15 2008

Re: Small CPUs in FPGAs - Rick Collins - Aug 10 11:57:12 2008

Re: Small CPUs in FPGAs - e2kcpu - Aug 10 12:35:34 2008

Re: Big CPUs in Small FPGAs - "bfr...@jetnet.ab.ca" - Aug 10 12:49:43 2008

Re: Small CPUs in FPGAs - e2kcpu - Aug 10 12:51:14 2008