Hi all,

I would like to get an overview what is actually cooking on JOP
related projects - and what has already been done. You're very
welcome to add a short description of your project with some
links to web sites, papers,... to the wiki page

http://www.jopwiki.com/Projects

If you want to elaborate longer on your project just start a
new wiki page. If you're too lazy to get an account at the wiki
(sorry, but that's needed to get protection from spam bots),
just send an email and I will add your project.

Looking forward for more entries.

Cheers,
Martin

Stefan Hepp has developed a static stack analysis tool for JOP as part
of his JOPtimizer. However,
I lost the information where to find this application :-( Perhaps Stefan
is still on the list and can answer
the question.

Another option would be to write a program to do this analysis on your
own. It's some work, but
you can try to use either the JOPizer infrastructure or the little
larger framework of the WCET analysis
tool

Cheers,
Martin

c.p.bridges@... wrote:
>
>
> Hi Dan, thanks for the information!
>
> I’m using a heavy middleware application which causes stack overflow.
> The app itself is 305-1000 KB (when minimised) and, from what I can
> tell, this causes a stack overflow. I’m also loading a lot of extra
> methods/ locals statically from JRE 1.1.8/ JRE 1.2 and different to
> JOP’s methods which is why this could occur too I’m told.
>
> I’m trying to get these applications and middleware to operate on a
> much larger/ faster device with the LEON3 processor + AMBA bus too; so
> stack size can be increased by quite a lot if necessary.
>
> Any thoughts on that logic? :P
>
> Cheers, Chris
>
> ------------------------------------------------------------------------
>
> *From:* java-processor@yahoogroups.com
> [mailto:java-processor@yahoogroups.com] *On Behalf Of *Dan Clemmensen
> *Sent:* 18 November 2009 13:36
> *To:* java-processor@yahoogroups.com
> *Subject:* Re: [java-processor] Re: Finding exact stack size
>
> There are two ways to analyze stack depth: static code analysis or
> dynamic measurement. You appear to be asking for a static code analysis.
>
> If there is no recursion, it is theoretically possible to perform a
> static code analysis on a Java application to see what depth the stack
> will reach. Note, however, that you must also account for additional
> methods that may be invoked via interrupts. The analysis uses the call
> graph: "no recursion" means that the graph has no loops: it's a tree.
> The paper on the joptimizer refers to acall graph but I do not know if
> one ws actually implemented.
>
> If you want to do a dyamic (experimental) analysis, then you must
> either instrument your code or you must instrument your compiler, JVM,
> or hardware. With JOP, it is probably easiest to instrument the JVM or
> the hardware. To accompish this, simply add a max stack register in
> the VHDL and update it (using a comparison) any time the stack pointer
> in incremented. alternatively, you can make your stack RAM word wider
> by one bit, pre-fill the extra bit in each word with zero prior to
> executing your app, and have the hardware write a 1 into the extra bit
> whenever the stack word is written: you get the extra bit "for free"
> in a Xilinx BRAM. You will need to implement new native methode to
> read and write these bits for the analysis. To instrment the JVM, it
> is probably easiest to pre-load the entire stack RAM with a pattern
> and then change any push operation to do an extra iload_0,pop to force
> a zero into TOS+1. You can post-analyze the stack with a tiny app to
> check the result. If you are reasonably sure that your pre-fill
> pattern is unique and will not be used by the code, you cna simply
> post-analyze the stack looking for the highest non-pattern entry.
>
> The other way to perform a dynamic analysis is by using (and
> instrumenting) the simulator.
>
> Finally, we must ask: Why do you care? the stack uses one or more
> BRAMs, with a default sice of 256 words (which will fit in a Spartan 2
> BRAM) but the Spartan3E BRAM size is 512 words. There is no gain in
> specifying a stack smaller than this. unless you intend to build an
> ASIC or your code is deeply recursive, it's not clear that this
> information is interesting.
>
> On Wed, Nov 18, 2009 at 5:46 AM, Christopher Bridges
> <c.p.bridges@... <mailto:c.p.bridges@...>> wrote:
>
> What about the sources in java\tools\src\com\jopdesign\build? Any of
> them any use for figuring it out?
>
> Sorry to ask again, but I want to be sure. Can I use any information
> in the .jop.txt file?
>
> Cheers, Chris
>
>
>
> --- In java-processor@yahoogroups.com
> <mailto:java-processor%40yahoogroups.com>, Martin Schoeberl
> <martin@...> wrote:
> >
> > There is no (easy) way to print a stack trace. What you can do is to
> > printout the value of the stack pointer. You can get that value with
> > Native.getSp().
> >
> > Cheers,
> > Martin
> >
> > Christopher Bridges wrote:
> > > Hi Martin,
> > >
> > > What would be the equivalent to 'printStackTrace' for JOP? Or can I
> do this in JOP sim?
> > >
> > > I need to figure out what my call depth is and the size of the
> args/locals for my application. I can then set the stack size accordingly.
> > >
> > > Can I use any information in the .jop.txt file?
> > >
> > > Or any useful tools I need?
> > >
> > > Cheers, Chris
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>

I am out of the office until 11/23/2009.

If you have an urgent request, please contact the Dean's office at (937)
229-2736.


Note: This is an automated response to your message  "[java-processor]
AUTO: John G Weber is out of the office. (returning 11/23/2009)". sent on
11/18/2009 4:01:55 AM:.

This is the only notification you will receive while this person is away.

I am out of the office until 11/23/2009.

If you have an urgent request, please contact the Dean's office at (937)
229-2736.


Note: This is an automated response to your message  "Re: [java-processor]
Re: Finding exact stack size" sent on 11/18/2009 8:36:24 AM.

This is the only notification you will receive while this person is away.

I am out of the office until 11/23/2009.

If you have an urgent request, please contact the Dean's office at (937)
229-2736.


Note: This is an automated response to your message  "[java-processor]
AUTO: John G Weber is out of the office. (returning 11/23/2009)". sent on
11/18/2009 4:01:03 AM:.

This is the only notification you will receive while this person is away.

I am out of the office until 11/23/2009.

If you have an urgent request, please contact the Dean's office at (937)
229-2736.


Note: This is an automated response to your message  "[java-processor] Re:
Finding exact stack size" sent on 11/18/2009 5:46:54 AM.

This is the only notification you will receive while this person is away.

What about the sources in java\tools\src\com\jopdesign\build? Any of them any
use for figuring it out?

Sorry to ask again, but I want to be sure. Can I use any information in the
.jop.txt file?

Cheers, Chris

--- In java-processor@yahoogroups.com, Martin Schoeberl <martin@...> wrote:
>
> There is no (easy) way to print a stack trace. What you can do is to
> printout the value of the stack pointer. You can get that value with
> Native.getSp().
>
> Cheers,
> Martin
>
> Christopher Bridges wrote:
> > Hi Martin,
> >
> > What would be the equivalent to 'printStackTrace' for JOP? Or can I do this
in JOP sim?
> >
> > I need to figure out what my call depth is and the size of the args/locals
for my application. I can then set the stack size accordingly.
> >
> > Can I use any information in the .jop.txt file?
> >
> > Or any useful tools I need?
> >
> > Cheers, Chris
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>

I am out of the office until 11/23/2009.

If you have an urgent request, please contact the Dean's office at (937)
229-2736.


Note: This is an automated response to your message  "Re: [java-processor]
Finding exact stack size" sent on 11/18/2009 12:33:37 AM.

This is the only notification you will receive while this person is away.

I am out of the office until 11/23/2009.

If you have an urgent request, please contact the Dean's office at (937)
229-2736.


Note: This is an automated response to your message  "[java-processor]
AUTO: John G Weber is out of the office. (returning 11/23/2009)". sent on
11/17/2009 10:02:44 PM.

This is the only notification you will receive while this person is away.

There is no (easy) way to print a stack trace. What you can do is to
printout the value of the stack pointer. You can get that value with
Native.getSp().

Cheers,
Martin

Christopher Bridges wrote:
> Hi Martin,
>
> What would be the equivalent to 'printStackTrace' for JOP? Or can I do this in
JOP sim?
>
> I need to figure out what my call depth is and the size of the args/locals for
my application. I can then set the stack size accordingly.
>
> Can I use any information in the .jop.txt file?
>
> Or any useful tools I need?
>
> Cheers, Chris
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>

I am out of the office until 11/23/2009.

If you have an urgent request, please contact the Dean's office at (937)
229-2736.


Note: This is an automated response to your message  "[java-processor]
Finding exact stack size" sent on 11/17/2009 7:53:49 PM.

This is the only notification you will receive while this person is away.

Hi Martin,

What would be the equivalent to 'printStackTrace' for JOP? Or can I do this in
JOP sim?

I need to figure out what my call depth is and the size of the args/locals for
my application. I can then set the stack size accordingly.

Can I use any information in the .jop.txt file?

Or any useful tools I need?

Cheers, Chris

Martin and Friends,

Wizardry has been renamed to "The_Wizardry_Project" on OpenCores (
http://www.opencores.com/project,the_wizardry_project ).  I had to "start over"
because there was not enough flexibility on the OpenCores site to modify
documents once uploaded to the "downloads" page.  Rather, I will be placing all
documents and code on the SVN.  I will be adding the first source code to the
SVN today!

The first component will be EmPAC, the protocol analyzer.  Please feel free to
take a look at it.  Up next is eRCP, and the RDIC :) followed by the Web Server.
I plan to have all of these components available by the end of next week (design
documents and source code).

I am very excited about this project and I hope that this will be a meaningful
contribution to JOP!

Regards,

--- In java-processor@yahoogroups.com, Martin Schoeberl <martin@...> wrote:
>
> Hi Marlon,
>
> that project looks quite cool!!! From your description and the block
> diagram I can get some idea of it. Looking forward to more information
> and source. I would especially like to use the DDR SDRAM interface for
> general use with JOP ;-)
>
> Is this an academic or industrial project? If it's the former one I'm
> looking forward to read paper(s) on it.
>
> Cheers,
> Martin
>
> mcwaccent wrote:
> > Hello Martin and Friends,
> >
> > I am delighted to inform everyone that at new open source project called
Wizardry is now available on OpenCores.  Martin if you recall, almost 2 years
ago, I had many questions regarding switching JOP's memory interface from SRAM
to priority-based round-robin Wishbone compliant DDR SDRAM.  While the idea to
replace JOPs main memory was abandoned, we were able to connect the DDR SDRAM
resources through JOP's IO interface.
> >
> > After successfully interfacing JOP with 512 MB of DDR SDRAM, we were able to
create a neat little open source network intrusion detection system.  This
system includes 2 very important components: a protocol analyzer (called EmPAC)
and a content processor (called eRCP).  Each of these components also connects
to the DDR SDRAM resources.  In fact, JOP is configured to load data from a web
server (which is also available open source), to each component for
configuration.
> >
> > The memory interface to the DDR SDRAM is Wishbone compliant and supports up
to 8 different component.  Each component has ~64 MB of memory space allocated
to it from the DDR SDRAM, while JOP has its own "special" port that has access
to each of the 8 components.
> >
> > I invite everyone to check out this project on at
http://www.opencores.com/project,wizardry .  As of right now there is only
documentation for EmPAC on there, as well as a top-level diagram of the entire
system.  Please let me know what you all think.  I will be adding all
documentation for each component, as well as all of the code within the next
week or so.  I hope that you all find this useful and can contribute your
thoughts.
> >
> > Regards,
> >
> > Marlon C. Winder
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>

First, thanks for all the prompt answers!  I really appreciate it.

Second, I can't believe somebody actually said they would read my thesis! 
That's great and horrible all at the same time.  The added benefit is obvious,
the downside is that if I try BS'ing anywhere I'm sure you'll catch it :)  Just
don't tell the committee!

I'll forward it to you as soon as its ready.  Thanks again.

--- In java-processor@yahoogroups.com, Martin Schoeberl <martin@...> wrote:
>
>
> > 1. I thought that when the JOP is loaded onto an FPGA, all the onboard
memory items were already initialized. Note - I peform (make tools, cd asm,
jopser, cd..). At this point I ran the full synthesization process on the
project up to the point where you would normally download the design to the
board(targeting the s3sk design). I instead output the project as an edif file. 
I understand that when running ModelSim, various mem_xxxx.dat files are utilized
to initialize different memory modules (including sram). For my simulation
model, I assumed that the only memory I had to initialize was the memory
external to the JOP - that being the SRAM. Am I correct in this?
> >
>
> That's correct. On-chip memory is part of the FPGA configuration,
> external memory (the main memory)
> has to be explicitly  loaded.
> > 2.  Based on the above - the only information sent over the serial line
should be some information for the JOP(amount of words, etc), then it should
boot the JVM, load the .jop program into main memory, and then set the JOP to
start executing code at a certain address.
> >
> Not exactly: over the serial line the main memory content (.jop file) is
> loaded. After that the JVM is booted. Part of
> the JVM is within the content of the main memory.
> > 3.  I read (can't remember where) in the JOP handbook that there is a
difference in the simulation jop and the actual jop in that the simulation jop
code assumes all the memory has already been initialized and loaded...where is
this difference coded into the project?  Is it in any of the main JOP modules?
> >
>
> There are #ifdefs in jvm.asm where you see the difference. Depending on
> the way the main memory
> is loaded (serial line, Flash, within ModelSim) different versions of
> the JVM microcode is generated,
> which itself is a memory initialization code (rom.vhd). Looks like I
> have to expand the section in the
> handbook a little bit to make it clearer.
>
> > That's all I can think of for now.  Thanks for your help Martin and also
thanks to Dan Clemenson (if you're reading this).  You two are extremely
helpful.  This is honestly the best supported OSS project I have every run into.
> >
> >
>
> Thanks! That's nice to hear. But the LEON mailing list is at least
> similar ;-)
>
> When you've finished your thesis I would like to read it. Or you can
> give me a version before you
> submit it and I can do a quick proof reading.
>
> Cheers,
> Martin
> > best
> >
> > dan
> >
> >
> > --- In java-processor@yahoogroups.com, Martin Schoeberl <martin@> wrote:
> >
> >> The download via serial line is quite simple. The memory content is
> >> sent in binary form - see down.c. The first word of the memory content
> >> is actually the size of the application so JOP knows how many words
> >> are downloaded. You can look into jvm.asm to see the JOP side of
> >> the download.
> >>
> >> Furthermore, a very simple handshake is used: each byte is echoed
> >> by JOP.
> >>
> >> However, for simulation I would *not* go the route to simulate the
> >> serial port and download the program. That would take forever!
> >> In ModelSim, the simulation of the main memory loads the content
> >> via VHDL code.
> >>
> >> Hope this helps,
> >> Martin
> >>
> >> dslaman0877 wrote:
> >>
> >>> -What is a "-ve number"?
> >>>
> >>> My bad, that is my shorthand for negative number. Sorry about that.
> >>>
> >>> --What do you mean by 'implement the memory as Java class files'?
> >>> --I don't understand. If you need the main memory content in a Java
> >>> --based simulation, just read it in.
> >>>
> >>> Well, never mind that for now. I determined a better way of doing
this...all I need now is to figure out how to simulate the serial lines
behavior.  Please see below.
> >>>
> >>> -What do you mean by converting integer to 32-bit binary numbers?
> >>> -The integers in the ASCII files are in the range of 32 bits as they
> >>> -actually represent the memory content in 32-bit words.
> >>>
> >>> I think I can explain better what I've done which should help anybody else
understand what my next step is.  I've got the entire JOP instantiated as a
SPICE netlist now - that being the s3sk design (yes, it took a lot of work). 
I've also got a model of the sram built.  Now I have to feed the jop the proper
set of input vectors for it to execute.  I think all I have to do is capture
what is sent over the serial line and use that to simulate the entire hardware
design.
> >>>
> >>> But I'm really jammed up on how to do this. I altered the down.c program
to send its output to a text file instead of over the com-port just so I could
see what was going on. It was all in ASCII so I used a text editor program which
converted all the ASCII to hexadecimal format.  It looks like there is a lot of
null words and then things start cranking.  I figure the JVM gets booted in the
first 1000 or so words and then the data to put into BRAM and SRAM is
sent...then it begins executing.
> >>>
> >>> Is down.exe sending ASCII values over the com-port? To me that doesn't
make any sense, reading the down.c program, I thought it was sending the words
over as 32-bit binary values.
> >>>
> >>> Also, I don't fully understand how the data is transmitted via the
com-port.  Are there timing issues I need to think about or could I just start
clocking the JOP and then begin pushing all the data over the ser_rxd line?
> >>>
> >>> Thanks for the help.  I need it.
> >>>
> >>> Best,
> >>>
> >>> dan
> >>>
> >>>
> >>>
> >>>> dslaman0877 wrote:
> >>>>
> >>>>
> >>>>> Turns out I was signed into my wifes yahoo account over the weekend so I
made 2 posts which never made it.  My bad.  A question I got from Dan Clemmenson
was whether or not external components to the JOP could be included in the
instantaneous power characterization.  So far, the answer is no.
> >>>>>
> >>>>> My plan at this point is to implement the memory as java class files.  I
won't elaborate until all my work is finished (because I'm not even sure if that
will work yet).  Then I can submit the project to Martin (or whoever controls
the repository) so others can start performing power characterizations of
embedded systems utilizing the JOP.  Pretty cool stuff if you ask me (obviously
if you ask me right?).
> >>>>>
> >>>>> I am still confused about the mem_main.dat file.  I wrote a Java program
which converts the integer numbers in the file to 32 bit binary numbers and
places them into a different file.  I don't know what to do with the -ve numbers
so I just set them to null for now.  Can somebody please explain at a very low
kindergarten level what the -ve numbers represent and thus how I should write my
program to convert?  Thanks in advance.
> >>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------
> >>>>>
> >>>>> Yahoo! Groups Links
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>

> 1. I thought that when the JOP is loaded onto an FPGA, all the onboard memory
items were already initialized. Note - I peform (make tools, cd asm, jopser,
cd..). At this point I ran the full synthesization process on the project up to
the point where you would normally download the design to the board(targeting
the s3sk design). I instead output the project as an edif file.  I understand
that when running ModelSim, various mem_xxxx.dat files are utilized to
initialize different memory modules (including sram). For my simulation model, I
assumed that the only memory I had to initialize was the memory external to the
JOP - that being the SRAM. Am I correct in this?
>

That's correct. On-chip memory is part of the FPGA configuration,
external memory (the main memory)
has to be explicitly  loaded.
> 2.  Based on the above - the only information sent over the serial line should
be some information for the JOP(amount of words, etc), then it should boot the
JVM, load the .jop program into main memory, and then set the JOP to start
executing code at a certain address.
>
Not exactly: over the serial line the main memory content (.jop file) is
loaded. After that the JVM is booted. Part of
the JVM is within the content of the main memory.
> 3.  I read (can't remember where) in the JOP handbook that there is a
difference in the simulation jop and the actual jop in that the simulation jop
code assumes all the memory has already been initialized and loaded...where is
this difference coded into the project?  Is it in any of the main JOP modules?
>

There are #ifdefs in jvm.asm where you see the difference. Depending on
the way the main memory
is loaded (serial line, Flash, within ModelSim) different versions of
the JVM microcode is generated,
which itself is a memory initialization code (rom.vhd). Looks like I
have to expand the section in the
handbook a little bit to make it clearer.

> That's all I can think of for now.  Thanks for your help Martin and also
thanks to Dan Clemenson (if you're reading this).  You two are extremely
helpful.  This is honestly the best supported OSS project I have every run into.
>
>

Thanks! That's nice to hear. But the LEON mailing list is at least
similar ;-)

When you've finished your thesis I would like to read it. Or you can
give me a version before you
submit it and I can do a quick proof reading.

Cheers,
Martin
> best
>
> dan
>
>
> --- In java-processor@yahoogroups.com, Martin Schoeberl <martin@...> wrote:
>
>> The download via serial line is quite simple. The memory content is
>> sent in binary form - see down.c. The first word of the memory content
>> is actually the size of the application so JOP knows how many words
>> are downloaded. You can look into jvm.asm to see the JOP side of
>> the download.
>>
>> Furthermore, a very simple handshake is used: each byte is echoed
>> by JOP.
>>
>> However, for simulation I would *not* go the route to simulate the
>> serial port and download the program. That would take forever!
>> In ModelSim, the simulation of the main memory loads the content
>> via VHDL code.
>>
>> Hope this helps,
>> Martin
>>
>> dslaman0877 wrote:
>>
>>> -What is a "-ve number"?
>>>
>>> My bad, that is my shorthand for negative number. Sorry about that.
>>>
>>> --What do you mean by 'implement the memory as Java class files'?
>>> --I don't understand. If you need the main memory content in a Java
>>> --based simulation, just read it in.
>>>
>>> Well, never mind that for now. I determined a better way of doing this...all
I need now is to figure out how to simulate the serial lines behavior.  Please
see below.
>>>
>>> -What do you mean by converting integer to 32-bit binary numbers?
>>> -The integers in the ASCII files are in the range of 32 bits as they
>>> -actually represent the memory content in 32-bit words.
>>>
>>> I think I can explain better what I've done which should help anybody else
understand what my next step is.  I've got the entire JOP instantiated as a
SPICE netlist now - that being the s3sk design (yes, it took a lot of work). 
I've also got a model of the sram built.  Now I have to feed the jop the proper
set of input vectors for it to execute.  I think all I have to do is capture
what is sent over the serial line and use that to simulate the entire hardware
design.
>>>
>>> But I'm really jammed up on how to do this. I altered the down.c program to
send its output to a text file instead of over the com-port just so I could see
what was going on. It was all in ASCII so I used a text editor program which
converted all the ASCII to hexadecimal format.  It looks like there is a lot of
null words and then things start cranking.  I figure the JVM gets booted in the
first 1000 or so words and then the data to put into BRAM and SRAM is
sent...then it begins executing.
>>>
>>> Is down.exe sending ASCII values over the com-port? To me that doesn't make
any sense, reading the down.c program, I thought it was sending the words over
as 32-bit binary values.
>>>
>>> Also, I don't fully understand how the data is transmitted via the com-port.
Are there timing issues I need to think about or could I just start clocking the
JOP and then begin pushing all the data over the ser_rxd line?
>>>
>>> Thanks for the help.  I need it.
>>>
>>> Best,
>>>
>>> dan
>>>
>>>
>>>
>>>> dslaman0877 wrote:
>>>>
>>>>
>>>>> Turns out I was signed into my wifes yahoo account over the weekend so I
made 2 posts which never made it.  My bad.  A question I got from Dan Clemmenson
was whether or not external components to the JOP could be included in the
instantaneous power characterization.  So far, the answer is no.
>>>>>
>>>>> My plan at this point is to implement the memory as java class files.  I
won't elaborate until all my work is finished (because I'm not even sure if that
will work yet).  Then I can submit the project to Martin (or whoever controls
the repository) so others can start performing power characterizations of
embedded systems utilizing the JOP.  Pretty cool stuff if you ask me (obviously
if you ask me right?).
>>>>>
>>>>> I am still confused about the mem_main.dat file.  I wrote a Java program
which converts the integer numbers in the file to 32 bit binary numbers and
places them into a different file.  I don't know what to do with the -ve numbers
so I just set them to null for now.  Can somebody please explain at a very low
kindergarten level what the -ve numbers represent and thus how I should write my
program to convert?  Thanks in advance.
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------
>>>>>
>>>>> Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>

Dang, the more I know about the JOP the more I don't know. I didn't realize the
JOP was echoing the words back every time. I assume that's to catch a bit flip
or other error.

OK then, so I have to initialize the necessary memory modules prior simulating
to save time. Here are some steps related to that which I don't understand -
please keep in mind that yes, I can figure most of this out myself, but my
thesis defense date is set and I am wayyyy behind.  I really appreciate the
answers here because it saves me a lot of time that I need (especially for
writing the damn thesis! I hate that part!).

1. I thought that when the JOP is loaded onto an FPGA, all the onboard memory
items were already initialized. Note - I peform (make tools, cd asm, jopser,
cd..). At this point I ran the full synthesization process on the project up to
the point where you would normally download the design to the board(targeting
the s3sk design). I instead output the project as an edif file.  I understand
that when running ModelSim, various mem_xxxx.dat files are utilized to
initialize different memory modules (including sram). For my simulation model, I
assumed that the only memory I had to initialize was the memory external to the
JOP - that being the SRAM. Am I correct in this?

2.  Based on the above - the only information sent over the serial line should
be some information for the JOP(amount of words, etc), then it should boot the
JVM, load the .jop program into main memory, and then set the JOP to start
executing code at a certain address.

3.  I read (can't remember where) in the JOP handbook that there is a difference
in the simulation jop and the actual jop in that the simulation jop code assumes
all the memory has already been initialized and loaded...where is this
difference coded into the project?  Is it in any of the main JOP modules?

That's all I can think of for now.  Thanks for your help Martin and also thanks
to Dan Clemenson (if you're reading this).  You two are extremely helpful.  This
is honestly the best supported OSS project I have every run into.

best

dan


--- In java-processor@yahoogroups.com, Martin Schoeberl <martin@...> wrote:
>
> The download via serial line is quite simple. The memory content is
> sent in binary form - see down.c. The first word of the memory content
> is actually the size of the application so JOP knows how many words
> are downloaded. You can look into jvm.asm to see the JOP side of
> the download.
>
> Furthermore, a very simple handshake is used: each byte is echoed
> by JOP.
>
> However, for simulation I would *not* go the route to simulate the
> serial port and download the program. That would take forever!
> In ModelSim, the simulation of the main memory loads the content
> via VHDL code.
>
> Hope this helps,
> Martin
>
> dslaman0877 wrote:
> > -What is a "-ve number"?
> >
> > My bad, that is my shorthand for negative number. Sorry about that.
> >
> > --What do you mean by 'implement the memory as Java class files'?
> > --I don't understand. If you need the main memory content in a Java
> > --based simulation, just read it in.
> >
> > Well, never mind that for now. I determined a better way of doing this...all
I need now is to figure out how to simulate the serial lines behavior.  Please
see below.
> >
> > -What do you mean by converting integer to 32-bit binary numbers?
> > -The integers in the ASCII files are in the range of 32 bits as they
> > -actually represent the memory content in 32-bit words.
> >
> > I think I can explain better what I've done which should help anybody else
understand what my next step is.  I've got the entire JOP instantiated as a
SPICE netlist now - that being the s3sk design (yes, it took a lot of work). 
I've also got a model of the sram built.  Now I have to feed the jop the proper
set of input vectors for it to execute.  I think all I have to do is capture
what is sent over the serial line and use that to simulate the entire hardware
design.
> >
> > But I'm really jammed up on how to do this. I altered the down.c program to
send its output to a text file instead of over the com-port just so I could see
what was going on. It was all in ASCII so I used a text editor program which
converted all the ASCII to hexadecimal format.  It looks like there is a lot of
null words and then things start cranking.  I figure the JVM gets booted in the
first 1000 or so words and then the data to put into BRAM and SRAM is
sent...then it begins executing.
> >
> > Is down.exe sending ASCII values over the com-port? To me that doesn't make
any sense, reading the down.c program, I thought it was sending the words over
as 32-bit binary values.
> >
> > Also, I don't fully understand how the data is transmitted via the com-port.
Are there timing issues I need to think about or could I just start clocking the
JOP and then begin pushing all the data over the ser_rxd line?
> >
> > Thanks for the help.  I need it.
> >
> > Best,
> >
> > dan
> >
> >
> >> dslaman0877 wrote:
> >>
> >>> Turns out I was signed into my wifes yahoo account over the weekend so I
made 2 posts which never made it.  My bad.  A question I got from Dan Clemmenson
was whether or not external components to the JOP could be included in the
instantaneous power characterization.  So far, the answer is no.
> >>>
> >>> My plan at this point is to implement the memory as java class files.  I
won't elaborate until all my work is finished (because I'm not even sure if that
will work yet).  Then I can submit the project to Martin (or whoever controls
the repository) so others can start performing power characterizations of
embedded systems utilizing the JOP.  Pretty cool stuff if you ask me (obviously
if you ask me right?).
> >>>
> >>> I am still confused about the mem_main.dat file.  I wrote a Java program
which converts the integer numbers in the file to 32 bit binary numbers and
places them into a different file.  I don't know what to do with the -ve numbers
so I just set them to null for now.  Can somebody please explain at a very low
kindergarten level what the -ve numbers represent and thus how I should write my
program to convert?  Thanks in advance.
> >>>
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>

The download via serial line is quite simple. The memory content is
sent in binary form - see down.c. The first word of the memory content
is actually the size of the application so JOP knows how many words
are downloaded. You can look into jvm.asm to see the JOP side of
the download.

Furthermore, a very simple handshake is used: each byte is echoed
by JOP.

However, for simulation I would *not* go the route to simulate the
serial port and download the program. That would take forever!
In ModelSim, the simulation of the main memory loads the content
via VHDL code.

Hope this helps,
Martin

dslaman0877 wrote:
> -What is a "-ve number"?
>
> My bad, that is my shorthand for negative number. Sorry about that.
>
> --What do you mean by 'implement the memory as Java class files'?
> --I don't understand. If you need the main memory content in a Java
> --based simulation, just read it in.
>
> Well, never mind that for now. I determined a better way of doing this...all I
need now is to figure out how to simulate the serial lines behavior.  Please see
below.
>
> -What do you mean by converting integer to 32-bit binary numbers?
> -The integers in the ASCII files are in the range of 32 bits as they
> -actually represent the memory content in 32-bit words.
>
> I think I can explain better what I've done which should help anybody else
understand what my next step is.  I've got the entire JOP instantiated as a
SPICE netlist now - that being the s3sk design (yes, it took a lot of work). 
I've also got a model of the sram built.  Now I have to feed the jop the proper
set of input vectors for it to execute.  I think all I have to do is capture
what is sent over the serial line and use that to simulate the entire hardware
design.
>
> But I'm really jammed up on how to do this. I altered the down.c program to
send its output to a text file instead of over the com-port just so I could see
what was going on. It was all in ASCII so I used a text editor program which
converted all the ASCII to hexadecimal format.  It looks like there is a lot of
null words and then things start cranking.  I figure the JVM gets booted in the
first 1000 or so words and then the data to put into BRAM and SRAM is
sent...then it begins executing.
>
> Is down.exe sending ASCII values over the com-port? To me that doesn't make
any sense, reading the down.c program, I thought it was sending the words over
as 32-bit binary values.
>
> Also, I don't fully understand how the data is transmitted via the com-port. 
Are there timing issues I need to think about or could I just start clocking the
JOP and then begin pushing all the data over the ser_rxd line?
>
> Thanks for the help.  I need it.
>
> Best,
>
> dan
>
>
>> dslaman0877 wrote:
>>
>>> Turns out I was signed into my wifes yahoo account over the weekend so I
made 2 posts which never made it.  My bad.  A question I got from Dan Clemmenson
was whether or not external components to the JOP could be included in the
instantaneous power characterization.  So far, the answer is no.
>>>
>>> My plan at this point is to implement the memory as java class files.  I
won't elaborate until all my work is finished (because I'm not even sure if that
will work yet).  Then I can submit the project to Martin (or whoever controls
the repository) so others can start performing power characterizations of
embedded systems utilizing the JOP.  Pretty cool stuff if you ask me (obviously
if you ask me right?).
>>>
>>> I am still confused about the mem_main.dat file.  I wrote a Java program
which converts the integer numbers in the file to 32 bit binary numbers and
places them into a different file.  I don't know what to do with the -ve numbers
so I just set them to null for now.  Can somebody please explain at a very low
kindergarten level what the -ve numbers represent and thus how I should write my
program to convert?  Thanks in advance.
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>

-What is a "-ve number"?

My bad, that is my shorthand for negative number. Sorry about that.

--What do you mean by 'implement the memory as Java class files'?
--I don't understand. If you need the main memory content in a Java
--based simulation, just read it in.

Well, never mind that for now. I determined a better way of doing this...all I
need now is to figure out how to simulate the serial lines behavior.  Please see
below.

-What do you mean by converting integer to 32-bit binary numbers?
-The integers in the ASCII files are in the range of 32 bits as they
-actually represent the memory content in 32-bit words.

I think I can explain better what I've done which should help anybody else
understand what my next step is.  I've got the entire JOP instantiated as a
SPICE netlist now - that being the s3sk design (yes, it took a lot of work). 
I've also got a model of the sram built.  Now I have to feed the jop the proper
set of input vectors for it to execute.  I think all I have to do is capture
what is sent over the serial line and use that to simulate the entire hardware
design.

But I'm really jammed up on how to do this. I altered the down.c program to send
its output to a text file instead of over the com-port just so I could see what
was going on. It was all in ASCII so I used a text editor program which
converted all the ASCII to hexadecimal format.  It looks like there is a lot of
null words and then things start cranking.  I figure the JVM gets booted in the
first 1000 or so words and then the data to put into BRAM and SRAM is
sent...then it begins executing.

Is down.exe sending ASCII values over the com-port? To me that doesn't make any
sense, reading the down.c program, I thought it was sending the words over as
32-bit binary values.

Also, I don't fully understand how the data is transmitted via the com-port. 
Are there timing issues I need to think about or could I just start clocking the
JOP and then begin pushing all the data over the ser_rxd line?

Thanks for the help.  I need it.

Best,

dan

> dslaman0877 wrote:
> > Turns out I was signed into my wifes yahoo account over the weekend so I
made 2 posts which never made it.  My bad.  A question I got from Dan Clemmenson
was whether or not external components to the JOP could be included in the
instantaneous power characterization.  So far, the answer is no.
> >
> > My plan at this point is to implement the memory as java class files.  I
won't elaborate until all my work is finished (because I'm not even sure if that
will work yet).  Then I can submit the project to Martin (or whoever controls
the repository) so others can start performing power characterizations of
embedded systems utilizing the JOP.  Pretty cool stuff if you ask me (obviously
if you ask me right?).
> >
> > I am still confused about the mem_main.dat file.  I wrote a Java program
which converts the integer numbers in the file to 32 bit binary numbers and
places them into a different file.  I don't know what to do with the -ve numbers
so I just set them to null for now.  Can somebody please explain at a very low
kindergarten level what the -ve numbers represent and thus how I should write my
program to convert?  Thanks in advance.
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>

