Does Java make sense in Virtual Prototyping ?

Written on . Posted in blog

The spin project was initiated by a more spontaneous idea. After first outcome, it is time to think if it really makes sense and why (I am) not staying with systemC. Lets start with a simple question.

What is bad about systemC ?

SystemC is not really bad and neither is C++, but there are several issues that make it difficult to use, especially in Virtual Prototyping:

C++ is  difficult

I guess there are not many people who don't say this. Even if I worked many years in C++/UML Architecture, compared to Java, I must say that C++ is really challenging, especially when it comes up with generics (generously used in systemC).

What I found is that hw people usually don't like C++. They can do C and they don't know Java (so difficult to say if they would like it). And it is difficult to convince hw people to start with C++ or to find people who can do both.

We are talking about Virtual Prototyping, we don't want to develop a new windows killer application, we just want to sketch hw! So the optimal language should be easy enough that hw people are able to define their hw in a simple way.

C++ is platform dependend

When you developed a piece of code in C++ on a windows pc, you can be sure that it will not run under linux.

Some months ago I tried to do some benchmarks for spin. So I tried to compile a fresh downloaded systemC on windows and linux. Both platforms had problems, both I had to fix in different ways. Unfortunately these problems are systematic.
You might think that it makes no sense to support different platforms. What I have found in my current project (@intel) is that it is ugly reality. HW people are usually bound to unix machines, firmware people prefer windows, platform guys do both. There is a lot of effort necessary to keep both platforms in sync and working. Another issue is about different library versions and compiler dependencies but I prefer to stop here.

C++ is inefficient in development

Still in the year 2012 we have to define headers and source code and keep them in sync. When changing name, locations or parameters we need to do this by hand in a lot of different files. If you tried this in Java (with eclipse), you will know that it can be done 10 times faster. You just change a variables name and all dependencies are updated, you change the parameters of a method (a special dialog) and all references are changed that way, you move a file into a different package and all includes are updated.

Developing a piece of  code in java is so much easier. Compilation is done invisibly in the background. You directly see if you typed something wrong and don't need to wait for compilation and linkage. Eclipse platform is also capable of C++ but unfortunately it is not at the same level as the java tooling is (and probably will never be as C++ is difficult to handle) even if they (CDT team) made good progress.

Next  question.

Has Java/spin the capability to replace C++/systemC ?

I am not sure it ever will, because systemC is a somehow defacto standard and all tool vendors go in that direction. So I am just talking about the technical capabilities.

Is Java fast enough for simulation ?

Looking into the benchmarks of spin, the answer should be a clear yes. But it is not that easy to compare simulation speed:

  1. When the simulation is short, C++ is clearly advanced. The hotspot engine needs some time before starting up.
  2. When starting up, the first code gets interpreted. When a code sequence is called more often it gets compiled into native.
  3. Afterwards the hotspot engine optimzes that native code.

So long runner have clear advantages with java hotspot - short runner may be faster in C++. Finally there can't be a clear answer as so far no large project has been made with it!

Does spin support enough features from systemC

Probably not (spin is at version 0.6). Also there is currently nothing compared to AMS or TLM.

spin 0.7 will contain sequence ports (similar to sdf), tlm features will follow. Both add-ons will focus on integrating these feature in a simple way.

From the tooling side, there is already a debug view available that allows to look into the modules and signals.

Print

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive