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 | Java processor / RISC cpu

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

Java processor / RISC cpu - Martin Schoeberl - Mar 18 17:28:00 2003

Hi Josh,

an answer on the list again. I don't think it's off-topic and we don't annoy
anybody. This Java Processor _is_ a fpga cpu. So why not discuss it here?
Jan Gray has to decide :-)

As I forgot in the last message, a link to the processor:
http://www.jopdesign.com/

You can find some (little bit outdated) description of the processor. It is
part of a thesis and I'm currently writing on it. Perhaps more info in a few
weeks. But the sources (in VHDL) reflect the current design and you can
download them from the site.

Why do you want translate Java byte code to RISC instructions (on the fly
?)? Java byte codes lead to a simple cpu architecture. With the more complex
instructions you have to find a solution. But I think you only can translate
the simple (like 'iadd') to one or more RISC instructions. For instructions
like 'invokevirtual' you have to call a function, right?

As you are working on a similar project, perhaps we can share some ideas or
find new solutions for the problems.

Martin

> Hi Martin,
>
> (This is direct to you, outside the list... so we don't annoy people)
>
> It's interesting that you bring up Java; While this particular paper is
> necessarily about general-purpose RISC cores, it is the first step towards
a
> Java implementation. We have a novel architecture for a processor which
> will accept either Java or RISC input instruction streams... the Java
> bytecodes will be folded and translated to the RISC ISA for execution in
the
> RISC back end.
>
> To save time, we are going to go with a previously established RISC core,
> and the selection of that core is the real purpose behind writing this
> paper.
>
> Anyways: my point is that I _am_ interested in Java processing, just not
> necessarily for this particular paper.
>
> JP
>
> -----Original Message-----
> From: Martin Schoeberl [mailto:]
> Sent: March 18, 2003 9:10 AM
> To:
> Subject: Re: [fpga-cpu] What are peoples opinion of the Altera Nios
> Processor? > > > I'll be writing a paper in the next few weeks: a survey of
commercially
> and
> > > freely available 32-bit RISC IP cores.
> >
> > Interssting. You may post a link to the paper to this group, when it is
> ready.
> >
> > > For the paper, I'm interested in hard and soft cores, but for the
> future,
> > > my research will require one that I can customize (that is, VHDL or
> Verilog
> > > available). I'm already looking at LEON for that... but I'd
appreciate
> > > input as well.
> >
> > We used LEON in some project, about a year ago. From the functional
point
> LEON
> > was ok, it worked well. The good point is, that LEON comes with a
> > compiler/assembler toolchain that works out-of-the-box. The drawback of
> LEON
> > on FPGAs is that it is quite large and pretty slow. We have synthesized
> LEON
> > for a Xilinx Virtex XCV800-5, the maximum speed we could reach was about
> 25
> > MHz, the design used 3800 slices. I guess, we could have pushed this
> > somewhat further by floorplanning, but 25 MHz was sufficient performance
> for
> > our application. Compared to Microblaze, LEON is much larger and slower,
> but
> > comparing them is not really fair, as Microblaze was specifically
> optimized
> > for Virtex FPGAs.
> >
>
> A Java Processor is not a classical RISC processor, but as in my
> implementation it is a simple stack machine with a very small instruction
> set (reduced instruction set :-). It has 47 different instrcutions, all
> variations counted. So instructions can be coded in 8 bit WITH some
operand.
> And it fits in an Altera ACEX 1K50, about 2000 LCs (depends on the
periphery
> you use) and runns at about 30 MHz in the slowest speed grade.
> Did port it two weeks ago to Cyclone (yes a porting was necessary because
of
> the different embedded memory), and Quartus says it should run at about 80
> MHz.
>
> Interested?
>
> Martin Schoeberl > To post a message, send it to:
> To unsubscribe, send a blank message to:




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


RE: Java processor / RISC cpu - Josh Pfrimmer - Mar 18 19:50:00 2003

Martin,

The basic idea is to fold _groups_ of that have a stack dependency into
single risc instructions
pop
pop
add
push

translates to a single add instruction, if the operands are already in
registers. If we use the register file (plus some intelligent caching) to
replace the stack, we can eliminate artificial dependencies. Then, we can
use a tomasulo-type algorithm to execute the folded instructions out of
order, as they become available.

Also, having a dual-front end (RISC, Java) allows for a general-purpose
approach, and efficient execution of programs written in other languages,
while maintaining the portability of Java.

I've just started on this project. Most of the theoretical work was done by
M.W.El-Kharashi here at UVic. My research will focus on implementation of
his design... in an FPGA.

For more information, see his articles in transactions on Consumer
electronics (IEEE).

JP

-----Original Message-----
From: Martin Schoeberl [mailto:] Why do you want translate Java byte code to RISC instructions (on the fly
?)? Java byte codes lead to a simple cpu architecture. With the more complex
instructions you have to find a solution. But I think you only can translate
the simple (like 'iadd') to one or more RISC instructions. For instructions
like 'invokevirtual' you have to call a function, right?

As you are working on a similar project, perhaps we can share some ideas or
find new solutions for the problems.

Martin




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

Re: Java processor / RISC cpu - Tommy Thorn - Mar 19 21:01:00 2003

Josh Pfrimmer wrote:
> Martin,
>
> The basic idea is to fold _groups_ of that have a stack dependency into
> single risc instructions
> pop
> pop
> add
> push
>
> translates to a single add instruction, if the operands are already in
> registers. If we use the register file (plus some intelligent
caching) to
> replace the stack, we can eliminate artificial dependencies. Then,
we can
> use a tomasulo-type algorithm to execute the folded instructions out of
> order, as they become available.

Sound kind of like boost, although the basic idea of translating stack
instructions to three address instructions must be older than the universe.

http://www.icsi.berkeley.edu/~ssinha/papers/Tech_CS252_-_BOOST_-_Out-of-Order_Stack.pdf

Now, out-of-order in an FPGA sounds like fun.

/Tommy




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

Re: Java processor / RISC cpu - Tim Boescke - Mar 20 3:09:00 2003

>
> The basic idea is to fold _groups_ of that have a stack dependency
into
> single risc instructions
> pop
> pop
> add
> push Just wondering, is this supposed to be done dynamically in Hardware ?
The folding sounds like a good job for a static precompiler or something
similar to me. Is there any benefit of doing it in runtime ?





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

Re: Java processor / RISC cpu - Martin Schoeberl - Mar 20 6:02:00 2003

Josch,

> The basic idea is to fold _groups_ of that have a stack dependency into
> single risc instructions
> pop
> pop
> add
> push
>
> translates to a single add instruction, if the operands are already in
> registers. If we use the register file (plus some intelligent caching) to
> replace the stack, we can eliminate artificial dependencies. Then, we can
> use a tomasulo-type algorithm to execute the folded instructions out of
> order, as they become available.

I think you will do that on the fly. Like the translation of x86 code to
RISC (started with Pentium Pro I think).

But this will lead to a very long pipline. Means that you need good branch
prediction logic. This will lead to a big design (and a big FPGA).

Some simple instrucion folding was done in the picoJava from Sun. You can
look at the Verilog code. But picoJava is (as I remeber) a big design (some
100k gates).

My approach is to build a simple processor (with a short pipeline) for two
reasons:

Fit in 'cheap' FPGAs (like ACEX 1K50 or Cyclone)
Predictable execution time (WCET) for hard realtime systems

This means no branch prediction, some 'different' caching mechanism. > Also, having a dual-front end (RISC, Java) allows for a general-purpose
> approach, and efficient execution of programs written in other languages,
> while maintaining the portability of Java.
>
> I've just started on this project. Most of the theoretical work was done
by
> M.W.El-Kharashi here at UVic. My research will focus on implementation of
> his design... in an FPGA.
>
> For more information, see his articles in transactions on Consumer
> electronics (IEEE).

Do you have links for this articles on your server. Not everyone has access
to IEEE papers.

Martin > JP
>
> -----Original Message-----
> From: Martin Schoeberl [mailto:] > Why do you want translate Java byte code to RISC instructions (on the fly
> ?)? Java byte codes lead to a simple cpu architecture. With the more
complex
> instructions you have to find a solution. But I think you only can
translate
> the simple (like 'iadd') to one or more RISC instructions. For
instructions
> like 'invokevirtual' you have to call a function, right?
>
> As you are working on a similar project, perhaps we can share some ideas
or
> find new solutions for the problems.
>
> Martin >
> To post a message, send it to:
> To unsubscribe, send a blank message to:



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

Re: Java processor / RISC cpu - Martin Schoeberl - Mar 20 6:07:00 2003

> > The basic idea is to fold _groups_ of that have a stack dependency
> into
> > single risc instructions
> > pop
> > pop
> > add
> > push
> >
>
> Just wondering, is this supposed to be done dynamically in Hardware ?
> The folding sounds like a good job for a static precompiler or something
> similar to me. Is there any benefit of doing it in runtime ?
>
Than you end up what is done in JIT for any target. Means no more fun with
Java bytecodes.

A link to a paper about Compiler versus Java hardware:
http://www.complang.tuwien.ac.at/andi/acac98.ps.gz
The conclusion is that it makes no sense to build a Java Processor.

But I think it depends on the application. For small embedded systems it
makes sense:
You can't run JIT on a small system.
A decent Java Processor is even smaller than a RISC.

Martin




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

Re: Java processor / RISC cpu - Tim Boescke - Mar 20 7:38:00 2003

>A link to a paper about Compiler versus Java hardware:
>http://www.complang.tuwien.ac.at/andi/acac98.ps.gz
>The conclusion is that it makes no sense to build a Java Processor.

>But I think it depends on the application. For small embedded systems
it
>makes sense:
>You can't run JIT on a small system.
>A decent Java Processor is even smaller than a RISC.

Yes, but as it seems it it is either limited to an IPC=<1
or includes hardware that could also be replaced by
precompiler.

I see the idea of really small embedded CPUs, but in
days where any implementation of a JAVA CPU ASIC will
be severely pad limited I do not see the point.

Of course things are different for FPGAs.

How about MIPS/POWER ? Just a quick guess:

A IPC of 1 (JAVA cpus) forces you to increase the
clockspeed to improve perfomance.

Assuming that the IPC of a RISC CPU can be increased
over 1, without linearly scaling the hardware to the
IPC, a RISC CPU could be even more power efficient.
That is, even when the 1 IPC implementation of the RISC
CPU is less power efficient than a comparable JAVA CPU.



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

RE: Java processor / RISC cpu - Jan Gray - Mar 20 11:29:00 2003

> From: Martin Schoeberl [mailto:]
> A link to a paper about Compiler versus Java hardware:
> http://www.complang.tuwien.ac.at/andi/acac98.p> s.gz
> The
> conclusion is that it makes no sense to build a
> Java Processor.

Sounds familiar: www.fpgacpu.org/usenet/javaproc.html. Although more
recently there have been a number of Java instruction decoders /
accelerators for RISC processors -- potentially interesting if you can't
afford memory for a translator.

Jan Gray, Gray Research LLC




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

Re: Java processor / RISC cpu - Martin Schoeberl - Mar 20 12:03:00 2003

> >But I think it depends on the application. For small embedded systems
> it
> >makes sense:
> >You can't run JIT on a small system.
> >A decent Java Processor is even smaller than a RISC.
>
> Yes, but as it seems it it is either limited to an IPC=<1
> or includes hardware that could also be replaced by
> precompiler.
>
When IPC means instrcutions per cycle, JOP is restricted to this. Basic
instructions in one cycle, more complex of corse in more. But 'normal' RISC
(not superscalar) also execute one instrucion per cycle.

As Java has thread constructs in the language programmers will (hopefully)
get used to write threaded code. In this way parallism can be explicite
expressed. When this happens the next step is logical: Use several (small)
Java Processors (in one FPGA) to execute the threads in parallel.
I had one day two JOPs running in one FPGA, but thread sceduling and memory
access for this multi processor system is still missing. Some time...

> How about MIPS/POWER ? Just a quick guess:
>
> A IPC of 1 (JAVA cpus) forces you to increase the
> clockspeed to improve perfomance.
>
> Assuming that the IPC of a RISC CPU can be increased
> over 1, without linearly scaling the hardware to the
> IPC, a RISC CPU could be even more power efficient.
> That is, even when the 1 IPC implementation of the RISC
> CPU is less power efficient than a comparable JAVA CPU.

I think it's not so easy to compare IPCs of RISC and Java. If you write
programs in C and compile it to a RISC machine you will get better
performance then Java on a Java proc. or Java 'compiled' to RISC.

Martin



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

RE: Java processor / RISC cpu - Josh Pfrimmer - Mar 20 13:12:00 2003

Yes, it's an entirely hardware solution. Doing the translations in a
compiler eliminates the portability of Java (and if you're not using Java
for the portability, then...?)

JP
-----Original Message-----
From: Tim Boescke [mailto:]
Sent: March 20, 2003 12:10 AM
To:
Subject: Re: [fpga-cpu] Java processor / RISC cpu >
> The basic idea is to fold _groups_ of that have a stack dependency
into
> single risc instructions
> pop
> pop
> add
> push Just wondering, is this supposed to be done dynamically in Hardware ?
The folding sounds like a good job for a static precompiler or something
similar to me. Is there any benefit of doing it in runtime ?
To post a message, send it to:
To unsubscribe, send a blank message to:





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

RE: Java processor / RISC cpu - Josh Pfrimmer - Mar 20 13:20:00 2003

Hi Martin, thanks for the article, but I can't seem to open the .gz file.
Do you have the .ps or .odf of it?

Thanks,

JP

-----Original Message-----
From: Martin Schoeberl [mailto:]

Than you end up what is done in JIT for any target. Means no more fun with
Java bytecodes.

A link to a paper about Compiler versus Java hardware:
http://www.complang.tuwien.ac.at/andi/acac98.ps.gz
The conclusion is that it makes no sense to build a Java Processor.

But I think it depends on the application. For small embedded systems it
makes sense:
You can't run JIT on a small system.
A decent Java Processor is even smaller than a RISC.

Martin To post a message, send it to:
To unsubscribe, send a blank message to:





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

Re: Java processor / RISC cpu - Martin Schoeberl - Mar 20 14:32:00 2003

> Hi Martin, thanks for the article, but I can't seem to open the .gz file.
> Do you have the .ps or .odf of it?

It's not an article I wrote. But I've seen that the extension is wrong. It's
only a .ps file!!!
Just rename it to acac98.ps.

Martin

> -----Original Message-----
> From: Martin Schoeberl [mailto:]
>
> Than you end up what is done in JIT for any target. Means no more fun with
> Java bytecodes.
>
> A link to a paper about Compiler versus Java hardware:
> http://www.complang.tuwien.ac.at/andi/acac98.ps.gz
> The conclusion is that it makes no sense to build a Java Processor.
>
> But I think it depends on the application. For small embedded systems it
> makes sense:
> You can't run JIT on a small system.
> A decent Java Processor is even smaller than a RISC.
>
> Martin > To post a message, send it to:
> To unsubscribe, send a blank message to: >
>
> To post a message, send it to:
> To unsubscribe, send a blank message to:





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