Looking into the scheduler code reveals the solution to the difference.
There is the notation of an idle tick. If no thread becomes ready
within 10ms the timer is still fired and the scheduler invoked.
Therefore, your task gets interrupted by this idle tick. I have
increased the value to 1 second and now the execution time within a
real-time thread is the same as when running in a single thread
without the scheduler.

Thanks again for pointing this out.

Cheers,
Martin

Martin Schoeberl wrote:
> Conal,
>
> thanks for your examples. It's true the loop of TaskShort takes about
> 5000 cycle more when executing in an RT-thread. Both WCEt analysis and
> measuring
> the task code in a single thread shows the shorter time. Actually I have
> absolutely no idea why it takes more cycles in a multi-threading setting.
>
> I will add your example into the git repository. Perhaps someone else,
> smarter than we, will find the explanation ;-)
>
> Cheers,
> Martin
>
> c.watterson wrote:
>
>> Yes, that is correct - I'm only concerned with TaskShort because the other
two are pre-empted in the middle of their measure/doWork methods (although I
have left in the measurement reports for them even so just to see them "roughly"
add up).
>>
>> Maybe it is because I'm not creating instances of RTThread but rather have
created instances of new classes extending RTThread?
>>
>> Or would it be to do with the "main" thread of taskset?
>>
>> I've emailed you the code for the taskset application.
>>
>> --- In java-processor@yahoogroups.com, Martin Schoeberl <martin@...> wrote:
>>
>>
>>> Thanks for this detailed explanation. You are measuring the execution
>>> time of ShortTask with the highest priority, right?
>>>
>>> When this thread runs, there should be no influence of the scheduler.
>>> The thread is already dispatched when you run your measure code and
>>> it is never interrupted.
>>>
>>> The only difference I can see between your single threaded measurement
>>> and your multithreaded measurement is that the method cache content
>>> will be different (depending on the other threads). However, the WCET
>>> analysis assumes a cache miss on doWork(), so this should be ok.
>>>
>>> If the measurement on the multithreaded setting is off by 4600 cycles
>>> that's something that needs ot further investigated. Perhaps you can
>>> send me your example code so I can run it.
>>>
>>> Cheers,
>>> Martin
>>>
>>>
>>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>

