Sign in

username:

password:



Not a member?

Search fpga-cpu



Search tips

Subscribe to fpga-cpu



fpga-cpu by Keywords

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

Ads

Discussion Groups

Discussion Groups | FPGA-CPU | related to 16-bit fpga cpu development

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

related to 16-bit fpga cpu development - Umair siddiqui - Oct 11 5:17:00 2004


First of all thanks for reply.
Well I want to mimic the Mr.Gray's x16 and MIPS(as
discribed in "Computer Organization and Design
The Hardware/Software Interface", 2nd Ed By
David Patterson and John Hennessy).
My Constraint is that I specified in project proposal
that RISC are more suitable than CISC and I'll be
making RISC...Besides x16 is also RISC and Book is
recommanded by Mr.Gray (in Article).

My Qestion are:
1) Are Stack-based cpus are more complex than RISC?
is writing software for stack-based is easy as
compared
to RISC?

2) I've learned (intermediate level)c++, java
programming but never worked with forth,
so how is the learning curve of Forth? recommended
Forth tools (Win32), Books, other learning resources?

3) porting GCC C-compiler to x16 or any custumized
architecture(optimzed for fpga) HOWTO -- as it is also
retargetable?
/////////////////////////////////////////////////////
Please Note that
-CPU should be compatible to x16
-I have build similar system like xsoc -- with
vga/lcd, keyboard and serial port
_______________________________






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


Re: related to 16-bit fpga cpu development - Arius - Rick Collins - Oct 13 14:08:00 2004

At 06:17 AM 10/11/2004, you wrote:
>First of all thanks for reply.
>Well I want to mimic the Mr.Gray's x16 and MIPS(as
>discribed in "Computer Organization and Design
>The Hardware/Software Interface", 2nd Ed By
>David Patterson and John Hennessy).
>My Constraint is that I specified in project proposal
>that RISC are more suitable than CISC and I'll be
>making RISC...Besides x16 is also RISC and Book is
>recommanded by Mr.Gray (in Article).
>
>My Qestion are:
>1) Are Stack-based cpus are more complex than RISC?
>is writing software for stack-based is easy as
>compared
>to RISC?
>
>2) I've learned (intermediate level)c++, java
>programming but never worked with forth,
>so how is the learning curve of Forth? recommended
>Forth tools (Win32), Books, other learning resources?
>
>3) porting GCC C-compiler to x16 or any custumized
>architecture(optimzed for fpga) HOWTO -- as it is also
>retargetable?
>/////////////////////////////////////////////////////
>Please Note that
>-CPU should be compatible to x16
>-I have build similar system like xsoc -- with
>vga/lcd, keyboard and serial port

I am not sure what you mean by "compatible". First, I want to make sure we
are talking about the same CPU design. Jan Gray designed an xr16 CPU, not
an x16. This is a 16 bit RISC CPU with 16 registers and a three stage
pipeline.

I belive you are trying to compare designing a stack based CPU (some call
this a MISC - minimal instruction set computer) to designing a RISC CPU. A
stack CPU can be simpler than a RISC CPU if done with minimization in
mind. Since the operands are implied (the stack), instructions can be much
shorter by eliminating the register fields from the opcodes. Often a 5 to
8 bit opcode is used.

You don't have to use Forth with a stack CPU just as a RISC CPU does not
require the use of a C complier. You can use either language with either
design. Forth is very different from other languages, but not hard. If
you are interested, download one of the many Forths available and try it
out on your PC. Spend an hour a day learning it and you will have a good
idea of what Forth is about by the end of a week.

BTW, there is a CPU design project going on to make a "clone" of the Xilinx
microBlaze RISC CPU. You might want to get involved in that.
Rick Collins
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX




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

Re: related to 16-bit fpga cpu development - rtstofer - Oct 13 23:01:00 2004


--- In , Umair siddiqui
<umairsiddiqui0800@y...> wrote:
>
> First of all thanks for reply.
> Well I want to mimic the Mr.Gray's x16 and MIPS(as
> discribed in "Computer Organization and Design
> The Hardware/Software Interface", 2nd Ed By
> David Patterson and John Hennessy).
> My Constraint is that I specified in project proposal
> that RISC are more suitable than CISC and I'll be
> making RISC...Besides x16 is also RISC and Book is
> recommanded by Mr.Gray (in Article).

One of the scary things about immitating this design is the
complexity. It is a very complex CPU that, due to the pipelining,
has to deal with issues like register interlocking, inserting NOPs
and things like that. A very advanced design by a very accomplished
designer. We're talking about mega doses of steroids pumped into a
Von Neumann machine. > My Qestion are:
> 1) Are Stack-based cpus are more complex than RISC?
> is writing software for stack-based is easy as
> compared
> to RISC?

I don't think stack based CPUs are more complex than RISC or CISC
but I think there are less fully developed examples around to
immitate. Not just in terms of hardware but in terms of software
tools. A long time ago Burroughs computers were stack oriented and
I think they used Algol but I could be way off on that.

As to RISC vs CISC - well that is a matter of conjecture in terms of
designing the CPU. After all, they are both implemented with state
machines. In my opinion, the selling point for RISC is that the
smaller, more regular, instruction set lends itself to pipelining
and speed. At the application level, programs still want to move
strings, extract characters from words or strings, and so forth. If
the instruction set contains string oriented op codes the execution
is probably pretty quick. If the instruction set omits op codes
then they have to be created from the more primitive codes. It
still has to be done. > 2) I've learned (intermediate level)c++, java
> programming but never worked with forth,
> so how is the learning curve of Forth? recommended
> Forth tools (Win32), Books, other learning resources? Forth is a non-starter, in my opinion. It has the advantage of an
integrated enviornment (a text editor) as does Basic. But Forth is
implemented bottom-up. The low level primitives have to be written
first and higher levels of code stacked on top. This is somewhat
contrary to top-down structured programming.

However, I have seen an elegant use of Forth: many years ago one of
the early hard disk manufacturers used it for all of their
diagnostic software at test stations. Here, the bottom-up approach
was perfect: write some code to read and write ports, layer it with
code to read and write sectors and layer that with code to debug the
disk. These test stations were quite nice and using Forth, new
diagnostics could be written in seconds because everything was
written in terms of known working primitives.

It remains a question to me whether a Pascal compiler could be
written in Forth and if it was whether any person other than the
writer could figure out how it worked.

Also, I believe Forth is an interpreted language. I don't think it
generates machine code. So, you would have to design some hardware
that would be sufficient to run Forth as compiled by a compiler that
doesn't exist for the hardware you are designing. You would be
creating 2 layers of software instead of one.

> 3) porting GCC C-compiler to x16 or any custumized
> architecture(optimzed for fpga) HOWTO -- as it is also
> retargetable?

Yes, GCC is retargetable but there is a reason Mr Gray chose LCC,
the retargetable C compiler. There is a book written by Fraser and
Hanson titled "A Retargetable C Compiler: Design and Implmentation"
that walks through the entire process detailing every piece that
needs to be implemented.

The only issue I see with either GCC or LCC is that they are
complete languages implementing every feature of ANSI C. So, the
assumptions they make about the capabilities of hardware in terms of
stack, index registers, base registers, etc. means you have to
implement a pretty complete machine. Like a MIPS or X16.

I still like the idea of a tiny language and a language oriented
CPU. The more I think about it, the more I would recommend the tiny
Pascal compiler/interpreter in Wirth's "Algorithms + Data Structures
= Programs". The CPU would have to implement 8 basic instructions
and 13 operators. To the basic language there would need to be a
couple of standard procedures/functions to read and write ports and
perhaps read and write files.

