"MOO" <[EMAIL PROTECTED]> writes:
--------
we are so interested in the back -end VHDL code generation in ptII.
we r gonna use the ptII in design of embedded systems .
and the problem we r facing now is how to generate a VHDL code for the
system components that will be dedicated for Hardware...
does any one have any suggestations about this delimma..!!
(note: we r using ptII new beta version ) and we r coding using Java.
we r not so interested to code in C++ as in ptolemy classic.
so what do u suggest ???
Thanks.
Regards,
MO. Salem .
----------
I suggest that you fix the a and the e keys on your keyboard :-)
Seriously though, we intended to ship Ptolemy II with some code
generation facilities, but as one of the contributors to that code,
I felt that it was not really ready for release.
In Ptolemy Classic, most of the codegen 'domains' were not really
differnet domains (they did not have different models of computation),
instead they were really backends to SDF. In Ptolemy Classic, a
developer needed to develop different actors for each target processor
or language. I'm told that one thing we found was that the
inter-actor communication often took up much of the computation time.
Jeff Tsay's Master's project was to add code generation to Ptolemy II.
Jeff's approach, which we call deep codegen is to read in actor
definitions written in Java, generate an AST and then generate
a faster/simpler Java description of the model that does not
use the Ptolemy II kernel include things like mutations etc.
In this way, we avoid writing different actors for different
platforms and apply compiler techniques to increase performance.
I was able to port simple models from Ptolemy II through the
deep codegen facility to the Palm Pilot by using KVM and Wabi.
However, since KVM lacks floats, and Wabi lacks Exceptions,
there is not much that can be done.
I have some notes about this at:
http://ptolemy.eecs.berkeley.edu/~cxh/ptpub/kvm.htm
I was also able to take a model and use the GNU Java backend (gcj)
and generate native code. This resulted in a fairly significant
performance improvement. I think I saw as much as 10x over regular
Ptolemy II times and 4x over deep codegen times for a small
Orthogonal Communication system.
Jeff's Masters report is at:
Jeff Tsay, "A Code Generation Framework for Ptolemy II," ERL Technical
Report UCB/ERL No. M00/25, Dept. EECS, University of California,
Berkeley, CA 94720, May 19, 2000.
http://ptolemy.eecs.berkeley.edu/publications/papers/00/codegen/
There is a short summary at:
Jeff Tsay, Christopher Hylands and Edward Lee, "A Code Generation
Framework for Java Component-Based Designs," CASES '00, November
17-19, 2000, San Jose, CA.
http://ptolemy.eecs.berkeley.edu/publications/papers/00/javacodegen/
You might also check out this paper:
JJ. Buck, R. Vaidyanathan, "Heterogeneous Modeling and Simulation of
Embedded Systems in El Greco," CODES2000.
http://www.sigda.acm.org/Archives/ProceedingArchives/Codes/Codes2000/papers/2000/codes00/pdffiles/08_1.pdf
Professor Shuvra Bhattacharyya, a former student of Professor Lee's,
is working on what we call 'shallow codegen', where we generate
a Java description of a model that is fairly dependent on the Ptolemy
kernel. Professor Bhattacharyya is also working on a C backend.
Combining deep and shallow codegen with different backends is
an area of research we would like to pursue.
Ultimately, I think we will need to provide actor authors with a way
to include Ptolemy Classic style codeblocks in actors so as
to optimize certain operations on specific processors.
There are some notes about codegen at
http://ptolemy.eecs.berkeley.edu/~cxh/ptpub/codegen.htm
All of the above code is still in production and not ready for
release. We don't have a scheduled release date either.
So, in the short term, there is not much we can suggest. The code
we have is still in the early stages of production, and is not yet
shippable. Once the release is out, I hope to return to working
on codegen.
-Christopher
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