Martin,

The DDR SDRAM interface is the definitely an interesting little module :) ; I
know that the interface will be a good contribution to JOP.  This project is an
industrial project and all of the documentation is currently being cleaned. 
There is a document for each component, as well as a document for the collective
system.  I look forward to working with you, and the rest of the community.

Regards,

Marlon



--- In java-processor@yahoogroups.com, Martin Schoeberl <martin@...> wrote:
>
> Hi Marlon,
>
> that project looks quite cool!!! From your description and the block
> diagram I can get some idea of it. Looking forward to more information
> and source. I would especially like to use the DDR SDRAM interface for
> general use with JOP ;-)
>
> Is this an academic or industrial project? If it's the former one I'm
> looking forward to read paper(s) on it.
>
> Cheers,
> Martin
>
> mcwaccent wrote:
> > Hello Martin and Friends,
> >
> > I am delighted to inform everyone that at new open source project called
Wizardry is now available on OpenCores.  Martin if you recall, almost 2 years
ago, I had many questions regarding switching JOP's memory interface from SRAM
to priority-based round-robin Wishbone compliant DDR SDRAM.  While the idea to
replace JOPs main memory was abandoned, we were able to connect the DDR SDRAM
resources through JOP's IO interface.
> >
> > After successfully interfacing JOP with 512 MB of DDR SDRAM, we were able to
create a neat little open source network intrusion detection system.  This
system includes 2 very important components: a protocol analyzer (called EmPAC)
and a content processor (called eRCP).  Each of these components also connects
to the DDR SDRAM resources.  In fact, JOP is configured to load data from a web
server (which is also available open source), to each component for
configuration.
> >
> > The memory interface to the DDR SDRAM is Wishbone compliant and supports up
to 8 different component.  Each component has ~64 MB of memory space allocated
to it from the DDR SDRAM, while JOP has its own "special" port that has access
to each of the 8 components.
> >
> > I invite everyone to check out this project on at
http://www.opencores.com/project,wizardry .  As of right now there is only
documentation for EmPAC on there, as well as a top-level diagram of the entire
system.  Please let me know what you all think.  I will be adding all
documentation for each component, as well as all of the code within the next
week or so.  I hope that you all find this useful and can contribute your
thoughts.
> >
> > Regards,
> >
> > Marlon C. Winder
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>