In my concept the interpreter would run in hardware. There would be
boot code and perhaps a command interpreter placed in Block RAM so
the machine could start interpreting directly at boot. If the
standard procedures/functions for PORT I/O are implemented then the
command processor could do things like read or write a hard drive
(probably a Compact Flash - I love those things) to load other code
for execution. Note that the PL0 compiler can not compile the
compiler so code will have to be written on a PC and executed on the
FPGA. The PL0 compiler itself is only 10 pages of text so it isn't
a huge project to get it running on a PC, whether Linux or Windows
using some Pascal compiler such as FreePascal (www.freepascal.org).

The Xilinx Starter Board comes with a VGA display and the VHDL code
is provided. Keyboard code is available at www.opencores.org as is
a very nice serial port as a component of the T80 project.

What you could wind up with is an implementation of a language
oriented computer that is extensible in the sense that the full
Pascal language as implemented by Wirth, et al. could eventually be
developed.

I am planning to build the original Wirth Pascal system for my own
purposes but, thinking about it, maybe I will do the PL0 system
first and see where it leads.

> /////////////////////////////////////////////////////
> Please Note that
> -CPU should be compatible to x16
> -I have build similar system like xsoc -- with
> vga/lcd, keyboard and serial port

The Xilinx Spartan 3 Starter Board has all these ports - nothing to
add, hardware wise except the code to drive them. >
>
> _______________________________






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

Re: related to 16-bit fpga cpu development - rtstofer - Oct 13 23:04:00 2004



Rick,

I am very interested in any possibility of working with a clone of
the microBlaze as there is no way I can afford to license the
thing. Where can I find more information? Opencores?

Richard

> BTW, there is a CPU design project going on to make a "clone" of
the Xilinx
> microBlaze RISC CPU. You might want to get involved in that. >
> Rick Collins
>
> rick.collins@a...
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX






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

Re: Re: related to 16-bit fpga cpu development - Arius - Rick Collins - Oct 14 1:14:00 2004

At 12:01 AM 10/14/2004, you wrote:
> >
> > 2) I've learned (intermediate level)c++, java
> > programming but never worked with forth,
> > so how is the learning curve of Forth? recommended
> > Forth tools (Win32), Books, other learning resources?
> >
>
>Forth is a non-starter, in my opinion. It has the advantage of an
>integrated enviornment (a text editor) as does Basic. But Forth is
>implemented bottom-up. The low level primitives have to be written
>first and higher levels of code stacked on top. This is somewhat
>contrary to top-down structured programming.

I don't think you understand Forth very well. There is nothing about Forth
that requires a bottom up design any more than any other language. Most
people initially do a top down design decomposition with a bottom up
implementation because each module is then testable without constructing a
framework. But you can use all the standard top down techniques with Forth
just like any other language. >However, I have seen an elegant use of Forth: many years ago one of
>the early hard disk manufacturers used it for all of their
>diagnostic software at test stations. Here, the bottom-up approach
>was perfect: write some code to read and write ports, layer it with
>code to read and write sectors and layer that with code to debug the
>disk. These test stations were quite nice and using Forth, new
>diagnostics could be written in seconds because everything was
>written in terms of known working primitives.
>
>It remains a question to me whether a Pascal compiler could be
>written in Forth and if it was whether any person other than the
>writer could figure out how it worked.

Good thing you are not posting this to the Forth newsgroup. :) Forth is
only hard to read if you don't know anything about forth. People who have
worked with Forth for even a little bit can understand any program just as
well as a C program. In fact, I would say that because they are typically
decomposed into many small functions, most Forth programs are more easily
understood than your typical open-source C programs. >Also, I believe Forth is an interpreted language. I don't think it
>generates machine code. So, you would have to design some hardware
>that would be sufficient to run Forth as compiled by a compiler that
>doesn't exist for the hardware you are designing. You would be
>creating 2 layers of software instead of one.

There are many types of Forths. None that I am aware of are interpreted at
run time. Most are compiled (interpreted) to threaded code which can still
run efficiently. But if you are designing a stack machine, it can run
Forth as its native language with *no* threading. In fact, Chuck Moore has
designed a Forth that runs so fast, he does not have binary images that are
loaded at run time, when he switches applications, he recompiled the code
each time. It is so fast partly because the applications are so small, and
I am talking about chip design software.
Rick Collins
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX



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

Re: Re: related to 16-bit fpga cpu development - Arius - Rick Collins - Oct 14 1:16:00 2004

At 12:04 AM 10/14/2004, you wrote:
>Rick,
>
>I am very interested in any possibility of working with a clone of
>the microBlaze as there is no way I can afford to license the
>thing. Where can I find more information? Opencores?

I was not aware that Xilinx charged for the microBlaze... but maybe I am
thinking about the picoBlaze. In any event, this was discussed in the
comp.arch.fpga newsgroup. If you don't have ready access to that, I can
look it up for you and find some links. I belive they are planning on
hosting the design on opencores.org, but I don't think there is any code up
just yet.
Rick Collins
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX




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

Re: related to 16-bit fpga cpu development - rtstofer - Oct 14 1:56:00 2004


I think I can get to comp.arch.fpga but I haven't been to a
newsgroup like that in a long time.

I'm pretty sure there is a horrific licensing fee. I initially
thought the source came with the $500 EDK (?) package but that
doesn't seem to be the case. I've seen numbers in the $10k range
and, if you are a big manufacturer this may not be an issue for a
known functioning, fast, core; in fact, it is cheap compared to in-
house design. For the hobbyist it is out of the question.
PicoBlaze is free and apparently it can run on a CPLD. I don't know
what value that might have but it has been done.

The only versions of Forth I have ever used are for CP/M-80 and they
were interpreted. It's been along time. Yes, the editor enforced
modularity by limiting the screen to 16 lines or so. One screen per
function - period.

It's not so much that Forth can't be designed top down, it has to be
designed pretty much all the way down and implemented bottom up. In
a lot of ways it reminds me of programming for the HP48 calculator.

It's not a language I have used in the last 20 years or so and it
was never one of my favorites. About a day with it was all I could
take! I felt the same way about Lisp at the time and Perl even
today. Still, there are those that like them...

--- In , Arius - Rick Collins
<dsprelated@a...> wrote:
> At 12:04 AM 10/14/2004, you wrote:
> >Rick,
> >
> >I am very interested in any possibility of working with a clone of
> >the microBlaze as there is no way I can afford to license the
> >thing. Where can I find more information? Opencores?
>
> I was not aware that Xilinx charged for the microBlaze... but
maybe I am
> thinking about the picoBlaze. In any event, this was discussed in
the
> comp.arch.fpga newsgroup. If you don't have ready access to that,
I can
> look it up for you and find some links. I belive they are
planning on
> hosting the design on opencores.org, but I don't think there is
any code up
> just yet. >
> Rick Collins
>
> rick.collins@a...
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX






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

Re: Re: related to 16-bit fpga cpu development - Göran Bilski - Oct 14 1:59:00 2004

Hi,

For $500 you get the tools and around 60 peripherals most of them is
open-source.
MicroBlaze is included in this price but the source code is encrypted.
It will allow you to design to any Xilinx FPGA without any restrictions,
license fee or royalty.

Göran

rtstofer wrote:

>I think I can get to comp.arch.fpga but I haven't been to a
>newsgroup like that in a long time.
>
>I'm pretty sure there is a horrific licensing fee. I initially
>thought the source came with the $500 EDK (?) package but that
>doesn't seem to be the case. I've seen numbers in the $10k range
>and, if you are a big manufacturer this may not be an issue for a
>known functioning, fast, core; in fact, it is cheap compared to in-
>house design. For the hobbyist it is out of the question.
>PicoBlaze is free and apparently it can run on a CPLD. I don't know
>what value that might have but it has been done.
>
>The only versions of Forth I have ever used are for CP/M-80 and they
>were interpreted. It's been along time. Yes, the editor enforced
>modularity by limiting the screen to 16 lines or so. One screen per
>function - period.
>
>It's not so much that Forth can't be designed top down, it has to be
>designed pretty much all the way down and implemented bottom up. In
>a lot of ways it reminds me of programming for the HP48 calculator.
>
>It's not a language I have used in the last 20 years or so and it
>was never one of my favorites. About a day with it was all I could
>take! I felt the same way about Lisp at the time and Perl even
>today. Still, there are those that like them...
>
>--- In , Arius - Rick Collins
><dsprelated@a...> wrote: >>At 12:04 AM 10/14/2004, you wrote:
>>
>>
>>>Rick,
>>>
>>>I am very interested in any possibility of working with a clone of
>>>the microBlaze as there is no way I can afford to license the
>>>thing. Where can I find more information? Opencores?
>>>
>>>
>>I was not aware that Xilinx charged for the microBlaze... but
>>
>>
>maybe I am >>thinking about the picoBlaze. In any event, this was discussed in
>>
>>
>the >>comp.arch.fpga newsgroup. If you don't have ready access to that,
>>
>>
>I can >>look it up for you and find some links. I belive they are
>>
>>
>planning on >>hosting the design on opencores.org, but I don't think there is
>>
>>
>any code up >>just yet.
>>
>>
>>
>>Rick Collins
>>
>>rick.collins@a...
>>
>>Arius - A Signal Processing Solutions Company
>>Specializing in DSP and FPGA design http://www.arius.com
>>4 King Ave 301-682-7772 Voice
>>Frederick, MD 21701-3110 301-682-7666 FAX
>>
> >To post a message, send it to:
>To unsubscribe, send a blank message to:
>Yahoo! Groups Links >





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

Re: related to 16-bit fpga cpu development - Martin Schoeberl - Oct 14 2:45:00 2004

> My Qestion are:
> 1) Are Stack-based cpus are more complex than RISC?
> is writing software for stack-based is easy as
> compared
> to RISC?

No, a stack architecture is usually simpler to build. That's the reason for the small FORTH
chips. I've built a stack processor to implement the Java Virtual Machine, which is a stack
machine. The main advantage in an FPGA is that you only need one read and one write port
for the stack to support single cycle pipelining. For a RISC machine you need two read and
one write port. Of course this can be simulated by doubling the internal memory (use two
block RAMS with the same content) for the register file.
About writing software: With a Java processor you write software in Java, you don't have
to think about the stack architecture :-)

Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/





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

RE: Re: related to 16-bit fpga cpu development - Austin Franklin - Oct 14 7:49:00 2004

Hi Rick,

> I was not aware that Xilinx charged for the microBlaze...

Me either... I believe it comes with the EDK which is $500.

Regards,

Austin




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

Re: related to 16-bit fpga cpu development - Brian Davis - Oct 26 20:25:00 2004


rtstofer wrote:
>
> I still like the idea of a tiny language and a language oriented
> CPU. The more I think about it, the more I would recommend the
> tiny Pascal compiler/interpreter in Wirth's "Algorithms + Data
> Structures = Programs". The CPU would have to implement 8 basic
> instructions and 13 operators. Also of interest would be Wirth's simple Oberon-0 compiler
(hypothetical RISC target) found in:

"Compiler Construction", Wirth, Addison-Wesley 1996

Brian




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

Re: related to 16-bit fpga cpu development - rtstofer - Oct 26 20:40:00 2004



Off to the used book sellers... The hardware is getting to be the
cheap part.

--- In , "Brian Davis" <brimdavis@a...> wrote:
>
> rtstofer wrote:
> >
> > I still like the idea of a tiny language and a language oriented
> > CPU. The more I think about it, the more I would recommend the
> > tiny Pascal compiler/interpreter in Wirth's "Algorithms + Data
> > Structures = Programs". The CPU would have to implement 8 basic
> > instructions and 13 operators.
> >
>
> Also of interest would be Wirth's simple Oberon-0 compiler
> (hypothetical RISC target) found in:
>
> "Compiler Construction", Wirth, Addison-Wesley 1996
>
> Brian





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