David,

More documentation will be made available soon, and source code will be made
available for the first component, EmPAC.  You are more that welcome to take a
look at everything.

Marlon

--- In java-processor@yahoogroups.com, David Blubaugh <davidblubaugh2000@...>
wrote:
>
> Sir,
>  
>  
> Can I also work with you on this project.  I would love to created a
radiation hardened variant of your project !!
>  
> Thanks,
>  
> David Blubaugh
>  
>  
>
>
> --- On Tue, 11/10/09, mcwaccent <mwinder@...> wrote:
>
>
> From: mcwaccent <mwinder@...>
> Subject: [java-processor] New Open Source Project Featuring JOP!!!
> To: java-processor@yahoogroups.com
> Date: Tuesday, November 10, 2009, 1:38 PM
>
>
>  
>
>
>
> Hello Martin and Friends,
>
> I am delighted to inform everyone that at new open source project called
Wizardry is now available on OpenCores. Martin if you recall, almost 2 years
ago, I had many questions regarding switching JOP's memory interface from SRAM
to priority-based round-robin Wishbone compliant DDR SDRAM. While the idea to
replace JOPs main memory was abandoned, we were able to connect the DDR SDRAM
resources through JOP's IO interface.
>
> After successfully interfacing JOP with 512 MB of DDR SDRAM, we were able to
create a neat little open source network intrusion detection system. This system
includes 2 very important components: a protocol analyzer (called EmPAC) and a
content processor (called eRCP). Each of these components also connects to the
DDR SDRAM resources. In fact, JOP is configured to load data from a web server
(which is also available open source), to each component for configuration.
>
> The memory interface to the DDR SDRAM is Wishbone compliant and supports up to
8 different component. Each component has ~64 MB of memory space allocated to it
from the DDR SDRAM, while JOP has its own "special" port that has access to each
of the 8 components.
>
> I invite everyone to check out this project on at http://www.opencore
s.com/project, wizardry . As of right now there is only documentation for EmPAC
on there, as well as a top-level diagram of the entire system. Please let me
know what you all think. I will be adding all documentation for each component,
as well as all of the code within the next week or so. I hope that you all find
this useful and can contribute your thoughts.
>
> Regards,
>
> Marlon C. Winder
>

Martin,

Thanks for taking a look. I'm happy at least that I wasn't misinterpreting
things or making some error in the code.

I'd certainly be interested to hear if anyone finds a particular explanation for
the extra execution time.

Regards,
Conal

--- In java-processor@yahoogroups.com, Martin Schoeberl <martin@...> wrote:
>
> Conal,
>
> thanks for your examples. It's true the loop of TaskShort takes about
> 5000 cycle more when executing in an RT-thread. Both WCEt analysis and
> measuring
> the task code in a single thread shows the shorter time. Actually I have
> absolutely no idea why it takes more cycles in a multi-threading setting.
>
> I will add your example into the git repository. Perhaps someone else,
> smarter than we, will find the explanation ;-)
>
> Cheers,
> Martin
>
> c.watterson wrote:
> > Yes, that is correct - I'm only concerned with TaskShort because the other
two are pre-empted in the middle of their measure/doWork methods (although I
have left in the measurement reports for them even so just to see them "roughly"
add up).
> >
> > Maybe it is because I'm not creating instances of RTThread but rather have
created instances of new classes extending RTThread?
> >
> > Or would it be to do with the "main" thread of taskset?
> >
> > I've emailed you the code for the taskset application.
> >
> > --- In java-processor@yahoogroups.com, Martin Schoeberl <martin@> wrote:
> >
> >> Thanks for this detailed explanation. You are measuring the execution
> >> time of ShortTask with the highest priority, right?
> >>
> >> When this thread runs, there should be no influence of the scheduler.
> >> The thread is already dispatched when you run your measure code and
> >> it is never interrupted.
> >>
> >> The only difference I can see between your single threaded measurement
> >> and your multithreaded measurement is that the method cache content
> >> will be different (depending on the other threads). However, the WCET
> >> analysis assumes a cache miss on doWork(), so this should be ok.
> >>
> >> If the measurement on the multithreaded setting is off by 4600 cycles
> >> that's something that needs ot further investigated. Perhaps you can
> >> send me your example code so I can run it.
> >>
> >> Cheers,
> >> Martin
> >>
> >>
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>

Conal,

thanks for your examples. It's true the loop of TaskShort takes about
5000 cycle more when executing in an RT-thread. Both WCEt analysis and
measuring
the task code in a single thread shows the shorter time. Actually I have
absolutely no idea why it takes more cycles in a multi-threading setting.

I will add your example into the git repository. Perhaps someone else,
smarter than we, will find the explanation ;-)

Cheers,
Martin

c.watterson wrote:
> Yes, that is correct - I'm only concerned with TaskShort because the other two
are pre-empted in the middle of their measure/doWork methods (although I have
left in the measurement reports for them even so just to see them "roughly" add
up).
>
> Maybe it is because I'm not creating instances of RTThread but rather have
created instances of new classes extending RTThread?
>
> Or would it be to do with the "main" thread of taskset?
>
> I've emailed you the code for the taskset application.
>
> --- In java-processor@yahoogroups.com, Martin Schoeberl <martin@...> wrote:
>
>> Thanks for this detailed explanation. You are measuring the execution
>> time of ShortTask with the highest priority, right?
>>
>> When this thread runs, there should be no influence of the scheduler.
>> The thread is already dispatched when you run your measure code and
>> it is never interrupted.
>>
>> The only difference I can see between your single threaded measurement
>> and your multithreaded measurement is that the method cache content
>> will be different (depending on the other threads). However, the WCET
>> analysis assumes a cache miss on doWork(), so this should be ok.
>>
>> If the measurement on the multithreaded setting is off by 4600 cycles
>> that's something that needs ot further investigated. Perhaps you can
>> send me your example code so I can run it.
>>
>> Cheers,
>> Martin
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>

Hi Marlon,

that project looks quite cool!!! From your description and the block
diagram I can get some idea of it. Looking forward to more information
and source. I would especially like to use the DDR SDRAM interface for
general use with JOP ;-)

Is this an academic or industrial project? If it's the former one I'm
looking forward to read paper(s) on it.

Cheers,
Martin

mcwaccent wrote:
> Hello Martin and Friends,
>
> I am delighted to inform everyone that at new open source project called
Wizardry is now available on OpenCores.  Martin if you recall, almost 2 years
ago, I had many questions regarding switching JOP's memory interface from SRAM
to priority-based round-robin Wishbone compliant DDR SDRAM.  While the idea to
replace JOPs main memory was abandoned, we were able to connect the DDR SDRAM
resources through JOP's IO interface.
>
> After successfully interfacing JOP with 512 MB of DDR SDRAM, we were able to
create a neat little open source network intrusion detection system.  This
system includes 2 very important components: a protocol analyzer (called EmPAC)
and a content processor (called eRCP).  Each of these components also connects
to the DDR SDRAM resources.  In fact, JOP is configured to load data from a web
server (which is also available open source), to each component for
configuration.
>
> The memory interface to the DDR SDRAM is Wishbone compliant and supports up to
8 different component.  Each component has ~64 MB of memory space allocated to
it from the DDR SDRAM, while JOP has its own "special" port that has access to
each of the 8 components.
>
> I invite everyone to check out this project on at
http://www.opencores.com/project,wizardry .  As of right now there is only
documentation for EmPAC on there, as well as a top-level diagram of the entire
system.  Please let me know what you all think.  I will be adding all
documentation for each component, as well as all of the code within the next
week or so.  I hope that you all find this useful and can contribute your
thoughts.
>
> Regards,
>
> Marlon C. Winder
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>

Hello Martin and Friends,

I am delighted to inform everyone that at new open source project called
Wizardry is now available on OpenCores.  Martin if you recall, almost 2 years
ago, I had many questions regarding switching JOP's memory interface from SRAM
to priority-based round-robin Wishbone compliant DDR SDRAM.  While the idea to
replace JOPs main memory was abandoned, we were able to connect the DDR SDRAM
resources through JOP's IO interface.

After successfully interfacing JOP with 512 MB of DDR SDRAM, we were able to
create a neat little open source network intrusion detection system.  This
system includes 2 very important components: a protocol analyzer (called EmPAC)
and a content processor (called eRCP).  Each of these components also connects
to the DDR SDRAM resources.  In fact, JOP is configured to load data from a web
server (which is also available open source), to each component for
configuration.

The memory interface to the DDR SDRAM is Wishbone compliant and supports up to 8
different component.  Each component has ~64 MB of memory space allocated to it
from the DDR SDRAM, while JOP has its own "special" port that has access to each
of the 8 components.

I invite everyone to check out this project on at
http://www.opencores.com/project,wizardry .  As of right now there is only
documentation for EmPAC on there, as well as a top-level diagram of the entire
system.  Please let me know what you all think.  I will be adding all
documentation for each component, as well as all of the code within the next
week or so.  I hope that you all find this useful and can contribute your
thoughts.

Regards,

Marlon C. Winder

Why would you need to switch contexts? That would imply that you have
more parallel code than actual execution units. With a highly parallel
hardware (either processor cores or dedicated FPGA dataflow hardware)
the challenge is to find enough parallelism in the algorithm.

Martin

Tobias Gogolin wrote:
>
>
> Would it be an efficient approach though?
> I represent the thesis that to achieve breakthrough performance the
> program with all its objects and methods should be mapped into an FPGA
> so that data can stream through this structure...
> Yet since one would probably run out of FPGA space quickly running OS
> and applications in this truly parallel processor, it would probably
> also be required to have a special FPGA structure that could do quick
> context switching between various 'Program graphs' that would be
> mapped into the FPGA Grid!
>
> I think the FPGA is the right direction for fast computing, but it
> requires to write a Compiler/Bios/OS and to create specialized new
> FPGAs to achieve this dream!
>
> Sorry for my contrary opinion...
>
>
>
> On Mon, Nov 9, 2009 at 3:46 PM, David Blubaugh
> <davidblubaugh2000@... <mailto:davidblubaugh2000@...>> wrote:
>
>
>
>     Sir,
>
>
>     Would you be interested in helping me to initiate such a project ??
>
>     David
>
>
>
>     --- On *Mon, 11/9/09, Martin Schoeberl /<martin@...
>     <mailto:martin@...>>/* wrote:
>
>
>         From: Martin Schoeberl <martin@...
>         <mailto:martin@...>>
>         Subject: Re: [java-processor] SUPERCOMPUTING MULTI-CORE JOP
>         PROJECT
>         To: java-processor@yahoogroups.com
>         <mailto:java-processor@yahoogroups.com>
>         Date: Monday, November 9, 2009, 6:25 PM
>
>
>
>         I'm not aware of such a project. I would be skeptic to use JOP for
>         high performance computing. It is designed for time-predictable
>         computing, which is a different design optimization.
>
>         After stating this disclaimer ;-), it could be an interesting try.
>         For multi-core at some point the performance limit is the memory
>         anyway (reaching this limit earlier, with less cores, on high
>         preforming cores). So with just adding more JOPs perhaps you
>         reach the same limit as with a smaller number of more powerful
>         cores.
>
>         Cheers,
>         Martin
>
>         David Blubaugh wrote:
>         >
>         >
>         > TO ALL,
>         >
>         > Has anyone ever developed a high performance computing
>         project by
>         > utilizing a multi-core approach with the Java Optimized
>         Processor ??
>         >
>         > Thanks,
>         >
>         > David Blubaugh
>         >
>         >
>         >
>         >
>         >
>         >
>         >
>         >
>         >
>
>
>
>
>
>
>
> --
> Tobias Gogolin
> Tel. Movistar (646) 124 32 82
> Tel. Telcel (646) 160 58 99
> skype: moontogo
> messenger: usertogo@... <mailto:usertogo@...>
>
> You develop Sustainable Ranch Technology at
> http://tech.groups.yahoo.com/group/SURA-TECH
> an Open Source Electric Motor/Alternator at
> http://groups.yahoo.com/group/Performance_Axial_Flux
> and an Open Source Motor Controller at
> http://groups.yahoo.com/group/GoBox
>
>
>